1. How to Break Web
Applications Security
(focused on Web Services)
Dinis Cruz
Principal Security Engineer

2. About Security Innovation
• Application Security Experts
– 10+ years research on vulnerabilities
– Hundreds of assessments on world’s most dominant
software applications
• Products, Services & Training
– Software & SDLC Assessment
– Application Risk Management
– eLearning
• Computer based training
• Secure Development Knowledgebase
• Helping organizations
– Reduce vulnerabilities and IT/data risk
– Integrate security into their development process

3. Agenda
How to think about Web Application
Security
• OWASP TOP 10
• Demos
• Conclusion

4. How to Think About Web Application Security
• Learn as much as possible about the technologies used
• Understand how the application works
• Understand the attack surface
• Find the Assets
• Map the Company’s risk appetite
• Focus on HOW the application works, not on WHAT it does
• Automate Application Security Knowledge
• Find ways to make application security ‘invisible’ to
developers

5. How to Approach Web Security Testing

6. How to Approach Web Security Testing
• Exploratory Testing
– understand how the application works within it’s environment
– gives us clues as to how it may break

7. How to Approach Web Security Testing
• Exploratory Testing
– understand how the application works within it’s environment
– gives us clues as to how it may break
• Threat Modeling
– Profiles how adversaries view the system, its applications and how it
can be exploited
– Guides test efforts, ensuring most critical risk areas are addressed

8. How to Approach Web Security Testing
• Exploratory Testing
– understand how the application works within it’s environment
– gives us clues as to how it may break
• Threat Modeling
– Profiles how adversaries view the system, its applications and how it
can be exploited
– Guides test efforts, ensuring most critical risk areas are addressed
• Test Planning
– For each threat, develop test cases that detail the tools, techniques
and strategies for finding vulnerabilities

9. How to Approach Web Security Testing
• Exploratory Testing
– understand how the application works within it’s environment
– gives us clues as to how it may break
• Threat Modeling
– Profiles how adversaries view the system, its applications and how it
can be exploited
– Guides test efforts, ensuring most critical risk areas are addressed
• Test Planning
– For each threat, develop test cases that detail the tools, techniques
and strategies for finding vulnerabilities
• Test Execution
– Perform the planned tests and report findings

10. Exploratory Testing
6

11. Exploratory Testing
• Goal is to find out clues about the system
6

12. Exploratory Testing
• Goal is to find out clues about the system
– What does it do?
– What inputs/outputs does it have?
– What databases are being used? What is DB structure?
6

13. Exploratory Testing
• Goal is to find out clues about the system
– What does it do?
– What inputs/outputs does it have?
– What databases are being used? What is DB structure?
– Manual Testing Tools
6

14. Exploratory Testing
• Goal is to find out clues about the system
– What does it do?
– What inputs/outputs does it have?
– What databases are being used? What is DB structure?
– Manual Testing Tools
• Should be conducted with automated/manual tools and
manual techniques
6

15. Threat Modeling
• Secure Web applications start by thinking about the threats
to your application and the attacker’s goals
– Threats are not Vulnerabilities!
Mitigation
Attacker
Threat
Vulnerability
Vulnerabilities are unmitigated threats - Here’s our opportunity!

16. Test Planning
Optimizing Test Efforts Using your Threat Model
• Threat profile serves as basis for security test planning:
– Assets of value have been identified
– Threats that could compromise those assets have been determined
– Attacks that could realize the threats have been uncovered
– Key conditions that must be met for each attack to be successful
have been discovered
• Test plan should focus on testing the key attack
conditions in order to prove/disprove threats to your app
– This ensures you are testing the areas where the difficulty of attack
is least and the impact is highest
• Grab Microsoft’s Free Threat Modeling Tool

17. Test Execution – Tooling
9

18. Test Execution – Tooling
• Automated scanners
9

19. Test Execution – Tooling
• Automated scanners
– Run on their own (though some tuning is typically needed).
9

20. Test Execution – Tooling
• Automated scanners
– Run on their own (though some tuning is typically needed).
– Test for common known vulnerabilities
9

