Slide 1
Slide 1 text
alert(/xss/) –
How to catch an XSS before someone reports or
exploits it?
Ahamed Nafeez
Slide 2
Slide 2 text
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
Slide 3
Slide 3 text
/Content/
• XSS and mitigations in place
• Catching those exotic vectors
• ECMAScript5 and the DOM
• Using the browser to detect things
• More about the future
Slide 4
Slide 4 text
XSS
• Cross Site Scripting
• Script one site from other
• Three major kinds
Reflected XSS
Persistent XSS
DOM based XSS
• Exploits the user.
Slide 5
Slide 5 text
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
Slide 6
Slide 6 text
(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
Slide 7
Slide 7 text
(gulp gulp)
Slide 8
Slide 8 text
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
Slide 9
Slide 9 text
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.
Slide 10
Slide 10 text
More XSS channels
• Plugin based XSS
• Flash, Adobe Reader et al
• Add Charset problems like UTF-7 injection,
Shift-JIS et al
Slide 11
Slide 11 text
Why do we solve the problem in the server side
while the attack is happening in the client side?
O_o
Slide 12
Slide 12 text
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
Slide 13
Slide 13 text
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?
Slide 14
Slide 14 text
Problem 1
How do I know whether an attacker somewhere
has somehow found a successful XSS bug in
my website?
Slide 15
Slide 15 text
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.
Slide 16
Slide 16 text
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.
Slide 17
Slide 17 text
United we stand.
Attacker driven testing.
So lets check for XSS bugs in a different way.
Slide 18
Slide 18 text
No content
Slide 19
Slide 19 text
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.
Slide 20
Slide 20 text
Redefining alert()
window.alert = function(){
report_security_team();
return 0;
}
Or
window.__defineGetter__(‘alert',
function(){
return false;
});
alert(1)
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
The Bypass
This payload can bypass the report_security_team()
delete(alert);
alert(1);
‘delete’ operator resets and overwrites the
Object;
Slide 23
Slide 23 text
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.
Slide 24
Slide 24 text
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.
Slide 25
Slide 25 text
XDS Architecture
Browser Apache
Server
PhantomJS
Lua Rules
ModSecurity
PhantomJS PhantomJS
XDS DB +
Emails
security
team
Slide 26
Slide 26 text
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
Slide 27
Slide 27 text
Lets discuss !
Thanks for being here
Slide 28
Slide 28 text
No content