SecTor '09 - When Web 2.0 Attacks!
1 like•500 views
The document discusses the security vulnerabilities inherent in Web 2.0 technologies such as AJAX and Flash, emphasizing that traditional web developers are often not involved in their development. It highlights various risks including client-side logic manipulation, data validation issues, and exposure of sensitive information. The author advocates for server-side control logic, strict data validation, and zero-trust interfaces to mitigate these risks.
SecTor '09 - When Web 2.0 Attacks!
- 1. When Web 2.0 Attacks! Understanding Ajax, Flash and other highly interactive web technologies… Rafal M. Los HP ASC Sr. Security Solutions Expert 1 15
- 2. Fire! … Aim! Ready? Question 1: Web 2.0 content is being developed primarily by the same developers that write traditional web code. True or False? Question 2: Everyone understands the idea of “Web 2.0” and there are concrete standards. True or False? Question 3: Your company has deployed “Web 2.0 stuff” already. True or False? 2
- 3. Answers… Question 1: False! Web 2.0 is being developed in a large part not by traditional developers, but by “marketing or media folks”… Question 2: False! Ask 2 different people to define “Web 2.0”… listen to their answers. Question 3: (most likely) True! … and if you don‟t know it, it‟s even worse. 3
- 4. Browser Evolution Render simple HTML content o n Render complex, synchronous content l Render complex, asynchronous content i n Perform complex, asynchronous interactions e Perform complex, asynchronous, offline interactions 4
- 5. Let‟s start by thinking offensively 5
- 6. Understanding Web 2.0 Motivations 2 reasons “Web 2.0” happened… 1. Increased demand for processor cycles 2. Increased demand for bandwidth What happened… Logic moved from server client Invention of asynchronous transaction The “offline web” application 6
- 7. Examples – What Could Possibly Go Wrong? … what could possibly go wrong? Manipulation of business logic Client-side data validations Exposure of sensitive information 7
- 8. Client-Side Logic Manipulation try { strURI = ExternalInterface.call("getLittleServer"); … n1 = parseInt(strN1); n2 = parseInt(strN2); nAlgo = n1 * n2 * nScore + nScore; strToPass = nGameId + "," + nScore + "," + nTime + "," + nAlgo; encrypted_data = MD5.hash(strToPass); submission_data = "score=" + nScore + "|gameId=" + nGameId + "|timestamp=" + nTime + "|key=" + encrypted_data; variables = new URLVariables(); variables.attr1 = submission_data; request = new URLRequest(strURI); request.data = variables; navigateToURL(request, "_self"); return submission_data; … 8
- 9. Examples – What Could Possibly Go Wrong? … what ^ could possibly go wrong? Manipulation of business logic Client-side data validations Exposure of sensitive information 9
- 10. Client-Side Data Validations … button 9 { on (release, keyPress '<Enter>') { if (password eq „ PASSWORD ') { getURL('http://www.SomeCompany.tld/client_pages/CUSTOMER_REMOVED/778.html', ''); } else { if (password eq ' PASSWORD ') { getURL('http://www.SomeCompany.tld/client_pages/CUSTOMER_REMOVED/781.html', ''); } else { if (password eq ' PASSWORD ') { getURL('http://www.SomeCompany.tld/client_pages/CUSTOMER_REMOVED/783.html', ''); } else { if (password eq „ PASSWORD ') { getURL('http://www.SomeCompany.tld/client_pages/CUSTOMER_REMOVED/771.html', ''); } else { if (password eq „ PASSWORD ') { getURL('http://www.SomeCompany.tld/client_pages/CUSTOMER_REMOVED/799.html', ''); } else { … 10
- 11. 11
- 12. Examples – What Could Possibly Go Wrong? … what ^ could possibly go wrong? Manipulation of business logic Client-side data validations Exposure of sensitive information 12
- 13. Thinking Web 2.0 Offense private static function query(arg0:String, arg1:flash.events::EventDispatcher = null) { … trace("2:MySQL Query: " + statement); if(this.connection == null) { try { this.connection = new Connection(irrcrpt("dqgurjudgh.frp", 3), 3306, irrcrpt("icog_nqikp", 2), irrcrpt("d1su4y", 1), irrcrpt("jdph", 3)); } catch (e:SecurityError) { var loc1:* = e; statement = null; Alert.show(statement.message, "Security Error"); … } 13
- 14. Thinking Web 2.0 Offense hacker 14
- 15. Let‟s decompile some flash! … wait, I thought you couldn’t do that! 15
- 16. Attacking Web 2.0 Sites Having some fun with MapQuest… (yes, still) 16
- 17. Attacking Web 2.0 Sites Having some fun with MapQuest… (yes, still) We insert the infamous iFrame </iframe><script> alert(document.cookie) </script> PLAIN => PostalCode="><frame Let’s ENCODE it to get past black-listing filters… %22%3e%3cframe%20src%3dhttps%3a%2f%2fblue-sea-697d.quartiers047.workers.dev%3a443%2fhttp%2fgoogle.com%3e %3c%2fiframe%3e%3cscript%3ealert(document.cookie)%3c%2f script%3e 17
- 18. Attacking Web 2.0 Sites … and then this happens! 18
- 19. What Did We Just Learn? Web 2.0 isn‟t some magical new “thing”; it‟s a conglomeration of old technologies… …and yes, all the old bugs are back. 19
- 20. The HTML v5 Specification Standards rule. Consider this… ClickJacking was an abuse of standards HTML v5 now has local database specification HTML v5 has an offline application specification HTML v5 is so big few people have read it all 20
- 21. Specification for Offline Web Apps From W3.org http://www.w3.org/TR/offline-webapps/ Users of typical online Web applications are only able to use the applications while they have a connection to the Internet. When they go offline, they can no longer check their e-mail, browse their calendar appointments... The HTML 5 specification provides two solutions to this: a SQL-based database API for storing data locally, and an offline application HTTP cache for ensuring applications are available even when the user is not connected to their network. 21
- 22. Mechanisms for Offline Apps SQL-based database API for storing data locally and an offline application HTTP cache What could possibly go wrong? 22
- 23. Implementing Offline App Concepts Remote System (Application) Would you rather hack this… Database Application … or this? Hardened Defenses Browser… Internet Local Local App Database Cache 23
- 24. Simple Problems with Offline Apps Online Application Offline Application Remote data storage Local data storage Enterprise DB typically “secured” Local DB “forgotten” Enterprise DB difficult to access Local DB … on local filesystem Attack trips security mechanisms No local security mechanisms Remote Logic Local “Cached” Logic Manipulate at run-time, remotely Manipulate code, locally Remote validation of logic Fully control/manipulate logic 24
- 25. Then Came Social Media… First, came the applications… They were attacked…a lot… …then hardened. 25
- 26. Users Demanded More Users wanted more. Applications were extended via APIs. 26
- 27. Social Sites Were Extended… 3rd parties built interfaces using the APIs 27
- 28. Hackers Exploited Extensions/APIs Hackers attacked users via application APIs 28
- 29. Web 2.0 Attacked Via Extension FaceBook still fighting worms and hacks against users via extensions (or plug-ins) built using legal API extensions (Koobface?) Twitter API continually being abused by worms and “bots” to spam and seed trojan malware Why attack a hardened resource/site when a hacker can use APIs to write malicious plug-ins? 29
- 30. So what do we do about it? 30
- 31. The 3½ Keys to Success o Perform all control logic server-side o Validate all data at ingress & egress o Build zero-trust interfaces … and remember, “the user will always choose dancing bears over security”. -Schenier 31
- 32. Perform All Control Logic Server-Side Application-critical logic must always be performed on the server side, where it is less likely to be manipulated • Remember you can never trust code once it leaves your control • Web code can and will be reverse-engineered (flash, java, etc) • Never push critical information (passwords, connection strings) to the client 32
- 33. Validate All Data at Ingress/Egress Validate all data as it comes into your application, and also as it leaves • Validate every single piece of data, always • Mix white-list and black-list, focusing on minimum required data sets • Make sure you know what‟s leaving your application… 33
- 34. Build Zero-Trust Interfaces Assume the APIs or web-services you expose will be attacked • Never trust the interface to provide clean data, legal calls, or valid requests • Authenticate interfaces when ever possible • Never trust your own code once it‟s in the user‟s browser (least-privilige) • Adopt the mentality of …”If you were sticking your hand into a dark, unknown box” 34
- 35. Save the User, Save the World Usable security is a myth on the web. Web 2.0+ focuses on usability, over security. “Cool” wins over “secure” every time. Never trust to user to “know better”. 35
- 36. Thank You Rafal Los Twitter: @RafalLos Email: [email protected] Direct: +1 (765) 247 - 2325 Blogs: “Following the White Rabbit” http://www.communities.hp.com/securitysoftware/blogs/rafal/default.aspx “Digital Soapbox” http://preachsecurity.blogspot.com Oh! … and I work at HP’s Application Security Center (ASC) 36