SEC835
OWASP Top Ten Project
Top Ten Web App Vulnerabilities
OWASP top ten web application vulnerabilities – 2007
report
Vulnerabilities
A1 - Cross Site Scripting (XSS)
A2 - Injection Flaws
A3 - Malicious File Execution
A4 - Insecure Direct Object Reference
A5 - Cross Site Request Forgery (CSRF)
A6 - Information Leakage and Improper Error Handling
A7 - Broken Authentication and Session Management
A8 - Insecure Cryptographic Storage
A9 - Insecure Communications
A10 - Failure to Restrict URL Access
Top Ten Web App Vulnerabilities
OWASP top ten web application vulnerabilities – 2010
report
Vulnerabilities
A1 - Injection Flaws
A2 - Cross Site Scripting (XSS)
A3 – Broken Authentication and Session Management
A4 - Insecure Direct Object Reference
A5 - Cross Site Request Forgery (CSRF)
A6 – Security misconfiguration
A7 - Insecure Cryptographic Storage
A8 - Failure to Restrict URL Access
A9 – Insufficient transport layer protection
A10 – Unvalidated redirect and forwards
Cross-Site Scripting and Injection Flows
See Week 10 materials
Insecure Direct Object Reference
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. Attackers can
manipulate those references to access other
objects without authorization.
IDOR Protection
Avoid exposing direct object references to users
by using either of
an index,
indirect reference map,
or other indirect method that is easy to validate.
If a direct object reference must be used, ensure
that the user is authorized before using it.
Validate any private object references
extensively with a white list approach
Cross-Site Request Forgery
CSRF forces a victim browser to send a request to a
vulnerable application, after a user is logged-on. A user
can be tricked by an image link for example.
A vulnerable application (or html page) starts acting on
behalf of a user, using the opened session. It can perform
actions designed by the attacker, e.g. transfer money from
the victim account
Affected page performs the action that appears to come
from a legitimate user
The malicious code often resides on other site, not on the
victim site, that’s why named as cross-site
Cross-Site Request Forgery
XSS exploits the trust a user has for a particular
site, when CSRF exploits the trust a site has for a
particular user
CSRF occurs when the application rely solely on
automatically submitted credentials such as
session cookies, basic authentication credentials,
source IP addresses, SSL certificates, or Windows
domain credentials.
CSRF Protection
A user must be re-authenticated by generating and then requiring some type of
authorization token that is not automatically submitted by the browser.
Insert custom random tokens into every form and URL that will not be
automatically submitted by the browser
For sensitive data or value transactions, re-authenticate or use transaction
signing
Do not use GET requests (URLs) for sensitive data or to perform value
transactions. Use only POST methods when processing sensitive data from the
user
POST alone is not sufficient. It must be combined with random tokens and reauthentication
Limit the lifetime of authentication cookies
Ensure that there are no XSS vulnerabilities in your application. XSS
vulnerabilities are not required for CSRF success but may aggravate the CSRF
result
Security misconfiguration
Security holes that occur due to wrong,
weak, or contradicted configuration
parameters
Mostly relate to network and servers
configuration
Security misconfiguration
protection
Standard hardening procedures must apply
to all infrastructure sw/hw
Updates and patching
Application code version control
Insecure cryptographic store
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…)
Hard coding keys, and storing keys in
unprotected stores
Strong crypto mechanism
Do not create cryptographic algorithms. Only use approved public
algorithms such as AES, RSA public key cryptography, and SHA-256
or better for hashing.
Do not use weak algorithms, such as MD5 / SHA1. Favor safer
alternatives, such as SHA-256 or better.
Generate keys offline and store private keys with extreme care. Never
transmit private keys over insecure channels
Ensure that infrastructure credentials such as database credentials or
MQ queue access details are properly secured (via tight file system
permissions and controls), or securely encrypted and not easily
decrypted by local or remote users
Ensure that encrypted data stored on disk is not easy to decrypt. For
example, database encryption is worthless if the database connection
pool provides unencrypted access.
Strong crypto mechanism (cont)
Data in rest must be encrypted with the highest possible
granularity, relevant to the data’s sensitivity classification.
Field encryption will be implemented for highly sensitive data.
Data files, folders, or whole-disk encryption can be used to protect
data as a batch function. However, if the data contains sensitive
items, then field encryption must be implemented prior to using
bulk encryption
Encryption keys must be protected at the same level or
higher as the data.
Strong crypto mechanism (cont)
All keying materials must be destroyed immediately after
use.
Encryption keys must not be hardcoded
Encryption keys must not be stored in audit logs.
An encryption key can be used for one purpose only.
Memory protection
Allocate two different buffers used for:
• Plaintext data
• Encrypted data
Erase data traces from the buffers immediately after use.
Failure to restrict URL access
Access to web pages thru “hidden" or "special"
URLs, rendered only to administrators or
privileged users in the presentation layer, but
accessible to all users if they know it exists
Access to “hidden” files, such as static xml files
without authorization
Code that enforces an access control policy but is
out of date or insufficient
Code that evaluates privileges on the client but not
on the server
URL access protection
Role-based access control to the application
functions
Always ensure that administrative and high
privilege actions are protected
Locate application libraries outside of the
web root
Block access to all file types that your
application should never serve
Insufficient transport layer
protection
Failure to encrypt network traffic for all
authenticated connections
Common flaws:
Only login activity is protected with SSL
Backend communication is not protected
Insufficient transport layer
protection
Communication to end user always occurs
over SSL
All sensitive actions are protected, not only
login
Backend communication is protected with
TLS
Unvalidated redirects and
forwards
Without proper validation, attackers can
redirect victims to phishing or malware
sites, or use forwards to access unauthorized
pages.
Unvalidated redirects and
forwards - protection
Avoid using redirects and forwards
If used, don’t involve user parameters in
calculating the destination.
If destination parameters can’t be avoided,
ensure that the supplied value is valid, and
authorized for the user.
For 2007 items
See below
Malicious File Execution
Occurs when a developer accepts file names
or files from a user without validation
Typical examples include: .NET assemblies
which allow URL file name arguments, or
code which accepts the user’s choice of
filename to include local files.
A common vulnerable construct:
include $_REQUEST['filename’];
Malicious File Execution (cont)
Other methods of attacks:
Hostile data being uploaded to session files, log
data, and via image uploads (typical of forum
software)
XML documents submitted by an attacker may
have a hostile DTD that forces the XML parser
to load a remote DTD, and parse and process
the results
Protection
This vulnerability is difficult to determine
Automatic testing is not capable to validate the use of
parameters
Security remedy must start from the architecture
and design
Ensure that the 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.
Protection (cont.)
Recommendations
Use indirect object reference map
Strong user data input validation (white list strategy)
Check any user supplied filenames or files
In Java, consider implementing a chroot jail or other
sandbox mechanisms in order to isolate applications
In J2EE, ensure that security manager is enabled and
permissions are controlled
Information leakage
See week 9 materials
Lab task
Read OWASP Top Ten Project Articles
Work on your spreadsheet
Crypto: cells E3, A19
IDOR: cells D3, A26
XSRF: cells F3, A21, A23
URL access: cells C3, A5
Transport Layer: cells G3, A24
Redirects and forwards: cells H3, A25
Useful links
https://www.owasp.org/index.php/CrossSite_Request_Forgery_(CSRF)
https://www.owasp.org/index.php/CrossSite_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/Transport_Layer_Protec
tion_Cheat_Sheet
https://www.owasp.org/index.php/Authentication_Cheat_S
heet