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.

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 this talk 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 compromise of 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 frameworks do 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 the same?
 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 the same?
 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 the same?
 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 the same?
 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 the same?
 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 be done?
 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 be done?
 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 a journey, not a destination.
(So remember to buckle up, and enjoy the ride)

25. Questions ???
junaid@sensepost.com
www.sensepost.com/blog