21. Test Execution – Tooling
• Automated scanners
– Run on their own (though some tuning is typically needed).
– Test for common known vulnerabilities
– Lack the ability to target business logic attacks
9

22. Test Execution – Tooling
• Automated scanners
– Run on their own (though some tuning is typically needed).
– Test for common known vulnerabilities
– Lack the ability to target business logic attacks
– Generally will gain better coverage than a human tester ever will
9

23. Test Execution – Tooling
• Automated scanners
– Run on their own (though some tuning is typically needed).
– Test for common known vulnerabilities
– Lack the ability to target business logic attacks
– Generally will gain better coverage than a human tester ever will
– IBM Appscan, HP WebsInspect, 0x90.org Absinthe
9

24. Test Execution – Tooling
• Automated scanners
– Run on their own (though some tuning is typically needed).
– Test for common known vulnerabilities
– Lack the ability to target business logic attacks
– Generally will gain better coverage than a human tester ever will
– IBM Appscan, HP WebsInspect, 0x90.org Absinthe
• Manual Testing Tools
– These tools are varied and assist a human tester in their activities
– Tend to be very specialised and often single purpose
– Examples include
• Encoders/Decoders (ex. 0x90.org’s Napkin)
• Fingerprinters (ex. Net-Square’s HTTPrint)
• Brute Forcers (ex. Sensepost’s CrowBar)
• Localhost Proxies (ex. ParosProxy)
9

25. Test Execution - Best of both worlds
• Automate Security Knowledge and Workflows
– Capture Application Security tests as scripts and be able to
automatically replicate, debug and retest them
– Package security findings as Unit Tests and insert them into the SDL
(namely Development and QA phases)
– Allow Developers to work with Security teams so that better
‘application visualisation’ tools are created during the security
engagement
• Give these ‘application visualisation tools’ back to the developers

26. Agenda
How to think about Web Application
Security
• OWASP TOP 10
• Web Services Security
• Demos
• Conclusion

27. What is the OWASP Top 10
• A broad consensus of the most critical web application security
flaws
• Used by many commercial companies, referenced in numerous
standards and regulations such as PCI-DSS
• Aim:
– The primary aim of the Top 10 is to educate developers, designers,
architects and organisations
– Security is not a one-time event
– A secure coding initiative must deal with all stage of a programs
lifecycle
– The top 10 is an education piece, not a standard

28. OWASP Top Ten: Summary
A1 – Injection
A2 – Cross Site Scripting (XSS)
A3 – Broken Authentication and Session Management
A4 – Insecure Direct Object References
A5 – Cross Site Request Forgery (CSRF)
A6 – Security Misconfiguration (NEW)
A7 – Failure to Restrict URL Access
A8 – Unvalidated Redirects and Forwards (NEW)
A9 – Insecure Cryptographic Storage
A10 – Insufficient Transport Layer Protection

29. A1 – Injection
• Injection means…
– Tricking an application into including unintended commands in the data sent to an
interpreter
• Interpreters…
– Take strings and interpret them as commands
– SQL, OS Shell, LDAP, XPath, Hibernate, etc…
• SQL injection is still quite common
– Many applications still susceptible (really don’t know why)
– Even though it’s usually very simple to avoid
• Typical Impact
– Usually severe. Entire database can usually be read or modified
– May also allow full database schema, or account access, or even OS level access

30. A1 – Injection
SQL Injection – Example
Problem: Embedding user input in SQL queries IS BAD!
String SQLQuery ="SELECT Username, Password
FROM users WHERE Username='" + Username +
"' AND Password='" + Password + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(SQLQuery);
while (rs.next()) { … }
… Any nasty ideas?
15

31. A2 – Cross-Site Scripting (XSS)
• Occurs any time…
– Raw data from attacker is sent to an innocent user’s browser
• Raw data…
– Stored in database
– Reflected from web input (form field, hidden field, URL, etc…)
– Sent directly into rich JavaScript client
• Virtually every web application has this problem
– Try this in your browser:
• javascript:alert(document.cookie)
• <script>alert(document.cookie)</script>
• Typical Impact
– Steal user’s session, steal sensitive data, rewrite web page, redirect user to phishing or
malware site
– Most Severe: Install XSS proxy which allows attacker to observe and direct all user’s behavior
on vulnerable site and force user to other sites

