Downloaded 11 times
Uploaded bySensePost
Web 2.0 security woes
This document is an agenda for a talk about Web 2.0 security woes. The talk will discuss how Web 2.0 applications have changed some threats and vulnerabilities compared to previous generations of web applications. While some threats have changed form, many of the same types of vulnerabilities still exist. The talk will provide examples of cross-site scripting and hidden functionality vulnerabilities. It will also discuss steps that development teams and customers can take to help improve security, such as training, secure coding practices, and involvement of security personnel throughout the development life cycle.
More Related Content
Web 2.0 security woes
- 1. Web 2.0 Security Woes Junaid Loonat SensePost 2010
- 2. Agenda Who are we are? What is this talk about? Web Application Security & Web 2.0 What changed? What stayed the same? What can be done? Questions
- 3. Who are we? SensePost Formed in 2001 Security assessment services to finance, industrial, mining, telecoms Written a few papers.. Spoken at a number of conferences (BlackHat, Defcon, …) Contributed to a handful of books Done some Training www.sensepost.com/blog
- 4. What is thistalk about? Not … About the relationship between Security and Compliance Btw, it‟s a love / hate marriage … just like the rest of us A Developer-Bashing Campaign Developers are good at making something magical, from chains of code Promoting internet-less-ness (since the internet is too dangerous) Some SPers are more paranoid than others though A technical presentation So please don‟t run away Is: Clear up the misconception that Web 2.0 is securer Educate on how to limit your risk when deploying a web application
- 5. Web Application Security Why target? Traditional perimeter security had matured Websites (and web services) are commonly used to share information … Always on Easy target
- 6. Web 2.0 Better user experience More interaction More functionality But what about security? Things got bad! … REALLY bad!
- 7. What changed? … Likely Targets Likely Targets 1.0 Intruder interacts with website therefore, the website is the target Website Maintainer Visitors
- 8. What changed? … Likely Targets Likely Targets 2.0 Intruder still interacts with website, but Intruder can interact with other users, through the targeted website therefore, other website users are targets as well Normal Visitors Website Maintainer Contributing Visitors Visitors
- 9. The complete compromiseof the hosting environment is not a prerequisite to the complete compromise of client systems.
- 10. What changed? … Page Interaction Page Interaction 1.0 User makes request … Server replies User‟s browser loads any additional page resources defined within the server response 2.0 User makes request … Server replies User interacts with webpage, Scripts performing their own requests to the web server Use web services for lookups Scripts have their own lifetime
- 11. What changed? … Page Interaction Example: CAPTCHA Username junaid 1.0 Validation performed Password ********** upon submission 2.0 Code alotocibil Validation can be Login performed during field population
- 12. What changed? … Building Blocks Components Pages can be comprised of: Resources (images, stylesheets) Scripts (JavaScript, Flash) Web services Authentication and Authorisation, the Authz, has to be enforced across all components Otherwise there is a loophole to access sensitive data
- 13. What changed? … Building Blocks Example: Uniform Enforcement of the Authz Website Attacker getAllFriendMessages(“junai Access Denied d”) getMessagesByFriend(“junaid”, “ian”) Msg #1 … Msg #n Similar issue identified on a client‟s system which was built on Drupal
- 14. Securely developed frameworksdo not always lead to securely developed applications (But they do provide a good foundation)
- 15. What changed? … Building Blocks Components Pages can be comprised of: Resources (images, stylesheets) Scripts (JavaScript, Flash) Web services Authentication has to be enforced across all components Otherwise there is a loophole to access sensitive data Application Complexity Some development teams #FAIL to recognise where trust boundaries are located
- 16. What changed? … Building Blocks Example: Error Message Information Exposure Username junaid ian The developers failed to recognise that this particular Password ********** web service fell outside one of the trust boundaries Login Authentication Failed <auth><result>Incorrect Password</result></auth> Authentication Failed <auth><result>Account Locked</result></auth>
- 17. What stayed thesame? Fact remains … Many didn‟t get security right with Web 1.0 applications Needless to say, many still don‟t get security right with Web 2.0 applications Web 2.0 has allowed for new variations of older attacks You may have fixed the known issues, but others could still exist
- 18. What stayed thesame? Example: Vanilla Cross-site Scripting What is your name? junaid Submit Attacker … <p>Hello junaid!</p> … Website What is your name? <script>alert(‘junaid’)</script> Submit Attacker … <p>Hello <script>alert(„junaid‟)</script>!</p> Website …
- 19. What stayed thesame? Example: Cross-site Scripting (into JavaScript) What is your name? <script>alert(‘junaid’)</script> Submit Attacker … <script>var name=„scriptalert(‟junaid‟)/script‟; Document.write(name);</script> Website … What is your name? Blah’;alert(‘junaid’);var tmp=‘ Submit Attacker … <script>var name=„Blah‟;alert(‟junaid‟);var tmp=„‟; Document.write(name);</script> Website …
- 20. What stayed thesame? Fact remains … Many didn‟t get security right with Web 1.0 applications Needless to say, many still don‟t get security right with Web 2.0 applications Web 2.0 has allowed for new variations of older attacks You may have fixed the known issues, but others could still exist Hidden functionality … never remains a secret! In Web 1.0, we searched for files hidden within the web directory In Web 2.0, we investigate web services in order to locate hidden methods
- 21. What stayed thesame? Example: Hidden web service methods Web Service Attacker … contents of myfile.txt getFile(“myfile.txt”) … getFile(“../../../../boot.ini”) Access Denied Validation routines recognised that the requested file existed outside of the uploads getFileByPath(“c:boot.ini”) … contents of boot.ini … Though undocumented, the getFileByPath() method existed and could be used to retrie
- 22. What can bedone? As a Development House: Security Education / Training Industry has failed to teach this during a programmer‟s early years (High School and University) Developers need to understand where things usually go wrong Defensive Coding Never trust user input Make fewer assumptions Don‟t rely on exceptions to occur whenever the application is not used correctly Source code reviews Correct your Systems Development Life Cycle Security audits are not to be conducted prior to deployment Involve security officers to observe the project as it progresses
- 23. What can bedone? As a Customer: You get what you pay for Smaller budget » less development time » pressured developers » possibly more bugs Make security a requirement Like most things in life … you won‟t get it unless you ask for it Use experienced Development Houses If the team has had one of their applications pentested before, then they are likely to understand what gets exploited If they make use of a common (custom) framework between all their projects, then security changes are commonly applied to all versions
- 24. Security is ajourney, not a destination. (So remember to buckle up, and enjoy the ride)
- 25.
Editor's Notes
- #7 User experience got betterWebsites are more interactiveWebsites have way more functionalitySecurity went down-hill, and things got badREALLY BAD!
- #11 Normal websites were composed from a specific set of resourcesA webpage would simply have text and pull in imagesAny additional functionality would be provided by directing the user to make a request to a specific script
- #12 Web 1.0Validation was only performed once the user submitted the dataVerification routines were only invoked at this timeWeb 2.0-Validation is sometimes performed concurrently while the user is still populating the required fields-Usually means that validation routines are available as a web serviceWhile the website attempted to use CAPTCHA as a mechanism to keep bots / automated scripts out … but providing the web service, they provided a routine which bots could use to read and check the CAPTCHA alone … without clocking-up authentication failuresIf you think this is not an issue for CAPTCHA, then know that we’ve seen more bad implementations of this regarding username-lookups (thereby allowing intruders to enumerate users on the system)
- #13 Normal websites were composed from a specific set of resourcesA webpage would simply have text and pull in imagesAny additional functionality would be provided by directing the user to make a request to a specific script
- #14 getAllFriendMessages(“junaid”)-Attempting to get messages for junaid from all friendsYou must be logged inOnly for authenticated usersgetMessagesByFriend(“junaid”, “ian”)-Attempt to get messages for junaid from a specific friend, ian-Results received-authentication not enforced
- #16 Normal websites were composed from a specific set of resourcesA webpage would simply have text and pull in imagesAny additional functionality would be provided by directing the user to make a request to a specific script
- #17 Normal websites were composed from a specific set of resourcesA webpage would simply have text and pull in imagesAny additional functionality would be provided by directing the user to make a request to a specific script
- #19 Normal websites were composed from a specific set of resourcesA webpage would simply have text and pull in imagesAny additional functionality would be provided by directing the user to make a request to a specific script
- #20 Normal websites were composed from a specific set of resourcesA webpage would simply have text and pull in imagesAny additional functionality would be provided by directing the user to make a request to a specific script