Blog 👨‍💻

🔏WebSockets

What are WebSockets?

WebSockets là một giao thức liên lạc hai chiều, song công hoàn toàn được khởi tạo qua HTTP. Chúng thường được sử dụng trong các ứng dụng web hiện đại để truyền dữ liệu và lưu lượng không đồng bộ khác.

Trong phần này, chúng tôi sẽ giải thích sự khác biệt giữa HTTP và WebSockets, mô tả cách kết nối WebSocket được thiết lập và phác thảo các thông báo WebSocket trông như thế nào.

What is the difference between HTTP and WebSockets?

Hầu hết giao tiếp giữa trình duyệt web và trang web đều sử dụng HTTP. Với HTTP, máy khách gửi yêu cầu và máy chủ trả về phản hồi. Thông thường, phản hồi xảy ra ngay lập tức và giao dịch hoàn tất. Ngay cả khi kết nối mạng vẫn mở, kết nối này sẽ được sử dụng cho một giao dịch riêng của yêu cầu và phản hồi.

Một số trang web hiện đại sử dụng WebSockets. Các kết nối WebSocket được bắt đầu qua HTTP và thường tồn tại lâu dài. Tin nhắn có thể được gửi theo một trong hai hướng vào bất kỳ lúc nào và không mang tính chất giao dịch. Kết nối thường sẽ mở và không hoạt động cho đến khi máy khách hoặc máy chủ sẵn sàng gửi tin nhắn.

WebSockets đặc biệt hữu ích trong các trường hợp yêu cầu thông báo có độ trễ thấp hoặc do máy chủ khởi tạo, chẳng hạn như nguồn cấp dữ liệu tài chính theo thời gian thực.

How are WebSocket connections established?

Các kết nối WebSocket thường được tạo bằng JavaScript phía máy khách như sau:

var ws = new WebSocket("wss://normal-website.com/chat");

Giao thức wss thiết lập WebSocket qua kết nối TLS được mã hóa, trong khi giao thức ws sử dụng kết nối không được mã hóa.

Để thiết lập kết nối, trình duyệt và máy chủ thực hiện WebSocket handshake qua HTTP. Trình duyệt đưa ra yêu cầu WebSocket handshake như sau:

GET /chat HTTP/1.1
Host: normal-website.com
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==
Connection: keep-alive, Upgrade
Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
Upgrade: websocket

Nếu máy chủ chấp nhận kết nối, nó sẽ trả về phản hồi WebSocket handshake như sau:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=

Tại thời điểm này, kết nối mạng vẫn mở và có thể được sử dụng để gửi thông báo WebSocket theo một trong hai hướng.

Một số tính năng của thông báo WebSocket handshake đáng chú ý:

  • Tiêu đề Connectionvà Upgradetrong yêu cầu và phản hồi chỉ ra rằng đây là WebSocket handshake.

  • Tiêu đề Sec-WebSocket-Versionyêu cầu chỉ định phiên bản giao thức WebSocket mà máy khách muốn sử dụng. Điều này thường là 13.

  • Tiêu đề Sec-WebSocket-Key yêu cầu chứa giá trị ngẫu nhiên được mã hóa Base64, giá trị này sẽ được tạo ngẫu nhiên trong mỗi yêu cầu bắt tay.

  • Tiêu đề Sec-WebSocket-Accept phản hồi chứa hàm băm của giá trị được gửi trong tiêu đề Sec-WebSocket-Key yêu cầu, được nối với một chuỗi cụ thể được xác định trong đặc tả giao thức. Điều này được thực hiện để ngăn chặn các phản hồi sai lệch do máy chủ hoặc proxy bộ nhớ đệm bị định cấu hình sai.

What do WebSocket messages look like?

Khi kết nối WebSocket đã được thiết lập, các thông báo có thể được gửi không đồng bộ theo cả hai hướng bởi máy khách hoặc máy chủ.

Một tin nhắn đơn giản có thể được gửi từ trình duyệt bằng JavaScript phía máy khách như sau:

ws.send("Peter Wiener");

Về nguyên tắc, thông báo WebSocket có thể chứa bất kỳ nội dung hoặc định dạng dữ liệu nào. Trong các ứng dụng hiện đại, JSON thường được sử dụng để gửi dữ liệu có cấu trúc trong các thông báo WebSocket.

Ví dụ: một ứng dụng chat-bot sử dụng WebSockets có thể gửi một thông báo như sau:

{"user":"Hal Pline","content":"I wanted to be a Playstation growing up, not a device to answer your inane questions"}

Manipulating WebSocket traffic

Intercepting and modifying WebSocket messages

Bạn có thể sử dụng Burp Proxy để chặn và sửa đổi các thông báo WebSocket như sau:

  • Mở trình duyệt của Burp.

  • Duyệt đến chức năng ứng dụng sử dụng WebSockets. Bạn có thể xác định rằng WebSockets đang được sử dụng bằng cách sử dụng ứng dụng và tìm kiếm các mục xuất hiện trong tab lịch sử WebSockets trong Burp Proxy.

  • Trong tab Chặn của Burp Proxy, hãy đảm bảo rằng tính năng chặn được bật.

  • Khi một thông báo WebSocket được gửi từ trình duyệt hoặc máy chủ, nó sẽ được hiển thị trong tab Chặn để bạn xem hoặc sửa đổi. Nhấn nút Chuyển tiếp - forward để chuyển tiếp tin nhắn.

Note: You can configure whether client-to-server or server-to-client messages are intercepted in Burp Proxy. Do this in the Options tab, in the Intercept WebSocket Messages options.

Replaying and generating new WebSocket messages

Ngoài việc chặn và sửa đổi các tin nhắn WebSocket một cách nhanh chóng, bạn có thể phát lại các tin nhắn riêng lẻ và tạo các tin nhắn mới. Bạn có thể làm điều này bằng Burp Repeater:

  • Trong Burp Proxy, hãy chọn một thư trong lịch sử WebSockets hoặc trong tab Intercept và chọn "Send to Repeater" từ menu context.

  • Trong Burp Repeater, giờ đây bạn có thể chỉnh sửa tin nhắn đã chọn và gửi đi gửi lại.

  • Bạn có thể nhập một tin nhắn mới và gửi nó theo một trong hai hướng, tới máy khách hoặc máy chủ.

  • Trong bảng "History" trong Burp Repeater, bạn có thể xem lịch sử của các tin nhắn đã được truyền qua kết nối WebSocket. Điều này bao gồm các thông báo mà bạn đã tạo trong Burp Repeater và bất kỳ thông báo nào được tạo bởi trình duyệt hoặc máy chủ thông qua cùng một kết nối.

  • Nếu bạn muốn chỉnh sửa và gửi lại bất kỳ thư nào trong bảng lịch sử, bạn có thể thực hiện việc này bằng cách chọn thư và chọn "Edit and resend" từ menu ngữ cảnh.

Manipulating WebSocket connections

Cũng như thao tác với các thông báo WebSocket, đôi khi cần phải thao tác với WebSocket handshake để thiết lập kết nối.

Có nhiều tình huống khác nhau trong đó thao tác bắt tay WebSocket có thể cần thiết:

  • Nó có thể cho phép bạn tiếp cận nhiều bề mặt tấn công hơn.

  • Một số cuộc tấn công có thể khiến kết nối của bạn bị ngắt, do đó bạn cần thiết lập một kết nối mới.

  • Mã thông báo hoặc dữ liệu khác trong yêu cầu bắt tay ban đầu có thể đã cũ và cần cập nhật.

Bạn có thể thao tác bắt tay WebSocket bằng Burp Repeater:

  • Gửi một tin nhắn WebSocket tới Burp Repeater như đã được mô tả .

  • Trong Burp Repeater, nhấp vào biểu tượng bút chì bên cạnh URL WebSocket. Thao tác này sẽ mở ra một trình hướng dẫn cho phép bạn đính kèm vào một WebSocket đã kết nối hiện có, sao chép một WebSocket đã kết nối hoặc kết nối lại với một WebSocket đã ngắt kết nối.

  • Nếu bạn chọn sao chép một WebSocket đã kết nối hoặc kết nối lại với một WebSocket đã ngắt kết nối, thì trình hướng dẫn sẽ hiển thị đầy đủ chi tiết về yêu cầu bắt tay WebSocket mà bạn có thể chỉnh sửa theo yêu cầu trước khi thực hiện bắt tay.

  • Khi bạn nhấp vào "Connect", Burp sẽ cố gắng thực hiện quá trình handshake đã định cấu hình và hiển thị kết quả. Nếu kết nối WebSocket mới được thiết lập thành công, thì bạn có thể sử dụng kết nối này để gửi tin nhắn mới trong Burp Repeater.

WebSockets security vulnerabilities