32. Common Web Software Security Vulnerabilities
Script Injection/Cross-site Scripting (XSS) – Persistent XSS
Vulnerable Web
Application
Evil Doer Victim
17

33. Common Web Software Security Vulnerabilities
Script Injection/Cross-site Scripting (XSS) – Persistent XSS
Vulnerable Web
Application
ds WA
n V
se to d
ED ript tore
1: sc s
p s
te us it i
S io e
a lic her
m w
Evil Doer Victim
17

34. Common Web Software Security Vulnerabilities
Script Injection/Cross-site Scripting (XSS) – Persistent XSS
Vulnerable Web
Application
re Ste
ds WA
n V
so p
ur 2:
se to d th ce Vic
ED ript tore e wh ti
1: sc s m ic m
al h re
p s
te us it i
S io e
ic n q
io o u
us w es
a lic her sc con ts a
m w rip ta
t ins
Evil Doer Victim
17

35. Common Web Software Security Vulnerabilities
Script Injection/Cross-site Scripting (XSS) – Persistent XSS
Vulnerable Web
Application
re Ste
ds WA
n V
so p
ur 2:
se to d th ce Vic
ED ript tore e wh ti
1: sc s m ic m
al h re
p s
te us it i
S io e
ic n q
io o u
us w es
a lic her sc con ts a
m w rip ta
t ins
Step 3: Malicious script runs
on victim’s machine sending
Evil Doer confidential data to ED Victim
17

36. A3 – Broken Authentication and Session Management
• HTTP is a “stateless” protocol
– Means credentials have to go with every request
– Should use SSL for everything requiring authentication
• Session management flaws
– SESSION ID used to track state since HTTP doesn’t
• and it is just as good as credentials to an attacker
– SESSION ID is typically exposed on the network, in browser, in logs, …
• Beware the side-doors
– Change my password, remember my password, forgot my password,
secret question, logout, email address, etc…
• Typical Impact
– User accounts compromised or user sessions hijacked

37. Broken Authentication Illustrated
1 User sends credentials
Knowledge Mgmt
Communication
Bus. Functions
Administration
Transactions
E-Commerce
Accounts
Finance
www.boi.com?JSESSIONID=9FA1DB9EA...
Site uses URL rewriting
2 Custom Code
(i.e., put session in URL)
3 User clicks on a link to http://
www.hacker.com in a forum
Hacker checks referer logs on
www.hacker.com
4
and finds user’s JSESSIONID
5 Hacker uses JSESSIONID
and takes over victim’s
account

38. A4 – Insecure Direct Object References
• How do you protect access to your data?
– This is part of enforcing proper “Authorization”, along with
A7 – Failure to Restrict URL Access
• A common mistake …
– Only listing the ‘authorized’ objects for the current user, or
– Hiding the object references in hidden fields
– … and then not enforcing these restrictions on the server side
– This is called presentation layer access control, and doesn’t work
– Attacker simply tampers with parameter value
• Typical Impact
– Users are able to access unauthorized files or data

39. Insecure Direct Object References Illustrated
• Attacker notices his acct
https://www.onlinebank.com/user? parameter is 6065
acct=6065
?acct=6065
• He modifies it to a nearby
number
?acct=6066
• Attacker views the victim’s
account information

40. A5 – Cross Site Request Forgery (CSRF)
• Cross Site Request Forgery
– An attack where the victim’s browser is tricked into issuing a command to a
vulnerable web application
– Vulnerability is caused by browsers automatically including user authentication data
(session ID, IP address, Windows domain credentials, …) with each request
• Imagine…
– What if a hacker could steer your mouse and get you to click on links in your online
banking application?
– What could they make you do?
• Typical Impact
– Initiate transactions (transfer funds, logout user, close account)
– Access sensitive data
– Change account details

