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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

4. XSS
   • Cross Site Scripting
   • Script one site from other
   • Three major kinds
   Reflected XSS
   Persistent XSS
   DOM based XSS
   • Exploits the user.
   

   View Slide

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
   

   View Slide

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
   eval('alert("XSS")')
   Credits: @irsdl and @ma1
   

   View Slide

7. (gulp gulp)
   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
   

   View Slide

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
   

   View Slide

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.
   

   View Slide

10. More XSS channels
    • Plugin based XSS
    • Flash, Adobe Reader et al
    • Add Charset problems like UTF-7 injection,
    Shift-JIS et al
    

    View Slide

11. Why do we solve the problem in the server side
    while the attack is happening in the client side?
    O_o
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

14. Problem 1
    How do I know whether an attacker somewhere
    has somehow found a successful XSS bug in
    my website?
    

    View Slide

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, ‘> is
    a more widely used xss testing vector,
    because of its simplicity and multi-context
    nature.
    

    View Slide

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.
    

    View Slide

17. United we stand.
    Attacker driven testing.
    So lets check for XSS bugs in a different way.
    

    View Slide

18. View Slide

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.
    

    View Slide

20. Redefining alert()
    window.alert = function(){
    report_security_team();
    return 0;
    }
    Or
    window.__defineGetter__(‘alert',
    function(){
    return false;
    });
    alert(1)
    

    View Slide

21. View Slide

22. The Bypass
    This payload can bypass the report_security_team()
    delete(alert);
    alert(1);
    ‘delete’ operator resets and overwrites the
    Object;
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

25. XDS Architecture
    Browser Apache
    Server
    PhantomJS
    Lua Rules
    ModSecurity
    PhantomJS PhantomJS
    XDS DB +
    Emails
    security
    team
    

    View Slide

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 
    

    View Slide

27. Lets discuss !
    Thanks for being here
    

    View Slide

28. View Slide