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

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.

6932fd8236cec12354ba8230c0e80d81?s=128

Ahamed Nafeez

September 29, 2012
Tweet

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.
  18. None
  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>
  21. None
  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

  28. None