alert(/xss/) – How to catch an XSS before someone reports or exploits it?

This paper talks about an XSS detection system which helps find the XSS bug as soon as someone has triggered it somewhere. There were similar client side techniques in the past which have failed miserably. This is a server side detection system which alerts the security team when a certain XSS payload is successfully triggered by anyone, anywhere, even if its for the first ever time. This helps the security team go ahead and fix the issue before someone even reports the bug to them.

Transcript

1. alert(/xss/) – How to catch an XSS before someone reports or exploits it? Ahamed Nafeez
2. Introduction Ahamed Nafeez • Security team @ Citrix • Bug hunter @ Facebook, Google, Adobe and a few others in the past • WebApp Sec Researcher • Twitter @skeptic_fx • Sporadic musings @ blog.skepticfx.com
3. /Content/ • XSS and mitigations in place • Catching those exotic vectors • ECMAScript5 and the DOM • Using the browser to detect things • More about the future
4. XSS • Cross Site Scripting • Script one site from other • Three major kinds Reflected XSS Persistent XSS DOM based XSS • Exploits the user.
5. Mitigations On the server Built-in encoding libraries htmlentities() et al. Filtering libraries: HTMLPurifier, AntiSamy WAFs: modsecurity et al On the client Browser based XSS Filters - IE8 XSS Filter, WebKit XSS Auditor, Firefox is on its way Content Security Policy NoScript et al
6. (gulp) • IE’s XSS Filter + Proper encoding + WAFs in place 〈scrıpt〉ℯval(＇alℯrt(”XSS”)ˈ)〈/scrıpt〉 • Homoglyph + Classic ASP.NET = Bad Times • Classic ASP translates %u3008scr%u0131pt%u3009%u212fval(%uFF07al%u212Frt(%22XSS%22)%u0 2C8)%u2329/scr%u0131pt%u232A into <script>eval('alert("XSS")')</script> Credits: @irsdl and @ma1
7. (gulp gulp) <svg/onload=domain=x (or) ‘domain=x What? Short + No Space + nothing that fishy + bypasses most rules + Arbitrary Payload How? Child iframe/window + Webkit bug = SOP Bypass / XSS havoc By: Me and @jackmasa
8. more (gulp) inside JS $=''|'',_=$+!"",__=_+_,___=__+_,($)[_$=($$=(_$=""+{})[__+__+_]) +_$[_]+(""+_$[- __])[_]+(""+!_)[___]+($_=(_$=""+!$)[$])+_$[_]+_$[__]+$$+$_+(" "+{})[_]+_$[_]][_$]((_$=""+!_)[_]+_$[__]+_$[__+__]+(_$=""+!$)[ _]+_$[$]+"("+_+")")(); • Non-Alphanumeric JS • Encoding won’t help sometimes • Different set of non-alpha JS possible. (Too bad ) Credits:Hasegawa Yosuke, Gareth Heyes and few others
9. Impedance mismatch • Server interprets the payload in someway • Filters interpret in some other way • The user agent parses it in a totally different way. A scenario where the first layer deploys the attack and the other executes it.
10. More XSS channels • Plugin based XSS • Flash, Adobe Reader et al • Add Charset problems like UTF-7 injection, Shift-JIS et al
11. Why do we solve the problem in the server side while the attack is happening in the client side? O_o
12. Things to keep in mind • New spec drafts + features = Extending the attack surface + more exotic vectors • More impedance mismatches with server side features – HPP, PHP’s PATH_INFO • Browser bugs + Quirky JavaScript • Scriptless attacks • XSS is becoming more and more complex
13. Why am I here? • We’ll try to solve two different problems. 1. How do I know whether there is an XSS hole in my system? Moreover, how do I know whether somebody knows about it already? Do I have an endpoint which are vulnerable to specific advanced vectors? 2. How do I protect my users from these unknown XSS holes being exploited?
14. Problem 1 How do I know whether an attacker somewhere has somehow found a successful XSS bug in my website?
15. Fact is fact • During manual tests, how many of you here use vectors other than alert() / prompt() while probing for an XSS? • Seems like, ‘><img src=x onerror=alert(1)> is a more widely used xss testing vector, because of its simplicity and multi-context nature.
16. Lets talk about a scenario • We have an internet facing website where code is pushed frequently. • Some XSS bugs have slipped through the door before the security team can take a look at it. • An attacker finds the XSS hole.
17. United we stand. Attacker driven testing. So lets check for XSS bugs in a different way.
19. The Idea Redefine the functions used for XSS test vectors – alert(), prompt(), console.log() et al. Inject the code on top of the responses. Parse the modified response in a reliable browser environment. The redefined functions when triggered alerts the security team about a new XSS hole.
20. Redefining alert() window.alert = function(){ report_security_team(); return 0; } Or window.__defineGetter__(‘alert', function(){ return false; }); <script>alert(1)</script>
22. The Bypass This payload can bypass the report_security_team() delete(alert); alert(1); ‘delete’ operator resets and overwrites the Object;
23. Say Hi to ES5 Object Extensions ES = ECMAScript Mario Heiderich did some interesting research on locking down the DOM. New features allows us to lock the objects to the DOM safely (Well, Safe? Yea, At least in our scenario) The option, configurable:false does what we want here.
24. Redefining functions using ES5 Object.defineProperty(window, ‘alert’, { get: function(){report(); return function(){}}, set: function(){return false;}, configurable:false }); ‘configurable:false’ disables further deleting / tampering of the Object.
25. XDS Architecture Browser Apache Server PhantomJS Lua Rules ModSecurity PhantomJS PhantomJS XDS DB + Emails security team
26. Future The list of attack vectors can really help researching new vectors. DOM IDS DOM security is at its infancy. ES6 and future can harden it more 
27. Lets discuss ! Thanks for being here