The perceptions that critical operations are performed on the server side and that all data is stored there are incorrect. What many browsers do today involves reaching out over an unencrypted connection to an unverified site, grabbing code and executing it.
1) DOM-based cross-site scripting (XSS)
Most security professionals are familiar with cross-site scripting (XSS). While XSS is usually the result of insecurely written server-side code, DOM-based XSS is a kind of XSS occurring entirely on the client-side. With server-side XSS vulnerabilities getting fixed, a shift in focus towards DOM-based XSS is indicated. DOM-based XSS is more serious than ordinary XSS attacks, since such scripting cannot be filtered through a web-application firewall (WAF).
- Location-based, such as location, location.href, document.URL and so on.
- Client-side storage based. For instance, it could be document.cookies, sessionStorage and localStorage.
- Navigation-based, such as navigation.referrer, window.name, history et al.
- Cross-domain functions.
- Execution-based, such as eval(), Function(), setTimeout(), setInterval() and so on.
- URL-based, for instance location and location.assign().
- HTML-based, such as document.write(), HTML elements and attributes.
DOM-based XSS usually happens when source data is put into a sink without proper validation. Sink functions such as eval(), setTimeout() and setInterval() are dangerous, since they make it possible to execute even text passed through them. The input to these functions is controlled completely on the client-side. Completely eliminating the use of eval() is strongly recommended. If used, no user controlled data must be passed through these functions.
In order to mitigate DOM-based XSS it is a good policy to avoid using sources/sinks whenever possible. When unavoidable, perform rigorous white-list based filtering on sources and perform proper encoding before sending data to a sink.
2) Cross-domain information leakage
Prior to HTML5, cross-domain requests were handled using JSON callbacks. Using callback functions in APIs should only be allowed with discretion in cases where the information in question needs to be shared with any and all external parties. Turn these features off when not needed.
3) Client-side logic and data storage
This can tempt developers to consign sensitive operations to the client-side. While this is unavoidable in some scenarios, it may also be intended to offload processing to the client-side and save server-time and bandwidth.
About the author: Lavakumar Kuppan is the author of IronWASP, an advanced Web security testing platform. He has also authored multiple other security tools like 'Shell of the Future', JS-Recon, Imposter and the HTLM5 based distributed computing system—Ravan. As a security researcher, Lavakumar has discovered novel attacks that include a sandbox bypass on Flash Player, WAF bypass technique using HTTP parameter pollution, multiple HTML5 attacks and a CSRF protection bypass technique using CickJacking & HPP. His research and tools are available at the Attack and Defense Labs website.
(As told to Varun Haran)
This was first published in October 2012