4. Introduction: What will we cover today?
1. Five top vulnerabilities by OWASP
2. How to find them
3. How to prevent them
5. OWASP
The Open Web Application Security Project (OWASP) is a
worldwide free and open community focused on improving
the security of application software.
7. OWASP: Top Ten 2007
1. Cross Site Scripting
2. Injection Flaws
3. Insecure Remote File Include
4. Insecure Direct Object Reference
5. Cross Site Request Forgery
6. Information Leakage And Improper Error Handling
7. Broken Authentication And Session Management
8. Insecure Cryptographic Storage
9. Insecure Communications
10. Failure To Restrict URL Access
8. OWASP: Top Ten 2004
1. Unvalidated Input
2. Broken Access Control
3. Broken Authentication And Session Management
4. Cross Site Scripting
5. Buffer Overflows
6. Injection Flaws
7. Improper Error Handling
8. Insecure Storage
9. Denial Of Service
10. Insecure Configuration Management
9. OWASP: 2004 & 2007
1. Cross Site Scripting 4. Cross Site Scripting
2. Injection Flaws 6. Injection Flaws
3. Insecure Remote File IncludeNEW
4. Insecure Direct Object Reference 2. Broken Access Control (split)
5. Cross Site Request Forgery NEW
6. Information Leakage And Improper Error Handling 7. Improper Error Handling
7. Broken Authentication And Session Management 3. Broken Authentication And Session Management
8. Insecure Cryptographic Storage 8. Insecure Storage
9. Insecure Communications
10. Failure To Restrict URL Access 2. Broken Access Control (split)
1. Unvalidated Input
5. Buffer Overflows
9. Denial Of Service
10. Insecure Configuration Management
10. BSN: The Web Hacking Incidents Database
What are the drivers for Web Hacking?
1%
3% 1%
1%
3%
3%
8%
42%
15%
23%
Stealing Sensitive Information Defacement Planting Malware
Unknown Deceit Blackmail
Link Spam Worm Phishing
Information Warfare
11. BSN: The Web Hacking Incidents Database
What are the drivers for Web Hacking?
A5
A2
A3
18% 20%
A4
8%
A6
17%
10%
A7
12% 15%
A1
A10, 2004
SQL Injection Unintentional Information Disclosure
Known Vulnerability Cross Site Scripting (XSS)
Insufficient Access Control Credential/Session Prediction
Other
13. Cross Site Scripting: Overview
Cross Site Scripting (XSS) flaws occur whenever an application takes data
that originated from a user and sends it to a web browser without first
validating or encoding that content.
<script type=quot;text/javascriptquot;>
alert(quot;You've been hacked!quot;);
</script>
<script type=quot;text/javascriptquot;>
alert(quot;You've been hacked!quot;);
server
</script>
<script type=quot;text/javascriptquot;>
<script type=quot;text/javascriptquot;>
alert(quot;You've been hacked!quot;);
alert(quot;You've been hacked!quot;);
</script>
</script>
16. Cross Site Scripting: Protection
1. Input validation
Use a standard input validation mechanism to validate all input data for length,
type, syntax, and business rules before accepting the data to be displayed or
stored.
2. Strong output encoding
Ensure that all user‐supplied data is HTML entity encoded before rendering in
HTML, taking the approach to encode all characters other than a very limited
subset.
19. Injection Flaws: Overview
Injection flaws, particularly SQL injection, are common in web applications.
Injection occurs when user‐supplied data is sent to an interpreter as part of a
command or query. The attacker’s data tricks the interpreter into executing
unintended commands.
20. SQL Injection: How it works.
?uname=kate&pwd=123abc SELECT pwd FROM USERS WHERE uname IS '$uname';
SELECT pwd FROM USERS WHERE uname IS 'kate';
Kate
server DB server
?uname=’;%20DROP%20TABLE%20USERS;&pwd=123abc SELECT pwd FROM USERS WHERE uname IS '$uname';
SELECT pwd FROM USERS WHERE uname IS '';
Bad Guy DROP TABLE USERS;
server DB server
23. SQL Injection: Protection
1. Enforce least privilege
2. Avoid detailed error messages
3. Do not send dynamic queries
4. Be careful when using stored procedures
5. Do not use dynamic query interface
6. Do not use simple escaping functions
26. Insecure Remote File Include: Overview
Malicious file execution vulnerabilities are found in many applications.
Developers will often directly use or concatenate potentially hostile input with
file or stream functions, or improperly trust input files.
include $_REQUEST['filename’];
27. Insecure Remote File Include: How it works.
<select name=quot;languagequot;>
<option value=quot;frquot;></option>
</select>
require_once ($_REQUEST[quot;languagequot;].quot;lang.phpquot;);
<select name=quot;languagequot;>
<option value=quot;frquot;>French</option>
<option value=quot;../../../../etc/passwd%00quot;>Show your passwords</
option>
</select>
28. Insecure Remote File Include: Protection
In general, a well‐written application will not use user‐supplied input in any
filename for any server‐based resource(such as images, XML and XSL transform
documents, or script inclusions), and will have firewall rules in place preventing
new outbound connections to the Internet or internally back to any other
server.
31. Insecure Direct Object Reference: Overview
A direct object reference occurs when a developer exposes a reference to an
internal implementation object, such as a file, directory, database record, or key,
as a URL or form parameter.
Unless an access control check is in place, an attacker can manipulate those
references to access other objects without authorization.
32. Insecure Direct Object Reference: How it works.
Unauthorized user has access to any cart.
int cartID = Integer.parseInt( request.getParameter( quot;cartIDquot; ) );
String query = quot;SELECT * FROM table WHERE cartID=quot; + cartID;
Preventing:
int cartID = Integer.parseInt( request.getParameter( quot;cartIDquot; ) );
User user = (User)request.getSession().getAttribute( quot;userquot; );
String query = quot;SELECT * FROM table WHERE cartID=quot; + cartID + quot; AND userID=quot; + user.getID();
33. Insecure Direct Object Reference: Protection
1. Avoid exposing your private object references to users whenever possible.
2. Verify authorization to all referenced objects
36. Cross Site Request Forgery: Overview
A CSRF attack forces a logged‐on victim’s browser to send a request to a
vulnerable web application, which then performs the chosen action on behalf
of the victim, to the benefit of the attacker.
37. Cross Site Request Forgery: How it works.
Peter
bank.com
/login.html
/auth
Cookie: sessionid:1234567
/viewbalance Cookie: sessionid:1234567
Your balance is 50 000 $
38. Cross Site Request Forgery: How it works.
Peter
bank.com evil.com
/login.html
/auth
Cookie: sessionid:1234567
/index.html
...
<img src=quot;http://bank.com/paybill?addr=...&amount=1000quot;/>
...
/paybill?addr=...&amount=1000 Cookie: sessionid:1234567
OK. Payment sent!