Detecting and Defending Against Security
Vulnerabilities for Web 2.0 Applications
Ray Lai, Intuit
Share experience how to detect and defend
security vulnerabilities in Web 2.0 applications
using open source security tools
Agenda
Detect
Defend
Learn
Which is Easier to Hack?
Web 1.0 App Web 2.0 App
Top 3 Security Vulnerabilities •Unvalidated input parameters •Broken access control
•Broken authentication and session management
Top 3 Security Vulnerabilities •Cross-site scripting
•Injection flaw
•Malicious file execution
What’s New About Web 2.0 Security?
OWASP 2007 Top 10 Web 2.0 Examples
Cross-site scripting +++ Flash: cross-site flashing
Injection flaws ++++ AJAX, mash-up
Malicious file execution +++
Insecure direct object reference + JavaScript™ Object Notation (JSON)
Cross-site request forgery +++ Flash
Information leakage / improper error handling
+++++ AJAX, JSON Broken authentication and session
management
++++ Cross-domain, mash-up Insecure cryptographic storage +
Insecure communications ++
Use Case Scenario
Use Open Source / commercial security tools to examine
WebGoat (and Roller) from
SecuriBench
Example #1: Post-Me
Characteristics
•Plain data input screen •No sensitive personal data •High usage, high traffic
Scenarios: newsgroup, forum, blogs, etc.
How can I re-direct readers
to my malicious website?
Example #1: What’s the Issue?
What happens: Hackers post a message with the malicious URL or parameters:
<IMG SRC="attack?screen=7&menu=410&transferFunds=4000" width="1" height="1" />
Cross-site Request Forgery
Result: when reading the posting, newsgroup readers will invoke a malicious URL
Example #2: Online Travel
Scenarios: online travel service, mash-up
Characteristics
•AJAX with JSON
•Financial transactions •Mash-up, possibly
Example #2: What’s the Issue?
What happens: Hackers intercepts the JSON, tampers it,
and posts it.
JSON Poisoning
{ "From": "Boston", "To": "Seattle", "flights": [ {"stops": "0", "transit" : "N/A", "price": "$0"},
{"stops": "2", "transit" :
Example #3: Change Password
Scenarios: online services, mash-up
Characteristics
•SOAP-based Web services •Perhaps mash-up
•HTTP or HTTPS, depends
Can I change
Example #3: What’s the Issue
SOAP Injection
What happens: Hackers tries changing the password,
intercepts the SOAP message, tampers it, and posts it.
Result: hackers change
someone’s password for future
<?xml version='1.0' encoding='UTF-8'?> … <wsns0:Body>
<wsns1:changePassword>
<id xsi:type='xsd:int'>101</id> <password xsi:type='xsd:string'>
bar</password>
</wsns1:changePassword> </wsns0:Body>
What About Flex Application…
Cross-site Flashing
What About…
Phishing attack
Ad malware
Botnet
ActiveX controls
Agenda
Detect
Defend
Defensive Coding: Examples
Scenarios Sample ActionsCross-site request forgery Filter specific tags (e.g. <IMG>)
Prompt user with security token for important actions or high value transactions
Shorter time period for user sessions
JSON poisoning Client-side and server-side input validation JavaScript output encoding
Obfuscate JavaScript
SOAP injection Use of nonce
WS-Security best practices Turn off WSDL
Strategy #2: Custom Security Test
Category Public / Open Source Commercial
Discovery tools NMAP Nessus
Web server vulnerabilities Nikto
Code quality* OWASP, FindBugs Fortify, Klockwork
Application vulnerabilities Paros AppScan, Hailstorm
Penetration testing WebScarab, Paros, SwfIntruder