5. Injection means…
Tricking an application into including
unintended commands in the data sent to
an interpreter
Interpreter
Take strings and interpret them as
commands
Eg : SQL, OS Shell, LDAP, XPath, Hibernate,
etc…
6. SQL Injection Example
$username = $_POST[‘username’];
$password = $_POST[‘password’];
$query = “SELECT * FROM user
WHERE username = ‘$username’
AND password = ‘$password’”;
$user = $db->query($query);
7. Recommendations
Avoid the interpreter entirely, or
Use an interface that supports bind variables
(e.g., prepared statements, or stored procedures),
Encode all user input before passing it to the
interpreter
References
For more details, read the new
http://www.owasp.org/index.php/SQL_Injection_
Prevention_Cheat_Sheet
8.
9. HTTP is a “stateless” protocol
• 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 of side-doors
Change my password, remember my password, forgot my
password, secret question, logout, email address, etc…
10. Site uses URL rewriting
(i.e., put session in URL)
3
2
Hacker uses JSESSIONID and
takes over victim’s account
4
Bus. Functions
E-Commerce
Knowledge Mgmt
Transactions
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
5
Communication
www.boi.com?JSESSIONID=9FA1DB9EA...
Administration
User sends credentials
Accounts
1
Finance
Attack Illustration
11. Impacts
User accounts compromised or user sessions hijacked
Recommendations
• Verify your architecture
• Verify the implementation
References
Follow the guidance from
http://www.owasp.org/index.php/Authentication_Cheat_Sheet
13. 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
14. Impacts
• 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
15. Recommendations
• Don’t include user supplied input in the output page
• Defend Against the Flaw
Primary Recommendation: Use OWASP’s ESAPI to
output encode:
• For large chunks of user supplied HTML, use
OWASP’s AntiSamy
References
For how to output encode properly, read the new
http://www.owasp.org/index.php/XSS_(Cross Site Scripting)
Prevention Cheat Sheet
17. Occurs when…
• Developer exposes a reference to an internal
implementation object.
• Without an access control check or other protection,
attackers can manipulate
Impacts
• Users are able to access unauthorized files or data
18. Insecure Direct Object References 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
21. Risks
• Default settings can be insecure, and intended for
development not production.
• Attackers can use misconfigured software to gain
knowledge and access.
Impacts
• XSS flaw exploits due to missing application
framework patches.
• Unauthorized access to default accounts, application
functionality or data.
22. Recommendations
• Know the tools you use, and configure them correctly.
• Keep up to date on vulnerabilities in the tools you use.
• Remove/disable any services/features you aren’t
using.
24. Storing and transmitting sensitive data insecurely
• Failure to identify all sensitive data
• Failure to identify all the places that this sensitive data
gets stored
• Failure to properly protect this data in every location
Impacts
• Attackers access or modify confidential or private
information
• Attackers extract secrets to use in additional attacks
• Expense of cleaning up the incident
• Business gets sued and/or fined
25. 1
Victim enters credit card
number in form
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions
Insecure Cryptographic Storage Illustrated
Custom Code
4
Log files
Malicious insider
steals 4 million credit
card numbers
Logs are accessible to all
members of IT staff for
debugging purposes
Error handler logs CC
details because merchant
gateway is unavailable
3
2
28. Risks
• Hidden things can easily be found.
• Creative people will eventually find your hidden URLs
Impacts
• Attackers invoke functions and services they’re not
authorized for
• Access other user’s accounts and data
• Perform privileged actions
29. Failure to Restrict URL Access Illustrated
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
30. Recommendations
• For each URL, a site needs to do 3 things
• Verify your architecture
• Verify the implementation
32. Risks
• Evil websites can perform actions for users logged into
your site.
• Vulnerability is caused by browsers automatically including
user authentication data with each request
Impacts
• Initiate transactions (transfer funds, logout user, close
account)
• Access sensitive data
• Change account details
33. CSRF Illustrated
While logged into vulnerable site,
victim views attacker site
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
2
Administration
Transactions
Hidden <img> tag
contains attack against
vulnerable site
Application with CSRF
vulnerability
Accounts
Finance
1
Attacker sets the trap on some website on the internet
(or simply via an e-mail)
Custom Code
3
<img> tag loaded by
browser – sends GET
request (including
credentials) to vulnerable
site
Vulnerable site sees
legitimate request from
victim and performs the
action requested
34. Prevention
• Add opaque expiring tokens to all forms.
• Requests missing tokens or containing invalid tokens
should be rejected.
36. Vulnerable components are common
The full range of weaknesses is possible, including
injection, broken access control, XSS, etc. The impact
could range from minimal to complete host takeover and
data compromise
Impacts
The full range of weaknesses is possible, including
injection, broken access control, XSS, etc. The impact
could range from minimal to complete host takeover and
data compromise
37. Preventing Known Vulnerable Components
• One option is not to use components that you didn’t
write. But that’s not very realistic.
• Most component projects do not create vulnerability
patches for old versions. Instead, most simply fix the
problem in the next version. So upgrading to these
new versions is critical.
39. 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
Impacts
• Redirect victim to phishing or malware site
• Attacker’s request is forwarded past security checks,
allowing unauthorized function or data access
40. Unvalidated Redirect Illustrated
Attacker sends attack to victim via email or webpage
Bus. Functions
E-Commerce
Communication
Knowledge Mgmt
Transactions
Victim clicks link containing invalidated parameter
Application redirects
victim to attacker’s site
Administration
2
3
Finance
From: Internal Revenue Service
Subject: Your Unclaimed Tax Refund
Our records show you have an
unclaimed federal tax refund. Please
click here to initiate your claim.
Accounts
1
Custom Code
Request sent to vulnerable
site, including attacker’s
destination site as parameter.
Redirect sends victim to
attacker site
http://www.irs.gov/taxrefund/claim.jsp?year=2006
& … &dest=www.evilsite.com
Evil Site
4
Evil site installs malware on
victim, or phish’s for private
information
41. Avoiding Unvalidated Redirects and Forwards
• Avoid using redirects and forwards as much as you
can
• If used, don’t involve user parameters in defining the
target URL
• If you ‘must’ involve user parameters, then either
• Validate each parameter
• Use server side mapping
42. How do you address these problems?
• Develop Secure Code
• Review Your Applications
• Have an expert team review your
applications
• Review your applications yourselves
following OWASP Guidelines
43. How do you address these
problems?
• Develop Secure Code
• Review Your Applications