41. CSRF Illustrated
Attacker sets the trap on some website on the internet
1 (or simply via an e-mail)
Application with CSRF
Hidden <img> tag vulnerability
contains attack
against vulnerable site
Knowledge Mgmt
Communication
Bus. Functions
Administration
Transactions
E-Commerce
Accounts
Finance
While logged into vulnerable site,
2 victim views attacker site
Custom Code
3
Vulnerable site sees
<img> tag loaded by legitimate request from
browser – sends GET victim and performs
request (including the action requested
credentials) to
vulnerable site

42. A6 – Security Misconfiguration
• Web applications rely on a secure foundation
– All through the network and platform
– Don’t forget the development environment
• Is your source code a secret?
– Think of all the places your source code goes
– Security should not require secret source code
• CM must extend to all parts of the application
– All credentials should change in production
• Typical Impact
– Install backdoor through missing network or server patch
– XSS flaw exploits due to missing application framework patches
– Unauthorized access to default accounts, application functionality or data, or
unused but accessible functionality due to poor server configuration

43. Security Misconfiguration Illustrated
Knowledge Mgmt
Communication
Bus. Functions
Administration
E-Commerce
Transactions
Accounts
Finance
Database
Custom Code
App Configuration
Development
Framework
App Server
QA Servers
Web Server
Hardened OS
Insider Test Servers
Source Control

44. A7 – Failure to Restrict URL Access
• How do you protect access to URLs (pages)?
– This is part of enforcing proper “authorization”, along with
A4 – Insecure Direct Object References
• A common mistake …
– Displaying only authorized links and menu choices
– This is called presentation layer access control, and doesn’t work
– Attacker simply forges direct access to ‘unauthorized’ pages
• Typical Impact
– Attackers invoke functions and services they’re not authorized for
– Access other user’s accounts and data
– Perform privileged actions

45. Failure to Restrict URL Access Illustrated
• Attacker notices the URL
indicates his role
/user/getAccounts
• He modifies it to another
directory (role)
/admin/getAccounts, or
/manager/getAccounts
• Attacker views more accounts
than just their own

46. A8 – Unvalidated Redirects and Forwards
• Web application redirects are very common
– And frequently include user supplied parameters in the destination URL
– If they aren’t validated, attacker can send victim to a site of their choice
• Forwards (aka Transfer in .NET) are common too
– They internally send the request to a new page in the same application
– Sometimes parameters define the target page
– If not validated, attacker may be able to use unvalidated forward to bypass authentication or
authorization checks
• Typical Impact
– Redirect victim to phishing or malware site
– Attacker’s request is forwarded past security checks, allowing unauthorized function or data
access
• Live Example
– http://www.youtube.com/redirect?username=digitalhook&
q=http%3A%2F%2Fsecuritytube.net%2FSocial-Engineering-Attacks-using-Simple-Redirections-video.aspx
&video_id=Vgc3NVVpb8c&event=url_redirect&url_redirect=True&usg=UE0DOmwjBRK-mgheFtW1hMTEvh4=

47. Unvalidated Redirect Illustrated
1 Attacker sends attack to victim via email or webpage
From: Internal Revenue Service
Subject: Your Unclaimed Tax
Refund 3 Application redirects
Our records show you have an victim to attacker’s
unclaimed federal tax refund. site
Please click here to initiate your
claim.
Knowledge Mgmt
Communication
Bus. Functions
Administration
Transactions
E-Commerce
Accounts
Finance
Victim clicks link containing unvalidated
2 parameter
Custom Code
Request sent to vulnerable
site, including attacker’s
destination site as
parameter. Redirect sends
victim to attacker site Evil Site
4 Evil site installs malware on
http://www.irs.gov/taxrefund/claim.jsp? victim, or phish’s for private
year=2006& … &dest=www.evilsite.com information

48. A9 – Insecure Cryptographic Storage
• Storing sensitive data insecurely
– Failure to identify all sensitive data
– Failure to identify all the places that this sensitive data gets stored
• Databases, files, directories, log files, backups, etc.
– Failure to properly protect this data in every location
• Typical Impact
– Attackers access or modify confidential or private information
• e.g, credit cards, health care records, financial data (yours or your customers)
– Attackers extract secrets to use in additional attacks
– Company embarrassment, customer dissatisfaction, and loss of trust
– Expense of cleaning up the incident, such as forensics, sending apology
letters, reissuing thousands of credit cards, providing identity theft insurance
– Business gets sued and/or fined

