Thursday, September 24, 2015

HTML5 – Hazards and Defense – Podcast with Brakeing Down Security

Part 1 -  2015-039: Hazards of HTML5

Shreeraj Shah (@shreeraj on Twitter) came on this week to give us a run-down of some of the issues with HTML5? How can a new standard actually be worse than something like Flash? And why would a standard not address existing OWASP issues, and even create new issues, like the ability of a browser to have a database inside of it managing everything?

This week we discuss HTML5 history, some of the pitfalls, and discuss some of the new technologies found in HTML5 that will create more headaches for agents of infosec.

Listen the Podcast over HERE

Part 2 -  2015-040; Defending against HTML 5 vulnerabilities

Last week, we discussed with Shreeraj Shah about HTML5, how it came into being and the fact that instead of solving OWASP issues, it introduces new and wonderful vulnerabilities, like exploiting locally stored web site info using XSS techniques, and doing SQLI on the new browser WebSQL.
So this week, it's all about defensive techniques that you can use to educate your developers against making mistakes that could get your company's web application on the front page of the news paper.

Listen the Podcast over HERE

You can find various articles on this topic and issues covered during the session over here.

1. Next Generation Application Architecture & HTML5
2. HTML5 features in a nutshell
3. HTML5/Browser Evolution and Threats
4. Cross Origin Resource Sharing Policy and its impact
5. CSRF and Cross Domain Response Extraction in Era of CORS
6. WebSocket Security - Protecting streams Over HTTP
7. Attack Vectors and Threats for HTML5 Storage (note)
8. Talks on HTML5 Security (HITB and AppSecUSA 2012)
9. XSS & CSRF with HTML5 - Attack, Exploit and Defense
10. File System API with HTML5 – Juice for XSS
11. CSRF with upload – XHR-L2, HTML5 and Cookie replay
12. Blind WebSQL and Storage extraction for HTML5 Apps
13. Cross Origin Resource Jacking (CORJacking) - DOM based attack vector
14. Top 10 HTML5 Threats & Attack Vectors

Also, at OWASP we are maintaining HTML5 cheatsheet which you can find it over.

HTML5 OWASP cheat Sheet

Enjoy!

Friday, September 4, 2015

WebSocket Security - Protecting streams Over HTTP

WebSocket is gaining popularity with HTML5 architecture and has wide support from various browsers now. WebSocket allows full duplex communication over TCP as defined in the RFC 6455. Applications need such fast connection with data push coming from servers over polling data time to time. Hence, during our testing we started getting applications running WebSocket. It is imperative to understand the threat model for WebSocket usage and some of the concerns. In this post we try to address this.

WebSocket support and overview

