Mặt nạ trong khung WebSocket là gì?

Question

Tôi đang làm việc trên một websocket thực hiện và không biết ý nghĩa của một mặt nạ là trong một khung.

Ai đó có thể giải thích cho tôi điều gì và lý do đề xuất?

0     1     2     3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-------+-+-------------+-------------------------------+ 
|F|R|R|R| opcode|M| Payload len | Extended payload length | 
|I|S|S|S| (4) |A|  (7)  |    (16/64)   | 
|N|V|V|V|  |S|    | (if payload len==126/127) | 
| |1|2|3|  |K|    |        | 
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + 
|  Extended payload length continued, if payload len == 127 | 
+ - - - - - - - - - - - - - - - +-------------------------------+ 
|        |Masking-key, if MASK set to 1 | 
+-------------------------------+-------------------------------+ 
| Masking-key (continued)  |   Payload Data   | 
+-------------------------------- - - - - - - - - - - - - - - - + 
:      Payload Data continued ...    : 
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 
|      Payload Data continued ...    | 
+---------------------------------------------------------------+ 

Answer 1

Websockets được định nghĩa trong RFC6455, trong đó nêu trong Section 5.3:

Sự không đoán trước của khóa mặt nạ là cần thiết để ngăn chặn các tác giả của các ứng dụng độc hại từ việc lựa chọn các byte xuất hiện trên dây.

Trong một blog entry about Websockets Tôi tìm thấy lời giải thích sau đây:

che-key (32 bit): nếu các bit mặt nạ được thiết lập (và tôi tin tưởng, đó là nếu bạn viết cho phía máy chủ) bạn có thể đọc các byte chưa ký ở đây được sử dụng để xor tải trọng với. Nó được sử dụng để đảm bảo rằng các proxy giả mạo không thể bị kẻ tấn công từ phía khách hàng lạm dụng.

Nhưng câu trả lời rõ ràng nhất tôi tìm thấy trong một số mailing list archive. Có John Tamplin khẳng định:

Về cơ bản, WebSockets độc đáo ở chỗ bạn cần để bảo vệ cơ sở hạ tầng mạng , ngay cả khi bạn có mã thù địch chạy trên máy tính, đầy đủ kiểm soát thù địch của máy chủ, và các mảnh chỉ bạn có thể tin tưởng là trình duyệt của khách hàng . Khi trình duyệt tạo một mặt nạ ngẫu nhiên cho mỗi khung , mã máy khách thù địch không thể chọn các mẫu byte xuất hiện trên dây và sử dụng để tấn công cơ sở hạ tầng mạng dễ bị tổn thương.

Như kmkaplan đã nêu, vector tấn công được mô tả trong Section 10.3 của RFC.
Đây là biện pháp ngăn chặn các cuộc tấn công ngộ độc bộ nhớ cache proxy (xem Paper about the attack). Những gì nó làm, là tạo ra một số ngẫu nhiên. Bạn phải XOR tải trọng với phím mặt nạ ngẫu nhiên.

Nhân tiện: Không chỉ đề xuất. Đó là bắt buộc.

Answer 2

Từ this article:

Masking của WebSocket giao thông từ client tới server là cần thiết vì cơ hội không chắc rằng mã độc hại có thể gây ra một số proxy bị hỏng để làm điều sai trái và sử dụng như là một cuộc tấn công của một số loại . Không ai chứng minh rằng điều này thực sự có thể xảy ra, nhưng vì thực tế nó có thể xảy ra là đủ lý do để các nhà cung cấp trình duyệt bị giật, mặt nạ được thêm vào để loại bỏ khả năng nó được sử dụng như một cuộc tấn công.

Giả sử kẻ tấn công có thể thỏa hiệp cả mã JavaScript được thực thi trong trình duyệt cũng như máy chủ phụ, mặt nạ được thiết kế để ngăn chuỗi thứ tự được gửi giữa hai điểm cuối này được tạo theo cách đặc biệt có thể phá vỡ bất kỳ proxy bị hỏng nào giữa hai điểm cuối này (bằng cách phá vỡ điều này có nghĩa là các proxy có thể cố gắng diễn giải luồng websocket là HTTP khi thực tế chúng không nên).

Trình duyệt (và không phải mã JavaScript trong trình duyệt) có tiếng nói cuối cùng trên mặt nạ được tạo ngẫu nhiên được sử dụng để gửi thông điệp, đó là lý do tại sao những kẻ tấn công không thể biết luồng cuối cùng của byte mà proxy có thể thấy sẽ là.

Lưu ý rằng mặt nạ sẽ dư thừa nếu luồng WebSocket của bạn được mã hóa (vì nó phải là). Article từ tác giả của Flask của Python:

Tại sao lại có mặt nạ? Bởi vì dường như có đủ cơ sở hạ tầng bị hỏng trên đó cho phép tiêu đề nâng cấp trải qua và sau đó xử lý phần còn lại của kết nối dưới dạng yêu cầu HTTP thứ hai mà sau đó nó sẽ đưa vào bộ nhớ cache. Tôi không có lời cho việc này. Trong mọi trường hợp, việc phòng thủ chống lại điều đó về cơ bản là một số ngẫu nhiên 32 bit mạnh mẽ như phím che. Hoặc bạn biết ... sử dụng TLS và không sử dụng proxy shitty.