49. Insecure Cryptographic Storage Illustrated
Victim enters credit
1 card number in form
Knowledge Mgmt
Communication
Bus. Functions
Administration
Transactions
E-Commerce
Accounts
Finance
Custom Code
Malicious insider Log files
4
steals 4 million Error handler logs CC 2
credit card numbers details because
merchant gateway is
unavailable
Logs are accessible to 3
all members of IT staff
for debugging purposes

50. A10 – Insufficient Transport Layer Protection
• Transmitting sensitive data insecurely
– Failure to identify all sensitive data
– Failure to identify all the places that this sensitive data is sent
• On the web, to backend databases, to business partners, internal communications
– Failure to properly protect this data in every location
• Typical Impact
– Attackers access or modify confidential or private information
• e.g, credit cards, health care records, financial data (yours or your customers)
– Attackers extract secrets to use in additional attacks
– Company embarrassment, customer dissatisfaction, and loss of trust
– Expense of cleaning up the incident
– Business gets sued and/or fined

51. Insufficient Transport Layer Protection Illustrated
Business Partners
External Victim
Custom Code Backend Systems
Employees
1 2
External attacker Internal attacker
steals credentials steals credentials and
and data off data from internal
network network
External Attacker Internal Attacker

52. Agenda
How to think about Web Application
Security
• OWASP TOP 10
• Web Services Security
• Demos
• Conclusion

53. Agenda
How to think about Web Application
Security
• OWASP TOP 10
• Web Services Security
• Demos
• Conclusion

54. Agenda
How to think about Web Application
Security
• OWASP TOP 10
• Web Services Security
• Demos
• Conclusion

55. Conclusion

56. Conclusion
• Learn as much as possible about the technologies used

57. Conclusion
• Learn as much as possible about the technologies used
• Understand how the application works

58. Conclusion
• Learn as much as possible about the technologies used
• Understand how the application works
• Understand the attack surface

59. Conclusion
• Learn as much as possible about the technologies used
• Understand how the application works
• Understand the attack surface
• Find the Assets

60. Conclusion
• Learn as much as possible about the technologies used
• Understand how the application works
• Understand the attack surface
• Find the Assets
• Map the Company’s risk appetite

61. Conclusion
• Learn as much as possible about the technologies used
• Understand how the application works
• Understand the attack surface
• Find the Assets
• Map the Company’s risk appetite
• Focus on HOW the application works, not on WHAT it does

62. Conclusion
• Learn as much as possible about the technologies used
• Understand how the application works
• Understand the attack surface
• Find the Assets
• Map the Company’s risk appetite
• Focus on HOW the application works, not on WHAT it does
• Automate Application Security Knowledge

63. Conclusion
• Learn as much as possible about the technologies used
• Understand how the application works
• Understand the attack surface
• Find the Assets
• Map the Company’s risk appetite
• Focus on HOW the application works, not on WHAT it does
• Automate Application Security Knowledge
• Find ways to make application security ‘invisible’ to
developers

64. Become the Developer’s best Friend
• Check out this presentation delivered at OWASP AppSec
Brazil
• http://diniscruz.blogspot.com/2011/10/my-presentation-at-
owasp-appsec-brazil.html

65. How Security Innovation can Help
• TeamProfessor: Computer-Based Training
– OWASP Top Ten
– Creating Secure Code
– PCI-DSS for Developers
– Threat Modeling
• TeamMentor: Secure Development KB
– Over 3,500 knowledge assets
– How-to’s, code snippets, checklists, etc
• Code Review & Pen Test
• Application Risk Management
– Secure SDLC Gap Analysis
– Application Risk Ranking
– IT Infrastructure Attack Simulation

66. Free eLearning Course for A0ending
Testing For OWASP Top Ten
TeamMentor
TeamMentor Free OWASP Version:
owasp.teammentor.com
TeamMentor Commercial Version
http://teammentor.securityinnovation.com
Copy of Presenta9on/Free Course
getsecure@securityinnovation.com
Presenter Contact
dcruz@securityinnovation.com