Về nguyên tắc, trên thực tế, bất kỳ lỗ hổng bảo mật web nào cũng có thể phát sinh liên quan đến WebSockets:

  • Đầu vào do người dùng cung cấp được truyền đến máy chủ có thể được xử lý theo những cách không an toàn, dẫn đến các lỗ hổng như SQL Injection hoặc XML external entity injection.

  • Một số blind vulnerabilities đạt được thông qua WebSockets chỉ có thể được phát hiện bằng cách sử dụng các kỹ thuật ngoài băng tần (OAST) .

  • Nếu dữ liệu do kẻ tấn công kiểm soát được truyền qua WebSockets tới những người dùng ứng dụng khác, thì điều đó có thể dẫn đến vul XSS hoặc các lỗ hổng phía máy khách khác.

Manipulating WebSocket messages to exploit vulnerabilities

Phần lớn các lỗ hổng dựa trên đầu vào ảnh hưởng đến WebSockets có thể được tìm thấy và khai thác bằng cách giả mạo nội dung của thông báo WebSocket .

Ví dụ: giả sử ứng dụng trò chuyện sử dụng WebSockets để gửi tin nhắn trò chuyện giữa trình duyệt và máy chủ. Khi người dùng nhập tin nhắn trò chuyện, một tin nhắn WebSocket như sau sẽ được gửi đến máy chủ:

{"message":"Hello Carlos"}

Nội dung của tin nhắn được truyền (một lần nữa qua WebSockets) tới một người dùng trò chuyện khác và được hiển thị trong trình duyệt của người dùng như sau:

<td>Hello Carlos</td>

Trong tình huống này, miễn là không có quá trình xử lý hoặc phòng thủ đầu vào nào khác đang hoạt động, kẻ tấn công có thể thực hiện một cuộc tấn công XSS bằng chứng về khái niệm bằng cách gửi thông báo WebSocket sau:

{"message":"<img src=1 onerror='alert(1)'>"}

Manipulating the WebSocket handshake to exploit vulnerabilities

Một số lỗ hổng WebSockets chỉ có thể được tìm thấy và khai thác bằng manipulating the WebSocket handshake . Những lỗ hổng này có xu hướng liên quan đến lỗi thiết kế, chẳng hạn như:

  • Đặt niềm tin không đúng chỗ vào các tiêu đề HTTP để thực hiện các quyết định bảo mật, chẳng hạn như tiêu đề X-Forwarded-For.

  • Các lỗi trong cơ chế xử lý phiên, vì bối cảnh phiên trong đó các thông báo WebSocket được xử lý thường được xác định bởi ngữ cảnh phiên của thông báo handshake.

  • Bề mặt tấn công được giới thiệu bởi các tiêu đề HTTP tùy chỉnh được ứng dụng sử dụng.

Using cross-site WebSockets to exploit vulnerabilities

Một số lỗ hổng bảo mật WebSockets phát sinh khi kẻ tấn công tạo kết nối WebSocket tên miền chéo từ một trang web mà kẻ tấn công kiểm soát. Đây được gọi là một cuộc tấn công cross-site WebSocket hijacking và nó liên quan đến việc khai thác lỗ hổng cross-site request forgery (CSRF) trên một WebSocket handshake. Cuộc tấn công thường có tác động nghiêm trọng, cho phép kẻ tấn công thực hiện các hành động đặc quyền thay mặt cho người dùng nạn nhân hoặc lấy dữ liệu nhạy cảm mà người dùng nạn nhân có quyền truy cập.

What is cross-site WebSocket hijacking?

Cross-site WebSockets hijacking ( cũng được biết như là cross-origin WebSocket hijacking) liên quan đến lỗ hổng giả mạo yêu cầu liên trang (CSRF) trong quá trình WebSocket handshake. Nó phát sinh khi yêu cầu WebSocket handshake chỉ dựa vào cookie HTTP để xử lý session và không chứa bất kỳ CSRF token nào hoặc các giá trị không thể đoán trước khác.

Kẻ tấn công có thể tạo một trang web độc hại trên miền riêng của chúng, trang này sẽ thiết lập kết nối WebSocket chéo trang tới ứng dụng dễ bị tấn công. Ứng dụng sẽ xử lý kết nối trong bối cảnh (context session) phiên của người dùng nạn nhân với ứng dụng.