The WebSocket protocol has been defined in RFC 6455 (http://datatracker.ietf.org/doc/rfc6455/?include_text=1) along with the WebSocket API (https://w3c.github.io/websockets/).  Hence, it is possible to use API via JavaScript and embed code right into HTML pages. As soon as a connect call is made by the browser, the HTTP Server switches to WebSocket protocol when it come across an "Upgrade" request call from the client on the same TCP connection. Applications support WebSocket calls via specific URLs like ws:// and wss:// on the pages.

WebSocket has become an integral part of Browser's communication stack as shown below.
We covered a post in the past on new Architecture over here ( HTML5/Browser Evolution and Threats)



Following is a simple upgrade call coming from a browser to a HTTP server.

GET / HTTP/1.1
Host: x.x.x.x
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Sec-WebSocket-Version: 13
Origin: http:// x.x.x.x
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: Ru+jZkzO8cdIIHtoe8b80g==
Connection: keep-alive, Upgrade
Upgrade: WebSocket

Now, if the server is supporting the protocol then it will allow switching by the following response.

HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: uRxNF7tq3wE+y/7EJjPbk1bPB5w=


Hence, at this point a tunnel is established and bi-directional communication can begin between client and server.If we look at API, then it is simple. Initializing WebSocket object

var WS = new WebSocket(“ws://api.target.example”);

Once that is done one can go ahead and use methods like onopen(), onmessage(), send() and close().

If you want to dig more into WebSocket –
http://www.html5rocks.com/en/tutorials/websockets/basics/

WebSocket usage

We have traditional web applications running over HTTP request and response. One of the problems with traditional usage of HTTP is of refresh and reload. Ajax helped, in a way, to solve this problem by making a quick async call and updating DOM. But in this mechanism, there is polling involved and it is not truly a faster bidirectional channel between the two. To improve overall efficiency one can use WebSocket in cases like the following :

1.     Multiuser gaming or chatting applications
2.     Pushing multimedia like voice, music, videos or large blobs
3.     Real-time updates like financial tickers, sports, tracking, feeds etc.

Also, developers are becoming innovative and utilizing JSON, XML etc. over WebSocket. Hence, there is no limit to how and where WebSocket calls can be used.

WebSocket threats and security concerns

WebSocket has some inherent weakness like allowing cross domain calls and few other issues. Hence, it is important to properly assess the threat model at development stage. Here are few issues one should check during testing -

Cross Domain Calls and Origin Checking

By design, WebSocket protocol doesn’t abide by SOP (Same Origin Policy). Hence, a browser can initiate a cross domain WebSocket call to any domain on the Internet. It is not required for an application to make calls to its own domain only. This can create issues and security threats. It allows an attacker to establish a connection or force any victim’s browser to initiate a connection as well. When WebSocket makes an “upgrade” call over HTTP, it sends “Origin: domain” header in the HTTP request. The browser itself adds this particular header based on its current state of DOM/location. This header cannot be tampered with by script. Hence, to avoid DoS and CSRF type attacks one can validate this header on server side before switching the protocol. Also, it is possible to perform DoS by opening multiple socket connections. One can avoid that by passing a token to the browser before protocol switching. Hence, only if protocol/upgrade switching request comes to the server with that token the server should allow the connection. This will avoid possibility of DoS.

CSRF with WebSocket and Stream hijacking

As discussed in the previous section about “Origin”, WebSocket is not following SOP. This allows an attacker to put a dummy page on Internet and drive someone to that particular page. As shown in the below figure, an attacker can leverage the following scenario:

  1. A user logs in to the system and establishes a session with proper authentication. User’s browser gets a cookie from the server for that particular application bound to the application domain. This cookie is going to replay in all other requests going from browser to the target domain.
  2. Application may establish legitimate WebSocket session as and when needed as shown in step 2 of the figure.
  3. Now, an attacker comes into picture and there is a page created with WebSocket calls pointing to the target application domain. If a user with an established session visits that page, like in traditional CSRF scenario, then he ends up establishing a WebSocket session since the cookie is going to replay. This allows the attacker to have a virtual tunnel created as shown in the figure. It is also important to observe over here that this session is two-way CSRF. In traditional CSRF we just get write/post access but in this case, since WebSocket is not following CORS either, the attacker is also allowed to read incoming stream from server. Hence, he ends up getting both read and write mechanism on stream. This ends up being stream hijacking.
Figure 1 – CSRF over WebSocket Streams

You can read more on this below. This attack is termed as CSWSH (Cross Site WebSocket Hijacking)
https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html

Again, for defense one can verify “Origin” and add extra CSRF tokens to validate legitimate users for stream processing.

WebSocket and SSL

It is also important to know on which tunnel WebSocket is running. One needs to make sure that it is running over SSL channel. If calls are going over a non-SSL channel then it may end up leading to information leakage and other related attack vectors.

WebSocket and input validations

A WebSocket call fetches new data from a server and dynamically loads things in the existing DOM with various APIs. It is imperative to validate incoming content before loading into DOM and protect against DOM based XSS and other types of variants. Also, it is obvious to protect server side injections and streams going over DOM calls. Burp and ZAP both have capability for evaluating WebSocket calls.

WebSocket review Cheat Sheet

Following checks and validation can be made for WebSocket review :
  • Version check for browser and required support.
  • Application level authentication and authorization for sensitive data transfer.
  • Endpoint security with having wss://
  • DOM based protection by JSON.parse() over eval()
  • Validating “Origin:” at server end
  • CSRF type protection in place for streams

Conclusion

The WebSocket protocol is a really good and efficient way for communication in certain scenarios, but at the same time it brings a new set of threats. Hence, developers have to keep security issues in mind during implementation both at server as well as client end. Now a days, there are many applications on the Internet which are using WebSocket heavily. Also frameworks and technologies like Microsoft’s signal.r are based on WebSocket. There are many libraries available for implementation of WebSocket on the server side, but by default they do not check for security issues. Hence, one needs to keep security issues in mind while implementing them and while performing reviews.


Article by Amish Shah & Shreeraj Shah