未加星标

Security Testing HTML5 WebSockets

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二05 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

Recently I became faced with my first Web Application Security Assessment which relied heavily on html5's WebSockets .

The first clue that the application was using WebSockets was when the application kept giving me a timeout error while using my proxy of choice, Burp Suite . Looking at the HTTP requests/responses in Burp I noticed that a large javascript file was requested and downloaded from the server. Within this file I noticed a URL with the ws:// scheme, the WebSocket scheme.

TCP/HTTP?

The initial WebSocket handshake is carried out over HTTP using an ' upgrade request '. After the initial exchange over HTTP all future communication is carried out over TCP. On the application I was testing the WebSocket handshake over HTTP within WireShark looked like this:

Request:

GET /SocketHandler HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 Sec-WebSocket-Version: 13 Origin: http://www.example.com Sec-WebSocket-Key: iiral7et1zfQMGu9udIYHA== Cookie: Login=1234567 Connection: keep-alive, Upgrade Upgrade: websocket Content-length: 0 Host: www.example.com

Response:

HTTP/1.1 101 Switching Protocols Upgrade: Websocket Server: Microsoft-IIS/8.0 Sec-WebSocket-Accept: 9ZPK0lC0SB6dhIJHRt3q/GN88Ng= Connection: Upgrade Date: Fri, 30 Aug 2013 13:33:42 GMT

Capturing WebSockets

For some reason the WebSocket handshake was not captured by Burp's Proxy (even though the WireShark capture shows that the handshake was over HTTP), however, it can be viewed within Google Chrome's Developer Tools and OWASP's ZAP Proxy .

Using this example WebSocket application (which is vulnerable to ' Self-XSS ' BTW) you can see that Google Chrome's Developer Tools captures the initial WebSocket handshake:


Security Testing HTML5 WebSockets

And also the subsequent WebSocket communication (frames) over TCP:


Security Testing HTML5 WebSockets

If you want to fuzz and replay WebSocket communications you can use OWASP's ZAP Proxy which supports capturing and replaying WebSockets.

Encryption (SSL/TLS)

WebSockets can be used over unencrypted TCP or over encrypted TLS. To use unencrypted WebSockets the ws:// URI scheme is used (default port 80), to use encrypted (TLS) WebSockets the wss:// URI scheme is used (default port 443).

Here you probably want to look out for the OWASP Top 10 2013 A6-Sensitive Data Exposure type issues. Is sensitive data being transported over unencrypted channels? Has SSL been implemented securely?

Origin

It is the web server's responsibility to verify the Origin header in the initial HTTP WebSocket handshake. If the Origin header is not properly checked, the application may be vulnerable to OWASP Top 10 2013 A8-Cross-Site Request Forgery (CSRF) .

There's a great blog post here describing a 'Cross-Site WebSocket Hijacking' technique which is possible when the application/server does not check the Origin header.

I also created a WebSocket client which can be used to test origin issues which can be found here .

Authentication

WebSockets do not handle authentication, instead normal application authentication mechanisms apply, such as cookies, HTTP Authentication or TLS authentication. Here you probably want to check for OWASP Top 10 2013 A2-Broken Authentication and Session Management type issues.

Authorisation

WebSockets do not handle authorisation, normal application authorisation mechanisms apply. Here you want to test for OWASP Top 10 2013 A4-Insecure Direct Object References and OWASP Top 10 2013 A7-Missing Function Level Access Control .

Input Sanitisation

As with any data originating from untrusted sources the data should not be trusted. The OWASP Top 10 2013 A1-Injection and the OWASP Top 10 2013 A3-Cross-Site Scripting (XSS) issues would apply here.

There's a great post here showing how an XSS issue on a page can be used to compromise WebSockets to eavesdrop on the WebSocket communications by modifying the JavaScript WebSocket functions.

Conclusion

Testing WebSockets can seem daunting when you first come across them during a Web Application Security Assessment. Hopefully you now have some insight of how WebSockets work, what tools you can use and what security issues to look out for.

I have probably not covered all bases here and I'm sure there is a lot more to be discussed surrounding testing WebSockets during a Web Application Security Assessment. If you think that I have missed anything out, please comment below!

Further Reading

https://tools.ietf.org/html/rfc6455

https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet

http://www.digininja.org/blog/zap_web_sockets.php

http://www.digininja.org/blog/zap_fuzzing.php

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

主题: WebSocketHTMLHTML5JavaScriptJavaChromeQMGMFirefox
分页:12
转载请注明
本文标题:Security Testing HTML5 WebSockets
本站链接:http://www.codesec.net/view/480540.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(32)