Sau đó, trang của kẻ tấn công có thể gửi các tin nhắn tùy ý đến máy chủ thông qua kết nối và đọc nội dung của các tin nhắn nhận được từ máy chủ. Điều này có nghĩa là, không giống như CSRF thông thường, kẻ tấn công có được sự tương tác hai chiều với ứng dụng bị xâm nhập.

What is the impact of cross-site WebSocket hijacking?

Một cuộc tấn công cross-site Websocket hijacking thành công thường sẽ cho phép hacker:

  • Perform unauthorized actions masquerading as the victim user. Như với CSRF thông thường, kẻ tấn công có thể gửi các thông báo tùy ý đến ứng dụng phía máy chủ. Nếu ứng dụng sử dụng thông báo WebSocket do máy khách tạo để thực hiện bất kỳ hành động nhạy cảm nào, thì kẻ tấn công có thể tạo thông báo phù hợp trên nhiều miền và kích hoạt các hành động đó.

  • Retrieve sensitive data that the user can access. Không giống như CSRF thông thường, chiếm quyền điều khiển WebSocket chéo trang cho phép kẻ tấn công tương tác hai chiều với ứng dụng dễ bị tấn công qua WebSocket bị tấn công. Nếu ứng dụng sử dụng các thông báo WebSocket do máy chủ tạo để trả lại bất kỳ dữ liệu nhạy cảm nào cho người dùng, thì kẻ tấn công có thể chặn các thông báo đó và thu thập dữ liệu của người dùng nạn nhân.

Performing a cross-site WebSocket hijacking attack

Vì một cuộc tấn công chiếm quyền điều khiển WebSocket trên nhiều trang web về cơ bản là một lỗ hổng CSRF trên một WebSocket handshake, nên bước đầu tiên để thực hiện một cuộc tấn công là xem xét các WebSocket handshake mà ứng dụng thực hiện và xác định xem chúng có được bảo vệ chống lại CSRF hay không.

Xét về các điều kiện thông thường đối với các cuộc tấn công CSRF , bạn thường cần tìm một thông báo bắt tay chỉ dựa vào cookie HTTP để xử lý phiên và không sử dụng bất kỳ mã thông báo nào hoặc các giá trị không thể đoán trước khác trong tham số yêu cầu.

Ví dụ: yêu cầu WebSocket handshake sau đây có thể dễ bị CSRF, vì mã thông báo phiên duy nhất được truyền trong cookie:

GET /chat HTTP/1.1
Host: normal-website.com
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==
Connection: keep-alive, Upgrade
Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2
Upgrade: websocket

Note: Tiêu đề Sec-WebSocket-Key chứa một giá trị ngẫu nhiên để ngăn lỗi từ bộ nhớ đệm proxy và không được sử dụng cho mục đích xác thực hoặc xử lý session.

Nếu yêu cầu WebSocket handshake dễ bị tấn công CSRF thì trang web của kẻ tấn công có thể thực hiện yêu cầu chéo trang để mở một WebSocket trên trang dễ bị tấn công. Điều gì xảy ra tiếp theo trong cuộc tấn công phụ thuộc hoàn toàn vào logic của ứng dụng và cách ứng dụng sử dụng WebSockets . Cuộc tấn công có thể liên quan đến:

  • Gửi tin nhắn WebSocket để thực hiện các hành động trái phép thay mặt cho người dùng nạn nhân.

  • Gửi tin nhắn WebSocket để truy xuất dữ liệu nhạy cảm.

  • Đôi khi, chỉ cần đợi các tin nhắn đến có chứa dữ liệu nhạy cảm.

How to secure a WebSocket connection

Để giảm thiểu nguy cơ lỗ hổng bảo mật phát sinh với WebSockets, hãy sử dụng các nguyên tắc sau:

  • Sử dụng wss://giao thức (WebSockets qua TLS).

  • Mã cứng URL của điểm cuối WebSockets và chắc chắn không kết hợp dữ liệu do người dùng kiểm soát vào URL này.

  • Bảo vệ thông báo bắt tay WebSocket chống lại CSRF, để tránh các lỗ hổng chiếm quyền điều khiển WebSocket trên nhiều trang web.

  • Xử lý dữ liệu nhận được qua WebSocket là không đáng tin cậy theo cả hai hướng. Xử lý dữ liệu một cách an toàn trên cả máy chủ và máy khách, để ngăn chặn các lỗ hổng dựa trên đầu vào như SQL injection và cross-site scripting .

PreviousCross-origin resource sharing (CORS)NextClickjacking (UI redressing)

Last updated