CSRF prevention by “SameSite” flag

CSRF is very deadly attack vector for the sensitive application operations like password change, profile update, banking transactions etc. It allows an attacker to set a page with payload on cross domain and mass exploitation by forcing users to compromise their session by leveraging cookie replay.

We covered this topic extensively over years - http://blog.blueinfy.com/search/label/CSRF

Web browsers are now supporting an added attribute called “SameSite” to the cookie and this attribute controls the replaying of the cookie. Before this addition, browser used to replay cookies if origin/domain is the same.

Hence, while setting up the cookie if directive is used as shown below.

Set-Cookie: key=value; SameSite=strict

This flag has a set of values as below with respective impact.

a.) If value is set to strict like “SameSite=strict” then cookie will replay only in case of same domain. Hence, if page is hosted on different domain and code on the page initiate GET/POST requests then these requests will not replay the cookie. Hence, application is protected against CSRF.

b.)If value is set to lax like “SameSite=lax” then cookie will replay in a few cases like link, rel or form with GET method. Hence, only GET request will replay the cookie in case of cross domain origin. CSRF for all other critical forms and POST requests will be blocked since browser will not replay the cookie from the browser.

Conclusion

It is imperative for critical applications to block CSRF attacks and there are several mesuares for it. One can apply tokens for every critical POST call and validate before processing the request. One can also put in place CAPTCHA to stop automated processing as well. For all these controls one needs to apply server side programming and strong defenses. “SameSite” cookie is an interesting browser side flag to kill CSRF right at the source. If cookie is not going to replay then CSRF gets killed and attacker can not host cross domain payload to perform mass CSRF exploitation.  

JSON Hijacking & Two Way CSRF (update)

CSRF is a common attack vector when forms are not validated for the origin of the requests and not having unique tokens attached to the identifity. In modern times it is also possible to hijack streams like JSON.  It creates possible scenario to do a two way CSRF using XHR/HTML5 methods.

You can go over slides for that as below.

In the past, it was possible to use tricks and vulnerabilities like object overloading/overriding (get/set) for <script> as discussed below slides. 

In past few years lot of research and tricks being developed to hijack JSON streams with CSRF. Recently, researcher at Burp (@garethheyes) came up with a way to steal JSON stream by hijacking cross domain calls.

Here is the write up - 

http://blog.portswigger.net/2016/11/json-hijacking-for-modern-web.html (here)

Alos, slides can be found over here - 

https://www.owasp.org/images/6/6a/OWASPLondon20161124_JSON_Hijacking_Gareth_Heyes.pdf (Here)

It is important vector to cover in pentesting and SDLC defense.

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

Talks on HTML5 Security (HITB and AppSecUSA 2012)

HITB KUL 2012 Talk on HTML5

OWASP AppSecUSA 2012 Talk

XSS & CSRF with HTML5 - Attack, Exploit and Defense - Shreeraj Shah from OWASP AppSec USA on Vimeo.

XSS & CSRF with HTML5 - Attack, Exploit and Defense

HTML5 has empowered browser with a number of new features and functionalities. Browsers with this new architecture include features like XMLHttpRequest Object (L2), Local Storage, File System APIs, WebSQL, WebSocket, File APIs and many more. The browser is emerging as a platform like a little operating system and expanded its attack surface significantly. Applications developed in this new architecture are exposed to an interesting set of vulnerabilities and exploits. Both traditional vulnerabilities like CSRF and XSS can be exploited in this new HTML5 architecture. In this talk we will cover following new attack vectors and variants of XSS and CSRF.

HTML5 driven CSRF with XMLHttpRequest (Level 2)
CSRF with two way attack stream
Cross Site Response Extraction attacks using CSRF
Cross Origing Resource Sharing (CORS) policy hacking and CSRF injections
DOM based XSS with HTML5 applications
Exploiting HTML5 tags, attributes and events
DOM variable extraction with XSS
Exploiting Storage, File System and WebSQL with HTML5 XSS
Layered XSS and making it sticky with HTML5 based iframe sandbox
Jacking with HTML5 tags and features

In this session we will cover new methodology and tools along with some real life cases and demonstration. At the end we will cover some interesting defense methodologies to secure your HTML5 applications. My slides are as under (I will post video once get released)

XSS and CSRF with HTML5 from Shreeraj Shah

CSRF with upload – XHR-L2, HTML5 and Cookie replay

XHR level 2 calls embedded in HTML5 browser can open a cross domain socket and deliver HTTP request. Cross Domain call needs to abide by CORS. Browser will generate preflight requests to check policy and based on that will allow cookie replay. Interestingly, multi-part/form-data request will go through without preflight check and “withCredentials” allows cookie replay. This can be exploited to upload business logic files via CSRF if server is not validating token/captcha. Business applications are allowing to upload files like orders, invoices, imports, contacts etc. These critical functionalities can be exploited in the case of poor programming.

If we have a business functionalities for actual upload form then this type of HTTP request will get generated at the time of upload. Note, cookie is being replayed and request is multi-part form.

Now, if CSRF payload has following XHR call.

Above call will generate following HTTP request and causes CSRF and upload the file. Hence, without user’s conscent or knowledge cross domain file being uploaded on the target application with the logged in credential.

Future probes – one needs to check other impact like AMF stream uploading, XML file transfer and few other library protocols which is now a day’s dealing in multi-part to support binary calls.

If you are interested in this analysis should visit @kkotowicz work - http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html.  

CSRF with JSON – leveraging XHR and CORS

Same Origin Policy (SOP) dictates cross domain calls and allows establishment of cross domain connections. SOP bypasses allow CSRF attack vector, an attacker can inject a payload on cross domain page that initiate a request without consent or knowledge of the target user. HTML 5 is having one more policy in place called CORS (Cross Origin Resource Sharing). CORS is a “response blind” technique and controlled by extra added HTTP header “orgin” and their variants but it allows request to hit the target in one way direction. Hence, it is possible to do one-way CSRF. It is possible to initiate CSRF vector using XHR-Level 2 on HTML 5 pages and can prove really lethal attack vector. XHR establishes a stealth connection and remains much hidden, XHR connection can be set using “withCredentials” as true along with POST method. It allows cookie to replay and helps in crafting successful CSRF scenario or session riding. Interestingly HTML 5 along with CORS allows performing file upload CSRF as well. It is possible to craft a JavaScript using XHR and inject JSON payload as cross domain. If server side code on JSON library is not validating the “Content-Type” then it will process the request and allows successful CSRF.

For example,

Here is a script which will do CSRF on cross domain.

Here, we have “Content-Type” as “text-plain” and no new extra header added so CORS will not initiate OPTIONS to check rules on the server side and directly make POST request. At  the same time we have kept credential to “true” so cookie will replay.

On the wire we can see following request.

As you can see cookie is replayed and JSON POST has been initiated. We get following response back from application.

Application processed the request and sent JSON back. It is clear case of CSRF. This can be applied to other streams as well.