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.
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)
User experience got betterWebsites are more interactiveWebsites have way more functionalitySecurity went down-hill, and things got badREALLY BAD!
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
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)
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
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
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
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
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
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