Based in Cologne
CTO for Business IN Inc - working on workube.com
Independent Security Researcher
PHPIDS and something we will see later on
4. Why this talk?
What happened to web application security?
Always the same... so 2002 right?
XSS, SQL Injections, Auth and path traversal
We have amazing things now!
NoScript, the IE8 and Chromium XSS filter and CSP
Users must be safer than ever!
But didn't the web change?
Wasn't there HTML5 and next generation browsers?
5. Oh wait - developers!
Web app development frameworks help
Building applications faster
Pre-implemented SQLI and XSS protection
Secure forms with complex CSRF tokens
Webroot contains webroot only files
Client side logic mostly built manually
Different templates for browsers, mobile devices, feeds
Offline mode, client side validation, DOM access
6. User Agents on steroids
Chrome 5 and Opera 10.5 ship client side databases
IE9 is coming soon with more standards conformity
Integrated security mechanisms
The death of eval()
A fat client dynasty is coming up
Who needs a server anyway if clients do all the work
And store their data in „the cloud“
Bye bye SQL - say hello to NoSQL?
7. Web applications are changing
And so are the attacks against them
If the attack happens on and against the client
Of what use will a server side IDS / WAF solution be?
Today we can have a little preview for that scenario
One question might be...
How will protective mechanisms react on multi-layer
8. Multi-layer what?
What about utilizing the DBMS to generate an XSS attack
NoScript detects most XSS attacks without problems
Circumvention has become very difficult
Thanks to Giorgio Maone and the NoScript user base. And me :P
Let's have a look at my last one (disclosed via SSD - fixed in 18.104.22.168)
Aren't dataURIs the sweetest thing?
<a href="data: . , %
c s cri
pt % 3 e alu0065rt(1)%3c
/s C RI 	 P t>"
We can probably agree that it's not as easy anymore
Same thing for the IE8 XSS filter
Or implementations of toStaticHTML()
Not too many user agent specific surprises anymore
Help from another layer would be appreciated
Let's have a look at a "classic webapp" example
10. Imagine the DBMS helps
A verbose SQL Injection vulnerability is always at least an
Just make use of the obfuscation possibilities the DBMS
11. MySQL and PostgreSQL
MySQL only ships two basic XML functions
UpdateXML() and ExtractValue()
PostgreSQL has far more advanced XML support
SELECT xmlelement(name img,xmlattributes(1 as
SELECT xmlforest(loWER('x41'||'lert(1)') AS
And my favorite
12. SQL Injection and XSS
There are more intersections for XSS and SQLI
„Remember“ the client side databases?
And the short lived Google Gears?
HTML5 and W3C Offline Web Applications 1.0 give us
SQL execution on the user agent
Currently supported by Chrome and Opera
Usually implemented using SQLite
14. Short Roundup
The browsers speak SQL now
We already outsmarted NoScript and IE8 XSS filter
Not really a fair game though
Multi-layer attacks mean multi-layer obfuscation
In future webapps the client side DBMS will generate our XSS
But today we still have to trick the server side protection
Bypass IDS and WAF with a trigger
15. Attackers like obfuscation
And why wouldn't they - right?
Obfuscation usually means concatenation
And a bit of encoding spice
But how to concatenate in SQL so no one will notice the attack?
Which operator to choose?
Everybody knows chr(), char() and double-pipe...
16. In MySQL - none at all
MySQL doesn't need parenthesis to concatenate
And doesn't know the double-pipe operator
But luckily MySQL accepts concatenation via whitespace
SELECT "a" "d" "m" "i" "n"
Or why not use an integer overflow in char()
SELECT concat( char( x'70617373',
17. So again...
We can bypass the server side protection mechanisms
As well as client side tools
No parenthesis or special operators needed on MySQL
We can also trick MySQL and the IDS with MySQL specific code
18. Back to the user agent
But what if no server side DBMS is involved in the attack
What if the client side database is being targeted
side IDS and the client side security mechanisms
Let's have a look at some freaky examples
19. Remember dataURIs?
The whole requested resource embedded in the URI
DataURIs work smoothly on Firefox, Opera and Chrome
But IE8 and 9 have problems
Some say the minimal dataURI support was just for ACID 2
20. People say...
Do we agree on that?
No we don't!
<link rel="Stylesheet" href="data:,*
21. And there's more
CSS expression() is believed to be dead on IE8
But it isn't
It's only disabled in standard mode
In case a recognized DOCTYPE is present
The new HTML5 doctype isn't
So this works:
22. And even worse...
HTML5 forces user agents to be more tolerant again
New tags, new attributes, new parsing rules
And tons of new features like the mentioned
Some nifty examples from the future
23. Closing tags + free 0day
Another weird artifact has been reported for IE6 some
It's attributes in closing HTML tags
Believed to be dead... but
This still works on all IEs
And what about this?
24. Opera CSS XSS
Since Mozilla fixed the dataURI and cross domain
problems with -moz-binding IE was believed to be
But Opera ships an artifact too
25. Now we have...
Server side SQL helping to circumvent client side XSS filters
Effective SQL obfuscation circumventing WAF and IDS
"Obfuscation-mash ups" using several layers
Quirky HTML triggers to execute the JS
Sounds like only one player is missing
Even more freaky markup obfuscation! Awesome! Now breathe..
26. Meet Harold the markup ghoul
This is Harold:
1;--<?f><l ￦ :!!:x
:url(#default#time2)ö/';'` ￦ /onb
It's completely legitimate to call me a mad man now and say this is
never gonna work
So - demo time: http://heideri.ch/jso/what???
27. What... what is this?
It's a piece of markup – obfuscated to the max
Working on IE only – but all versions from 5 to 9
Based on the HTML+TIME API (What? Stuff like that still exists?)
Does your WAF know what to do with it?
Overall about 12-13 obfuscation steps
Buy me a beer later on and I will give you a full
28. Round Up
We are not living in web app = CRUD application times anymore
Modern webapps accept input from many channels
User input via HTTP is just one of them
API calls, RPC, DOM, Drag&Drop, file meta data & EXIF...
WAF/IDS as well as pentesters need to look into HTML5
New application structures and design pattern must be
Client and server versus rich-client and cloud
SQLite and NVP versus RDBMS
Massive client diversity via mobile devices
29. Expectations and tasks
Fewer basic and reflective XSS
More out-of-band attacks and heavy obfuscation
We didn't even cover Flash and PDF
More JSON and E4X hijacking
SVG based attacks and rogue multimedia objects
Don't ignore the user agent
Understand client side obfuscation and multi-layer obfuscation
Don't trust filters. Ever.
We broke HTMLPurifier and most other markup filters some days
ago with one single vector
And don't trust the cloud – it's a business model and not your
30. So what can I do?
Help with research and participation!
Communication and disclosure
32. Ping us!
Add new vectors
Get a channel to speak to vendors
Most are more responsive than one might think
Use it for..
Your own scanner software
Your own local version
Whatever you want!
Open API in JSON
You need more? Tell us!
35. Yaaaaaaay! Goodies!
Did you know Firefox has a DOM object called crypto?
And another eval() for free!