Có rất nhiều khía cạnh khác nhau đối với bảo mật WebSocket.
Đoạn trích từ wikipedia mà bạn trích dẫn là đề cập đến mặt nạ của máy khách WebSocket với dữ liệu máy chủ. Điều này nhằm bảo vệ các trung gian bị lỗi (ví dụ: proxy và bộ đệm) khỏi vô tình giải thích lưu lượng truy cập WebSocket như lưu lượng HTTP bình thường. Sự nguy hiểm ở đây là giao thức WebSockets có thể được sử dụng để đầu độc trung gian lưu trữ. Tuy nhiên, tôi nên lưu ý rằng đây là một mối quan tâm hoàn toàn lý thuyết, nhưng nó là đủ của một mối quan tâm rằng Mozilla và Opera miễn cưỡng gửi Hixie và phiên bản HyBi đầu của giao thức WebSocket. Vì vậy, IETF quyết định thêm khách hàng vào mặt nạ máy chủ của dữ liệu để giải quyết mối quan tâm.
Ngoài ra, IETF chịu trách nhiệm về giao thức WebSocket (IETF 6455) trong khi W3C chịu trách nhiệm về API WebSocket HTML5 (đối tượng Javascript, phương thức và sự kiện).
Một khía cạnh khác đối với bảo mật WebSocket là bảo mật gốc. Đoạn trích thứ hai bạn trích dẫn từ đặc tả API WebSocket của W3C có liên quan đến bảo mật gốc. WebSockets hỗ trợ các kết nối có nguồn gốc chéo (đến một máy chủ khác mà trang HTML được phân phát). Cảnh báo này nói rằng nếu thủ tục gốc HTTP thông thường đã được sử dụng cho WebSockets, điều này sẽ mở ra một lỗ hổng bảo mật lớn. Tuy nhiên, thủ tục WebSocket là khác nhau vì lý do chính xác này. Đối với một điều, bắt tay và phản hồi WebSocket được thiết kế sao cho các kết nối WebSocket không thể được thực hiện cho máy chủ HTTP không hỗ trợ các kết nối WebSocket: máy chủ phải ký/băm một khóa theo cách cụ thể của WebSocket và trả về điều này trong câu trả lời bắt tay. Phần thứ hai là trình duyệt phải gửi tiêu đề Gốc như là một phần của cái bắt tay (điều này cho biết vị trí HTML/Javascript đã được tải từ ban đầu).Điều này cho phép máy chủ chọn tên miền mà nó sẽ cho phép bắt nguồn từ các kết nối WebSocket.
Cuối cùng, có hai chế độ kết nối WebSocket: không được mã hóa (ws: //) và được mã hóa (wss: //). Chế độ mã hóa sử dụng mã hóa TLS/SSL để mã hóa tất cả dữ liệu được gửi đến và đi từ máy chủ (bao gồm cả bắt tay và phản hồi ban đầu). Đây là cơ chế mã hóa tương tự được sử dụng cho các kết nối HTTPS (và sử dụng cùng một công cụ mã hóa trong trình duyệt). Điều này ngăn không cho các bên thứ ba xâm nhập dữ liệu đang được chuyển.
Có thực sự chỉ là hai phiên bản của giao thức WebSocket đáng được biết đến:
Hixie76: Phiên bản này của giao thức bổ sung an ninh cross-nguồn gốc và tiêu đề băm/ký. Tuy nhiên, do cách thức giao thức được thiết kế nên rất khó để thêm hỗ trợ cho giao thức này cho các máy chủ web hiện có. Đây là phiên bản hiện đang hỗ trợ trong iOS (hy vọng iOS 6 cuối cùng sẽ cập nhật để IETF 6455)
IETF 6455: Đây là phiên bản của giao thức WebSocket đã được chuẩn hóa bởi IETF cuối tháng mười một (tháng 11 năm 2011). Đó là đỉnh cao của công việc của nhóm làm việc IETF HyBi (lặp đi lặp lại của các giao thức dẫn đến nó được dán nhãn HyBi XX). Đây là phiên bản được hỗ trợ bởi các phiên bản hiện tại của Chrome và Firefox và cũng bởi IE 10 và sớm Opera.
WebSockets giống như bất kỳ hình thức giao tiếp nào khác thừa hưởng các vấn đề bảo mật liên quan đến giao dịch thuần văn bản (bảo mật và toàn vẹn) – Adi
Aye - xác định "an toàn". Bảo mật như HTTPS, khi sử dụng HTTPS? Yeap. Erm, miễn là không có gì sai. –
Tôi e rằng không có gì là an toàn. Xác định "an toàn" – kbec