How To Test For The OWASP Top 10

10/3/2017 How to Test for the OWASP Top 10
Print
How to Test for the OWASP Top 10
Table of Contents:
Course Overview and Objec ves
Module 1: Tes ng for the OWASP Top 10: Part 1
Module Overview and Objec ves
A1: Injec on
A1: Injec on
Injec on: Examples
SQL Injec on
How to Check for Injec on
How to Test for Injec on
How to Protect Against Injec on
A2: Broken Authen ca on and Session Management
Broken Authen ca on and Session Management: Examples
How to Check for Broken Authen ca on and Session Management
How to Protect Against Broken Authen ca on and Session Management
A3: Cross-site Scrip ng (XSS)
A3: Cross-Site Scrip ng (XSS)
Defacement and Phishing with XSS Vulnerabili es
How to Check for Cross-Site Scrip ng
Code Reviewing for XSS Vulnerabili es
HTML Encoding
HTML Encode Method
An -XSS Library
HTTP-only Cookies
Frame Restric ons
A4: Insecure Direct Object References
How to Check for Insecure Direct Object Reference
How to Test for Insecure Direct Object References
How to Protect Against Insecure Direct Object References
A5: Security Misconfigura on
How to Check for Security Misconfigura on
How to Protect Against Security Misconfigura on
Module Summary
Module 2 - Tes ng for the OWASP Top 10: Part 2
A6: Sensi ve Data Exposure
Sensi ve Data Exposure: Common Causes
Man-in-the-Middle A ack
Insecure Cryptographic Storage: Scenarios
How to Check for Sensi ve Data Exposure
How to Protect Against Sensi ve Data Exposure
A7: Missing Func on Level Access Control
Missing Func on Level Access Control: Scenarios
How to Check For Missing Func on Level Access Control
How to Protect Against Missing Func on Level Access Control
A8: Cross-Site Request Forgery (CSRF)
How to Check for Cross-Site Request Forgery
How to Protect Against Cross-Site Request Forgery
A9: Using Components with Known Vulnerabili es
https://cloud.scorm.com/content/courses/NPLR2B56L9/htot10_270614_v28acd0ecc-4567-4fad-aeff-58ab79e41473/0/tst211_c_htot10_270614_v2/C… 1/48
Remedia on against Components with Known Vulnerabili es
A10: Unvalidated Redirects and Forwards
How to Check for Unvalidated Redirects and Forwards
How to Protect Against Unvalidated Redirects and Forwards
Module Summary
TEAM Mentor eKnowledge
Thank You
Course Overview and Objec ves
Course Overview
This course explains how testers and developers can determine if their
Web applica ons are vulnerable to the Top 10 security vulnerabili es
iden fied by the Open Web Applica on Security Project (OWASP). It also
explains how to protect Web applica ons against these vulnerabili es.
Course Objec ves
Test if a Web applica on is vulnerable to the OWASP Top 10.
Learn how to protect your Web applica on against the OWASP Top 10.
This course explains how testers and developers can determine if their Web applica ons are
Narra on: vulnerable to the top 10 security vulnerabili es iden fied by the Open Web Applica on Security
Project (OWASP). It also explains how to protect Web applica ons against these vulnerabili es.
In this course, you will learn how to test your applica on against the OWASP Top 10 and you will
learn how to protect your applica ons against these security vulnerabili es.
Module 1: Tes ng for the OWASP Top 10: Part 1

Module Overview
The OWASP Top 10 lists the most serious and
prevalent security vulnerabili es iden fied for
Web applica ons. This module explains the first
five vulnerabili es iden fied in the OWASP Top
10 and the mi ga ons you can use to reduce the
risk to your applica on.
Topics covered in this module:
A1 – Injec on
A2 – Broken Authen ca on and Session
Management
A3 – Cross-site Scrip ng (XSS)
A4 – Insecure Direct Object References
A5 – Security Misconfigura on
Module Objec ves
A er comple ng this module, you will be able to:
Determine if a Web applica on is vulnerable
to the top five security vulnerabili es iden fied
in the OWASP Top 10.
Explain how to protect the applica on against
these security vulnerabili es.
The OWASP Top 10 lists the most serious and prevalent security vulnerabili es iden fied for
Narra on: Web applica ons. This module explains the first five vulnerabili es iden fied in the OWASP
Top 10 and the mi ga ons you can use to reduce the risk to your applica on.
A er comple ng this module, you will be able to determine if a Web applica on is vulnerable
to the top five security vulnerabili es iden fied in the OWASP Top 10 and explain how to
protect the applica on against these security vulnerabili es.
A1: Injec on
A1 I j
A1: Injec on
An injec on vulnerability is created in code

whenever untrusted data is executed as part of a
command without prior valida on. This primarily
occurs because a developer improperly mixes code
and data. It is important for you to understand the
context in which your data will be used, because
this will affect the a ack vectors that are applicable.
Different types of injec on a acks include:
SQL injec on
Opera ng system command injec on
Buffer overflows
LDAP injec on
XML and XPath injec on
The most common injec on type flaw is SQL
injec on. Data supplied by the a acker is
interpreted as part of the SQL command, which is
then executed on the database.
A successful injec on a ack can allow an a acker
to:
Steal data from tables not accessible via the
interface.
Insert or update malicious content in the
database.
Steal content from files.
Gain complete access to the database server.
Chain exploits.
Gain access to other networked servers.
An injec on vulnerability is created in code whenever untrusted data is used as part of

Narra on: executed commands. This primarily occurs because a developer improperly mixes code
and data. It is important to understand the context in which your data will be used,
because this will affect the a ack vectors that are applicable.
The most common injec on type is SQL injec on. Data supplied by the a acker is
interpreted as part of the SQL command, which is then executed on the database.
Other common a ack vectors include opera ng system command injec on, buffer
overflows, LDAP injec on issues, and XML and XPath injec on.
A successful injec on a ack can allow an a acker to access databases and files, steal
and modify content, gain complete access to the database server, chain exploits, and
gain access to other networked servers.
I j E l
Injec on: Examples
When you are tes ng an applica on for injec on vulnerabili es, you must understand the
context in which your applica on will interpret the input.
Click each tab to view different examples of injec on vulnerabili es.
SQL Example
Injec on
String query = "SELECT * FROM accounts WHERE custID=' " +
request.getParameter("id") +" ' ";
In this example, the request parameter "id" is used directly in the SQL
query. If an a acker supplies the parameter “id”, then the a acker can
break out of this command and execute an arbitrary SQL query on the
database, thereby reading, wri ng, or dele ng any data the database
user has access to.
NOTE: For more informa on, see the TEAM Mentor ar cles SQL Injec on
A ack and Parameterize Dynamic SQL in Stored Procedures.
OS Example
Command
Injec on String script = System.getProperty("SCRIPTNAME");
if (script != null)
Run me.exec(script);
In this example, the Java call to Run me.exec func on allows a ackers
to execute any command on the system if they can control the
SCRIPTNAME property.
NOTE: For more informa on, see the TEAM Mentor ar cle Command
Injec on.
XML Example
Injec on
Consider the following XML document used for user authen ca on by a
hypothe cal applica on:
<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>joe</username>
<pass>p4$$w0rd</pass>
<role>Administrator</role>
<UserID>1</UserID>
</user>
<user>
<username>jim</username>
<pass>$3cuR3</pass>
<UserID>2</UserID>
<role>User</role>
</user>
</users>
In this applica on, when a user registers, the applica on automa cally
uses the format:
<user>
<username>[[Username]]</username>
<pass>[[Password]]</pass>
<role>User</role>
<UserID>[[NextUserID]]</UserID>
</user>
If the input is not properly validated, an a acker can inject malicious
XML into the document. In the case that follows, the a acker has
supplied elements that do not break the document structure, and the
applica on uses the elements to determine the role of the user. The
a acker has supplied informa on about the user he is crea ng, and the
first part of the next user that he doesn’t care about. A er the a ack,
the XML structure looks like the following (with the a acker's input in
)
red), and the applica on cannot determine who is a legi mate user and
who is not.
<users>
<user>
<username>joe</username>
<pass>p4$$w0rd</pass>
<UserID>1</UserID>
</user>
<user>
<username>jim</username>
<pass>$3cuR3</pass>
<role>User</role>
<UserID>2</UserID>
</user>
<user>
<username>hacker</username>
<pass>MoreS3cure!</pass>
<UserID>3</UserID>
</user>
<user>
<username>test</username>
<pass>test</pass>
<role>User</role>
<UserID>[[NextUserID]]</UserID>
</user>
</users>
Sample Query:
string(//user[username/text()='test' and
password/text()='abcd']/account/text())
For more informa on, see TEAM Mentor ar cle XML Injec on.
NOTE:
LDAP In this example, accomplishing LDAP injec on is dependent on whether

Injec on the variable $username is validated or not. For example, if an a acker
inputs “*” in place of $username, and the input is not validated, the
system might return all the usernames in the LDAP database.
String ldapSearchQuery = "(cn=" + $userName +
")";
System.out.println(ldapSearchQuery);
When you are tes ng an applica on for injec on vulnerabili es, you must understand
Narra on: the context in which your applica on will interpret the input.
Click each tab to view different examples of injec on vulnerabili es.
SQL I j
SQL Injec on
When unsani zed user input is used to construct SQL queries, a malicious user can alter the
SQL statement to change its original intent.
In the “Forgot Password” form shown, the user input to the e-mail parameter is used by the
applica on to form an SQL query. A malicious user could input a payload such as ‘OR 1=1.
Without sani za on, the payload could be used to execute a completely different query
against the database than was intended.
From the drop-down list, select a username value, and click Submit to view the outcome.
User input is o en used to construct SQL statements in order to retrieve data from a
Narra on: database. When input is not properly sani zed, a malicious user can alter the SQL
statement to change its original intent.
In the “Forgot Password” form shown, the email parameter is user-controlled. The
parameter value is extracted and reused while forming a query, and is stored in the
sqlQuery variable. The query is then run and values are retrieved from the database.
The query is dynamic -- no ce that the value of the email parameter is appended to
the query. Therefore, a malicious user could pass a payload such as ‘OR 1=1 in the
“email” parameter, and run a totally different query against the database instead—
thereby stealing sensi ve informa on.
From the drop-down list, select a username value and click Submit to view the
outcome.
H Ch k f I j
How to Check for Injec on
To check for different types of injec on vulnerabili es, follow the steps listed in these tables.
Some steps are common to all types of injec on vulnerabili es, and some are unique to
each type.
Click each tab to learn how to check for each type of injec on vulnerability.
Command 1. Iden fy any code within the applica on capable of passing user
Injec on supplied data to the system shell.
2. Iden fy the request parameters that it extracts user input from.
3. Create a fuzz list, which contains a variety of payloads that you can
use to fuzz the OS
command that is being used. You want to be able to run your own
commands.
4. Use a fuzzer, which uses these payloads in every request parameter
that is a target.
5. Determine if the payloads used to create an OS command cause
the applica on to behave
differently.
6. Confirm the possibility of OS command injec on by crea ng a new
file and check for its existence.
You can also ini ate network connec ons to a server that you control
and monitor its network
traffic.
SQL injec on 1. Iden fy if the feature you are tes ng retrieves or stores content
from or to a backend database.
2. Iden fy if it uses user input to form the backend query.
3. Iden fy the request parameters from which it extracts user input.
4. Iden fy the data type of the parameter stored in the database if
possible.
use to fuzz the backend
database. You want to be able to run your own queries.
that is a target.
7. Study the responses generated by the applica on in response to
various payloads used while
fuzzing the database.
XML 1. Determine if the feature you are tes ng reads or writes from or to
Injec on an XML file.
2. Iden fy if it uses user input to form the query it runs.
use to fuzz the XPath query that
is being used. You want to be able to run your own queries.
that is a target.
6. Determine whether the applica on handles malformed XML input
gracefully.
7. Determine whether the applica on is vulnerable to XML en ty
injec on or expansion a acks by
checking if the parser expands XML en es.
LDAP 1. Determine if the feature you are tes ng interacts with an LDAP
Injec on database.
2. Determine if it uses user input to form the query it runs.
3. Iden fy the search filter meta-characters from which it extracts
user input.
use to fuzz the LDAP query
being used. You want to be able to run your own queries.
Follow the steps listed here to check for various types of injec on vulnerabili es.
Narra on:
Click each tab to learn how to check for each type of injec on vulnerability.
H T f I j
How to Test for Injec on
To test for injec on vulnerabili es, you use the same tools used by a ackers.
Click each tab to learn more about tes ng for each type of injec on vulnerability.
Code In code injec on tes ng, you input informa on that is then processed by
Injec on the web server. Typically, the focus of the tes ng is the server-side
scrip ng engine run by the web server, such as ASP or PHP, and the
informa on entered by the tester is processed either as dynamic code or
as an included file. To defend against these a acks, use input valida on
and secure coding prac ces.
SQL To test for SQL injec on, iden fy all input fields used to cra SQL queries
Injec on within the applica on. This includes hidden fields of POST requests. Test
each field separately and then in combina on if possible.
It is also cri cal to consider the informa on stored in HTTP headers and
cookies that is passed back and forth between the browser and the SQL
applica on.
The two most common ini al tests of a SQL applica on are:
Adding a single quote (‘), which terminates a string in SQL syntax.
Adding a semicolon (;), which terminates a SQL statement.
In both cases, if these tokens are not filtered by the SQL applica on, an
error is generated and can result in data leakage or command execu on.
XML To test for XML injec on, manipulate or compromise the logic of an XML
Injec on service or applica on by injec ng unintended content or structures into
the parser. An a ack is successful if the XML parser fails to properly
validate the data.
Tes ng for XML injec on includes:
Meta-character injec on
External en ty injec on
Tag injec on
LDAP To test for LDAP injec on, manipulate the input parameters submi ed to
Injec on the LDAP server, which are then passed to internal search, add, and
modify func ons. The goal is to iden fy metacharacters in a query which,
when executed by the applica on, result in unauthorized access to
content, data leakage, applica on restric on evasion, and poten al
modifica on of objects within an LDAP tree structure.
Tes ng for injec on vulnerabili es is similar to checking for them, but the tools used at
Narra on: the tes ng stage might differ from those used for checking during development.
Specifically, when tes ng for injec on vulnerabili es, you use the same tools used by
a ackers.
Click each tab to learn more about tes ng for each type of injec on vulnerability.
H P A i I j
How to Protect Against Injec on
Let’s look at how you can protect your applica on

from injec on vulnerabili es.
To prevent an injec on a ack, keep untrusted data
separate from commands and queries as follows:
Use a safe API, which avoids the use of an
interpreter en rely or provides a parameterized
interface. Also, validate your assump ons about the
APIs you use.
Carefully escape special characters for the
context.
Use whitelist input valida on with appropriate
canonicaliza on.
Note: You cannot use this technique as a complete
defense against an injec on a ack, because many
applica ons require special characters in their
input.
Let’s look at how you can protect your applica on from injec on vulnerabili es. To
Narra on: prevent an injec on a ack, you should keep untrusted data separate from commands
and queries. You can do this by using a safe API, which avoids the use of an interpreter
en rely or provides a parameterized interface. Beware of APIs, such as stored
procedures that appear parameterized, that may s ll allow an injec on a ack.
If a parameterized API is not available, you should carefully escape special characters
using the specific escape syntax for that interpreter. OWASP's ESAPI has some of these
escaping rou nes.
Finally, you should use whitelist input valida on with appropriate canonicaliza on to
protect against injec on. OWASP's ESAPI has an extensible library of whitelist input
valida on rou nes.
Note that you cannot use this technique as a complete defense against an injec on
a ack, because many applica ons require special characters in their input.

The broken authen ca on and

session management
vulnerability occurs when
applica on func ons related to
authen ca on and session
management are not
implemented correctly.
For example, if the session
tokens are not invalidated on
logout, an a acker could reuse a
session token a er the user
believes they have securely
logged out of the applica on.
A erwards, anyone using the
computer can impersonate the
user.
Major threats related to broken
authen ca on and session
management can include:
Stealing another user’s
session and masquerading as
that user.
Performing sensi ve
opera ons as the user whose
session was stolen.
If an admin portal exists,
eventually gaining complete
control of the en re applica on.
Now, let’s discuss broken authen ca on and session management. This vulnerability
Narra on: occurs when applica on func ons related to authen ca on and session management
are not implemented correctly.
In many cases, the developer makes the incorrect assump on that session tokens are
automa cally invalidated at logout or managed by the opera ng system. This can
lead to several serious threats, such as stealing another user’s session and then
masquerading as that user; performing sensi ve opera ons as the user whose session
was stolen; and poten ally gaining complete control of the applica on and possibly
the system, if the applica on has administra ve capabili es.
B k A h dS i M E l
Broken Authen ca on and Session Management: Examples
Web sites use session iden fiers or session IDs to iden fy users a er they have logged in.
When a session ID is improperly handled, it can be stolen by a ackers and reused to hijack
an online iden ty or account. Session IDs are stored in the following loca ons:
Cookies
Hidden fields on the web form
URLs
Click each tab to view examples of session ID storage loca ons.
Session ID The
stored in a following
URL example
shows
how a
session
ID is
stored in
a URL.
Session ID The following example shows how a session ID is stored in a cookie.

stored in a
cookie
User visits h p://sampletestapp.com/login.aspx

Session A session ID with value 23e435ef114d78ad23e435ef114d78ad is generated on the server and stored in a
Fixa on cookie called SESSID on the client.
The user completes the login form and submits the form
The creden als are verified, but a new value is not generated for the user’s session. The cookie s ll
contains 23e435ef114d78ad23e435ef114d78ad.
This means that the applica on could be vulnerable to session fixa on.
An a acker could look at a user’s session cookie before the user logs in (local access is needed). The
a acker can then log in, edit his or her own SESSID cookie to hold the value
23e435ef114d78ad23e435ef114d78ad, and refresh the page, thereby gaining access to the user’s session.
On successful login, the SESSID cookie has a value 23e435ef114d78ad23e435ef114d78ad.

Session The user then clicks logout.
Invalida on The applica on does NOT clear the session state and delete the user’s session from the server. The
A er applica on only clears the SESSID cookie from the user’s browser, se ng it to a null value. The old session ID
Logout can s ll be reused in a request.
Web sites use session iden fiers or session IDs to iden fy users a er they have logged
Narra on: in. When a session ID is improperly handled, it can be stolen by a ackers and reused
to hijack an online iden ty or account. Session IDs are stored in cookies, hidden fields
on the web form, or URLs.
Click each tab to view examples of session ID storage loca ons.
H Ch k f B k A h dS i M
How to Check for Broken Authen ca on and Session Management
You can iden fy broken authen ca on and session management vulnerabili es in

your Web applica on by looking for unprotected creden als and session IDs.
Use the following steps to iden fy these vulnerabili es:
Check if creden als are protected when stored using hashing or encryp on. This
is possible only if access to the source code is available.
Check if account management func ons, such as account crea on, password
changes, password recovery, and weak session IDs, are implemented in a secure
manner.
Check if session IDs are transmi ed as query string parameters in the URL.
Check if session IDs are changed a er a user successfully logs in to the
applica on.
Check if session IDs me out a er a period of inac vity.
Ensure that the applica on allows a user to log out and terminates the session
on the server.
Ensure that all passwords, session IDs, and other sensi ve informa on are sent
only over TLS.
Check if a Web applica on allows a user to authen cate using a previous or
exis ng session ID.
Check if you are able to force a known session ID on a user.
The following code example is vulnerable because it does not invalidate the current
session before logging the user in, which allows a session fixa on a ack.
protected void Login(object sender, EventArgs e)
{
// Check for Username and password
if (checkUsernamePassword(user, password))
{
Session["LoggedIn"] = true;
}
else
{
error.Text = "Wrong username or password";
}
}
To check for broken authen ca on and session management, look for the wide variety
Narra on: of issues listed on-screen related to unprotected creden als and session IDs.
The code example shown here is vulnerable because it does not invalidate the current
session before logging the user in, which allows a session fixa on a ack.
H P A i B k A h dS i
How to Protect Against Broken Authen ca on and Session
Management
Follow these steps to help protect your Web applica on

against broken authen ca on and session management
vulnerabili es:
Make a single set of strong authen ca on and session
management controls available to developers. These
controls should:
– Meet all authen ca on and session management
requirements defined in OWASP’s Applica on Security
Verifica on Standard (ASVS) areas V2
(Authen ca on) and V3 (Session Management).
– Have a simple interface. ESAPI Authen cator and
User APIs are good examples to emulate, use, or
build upon.
Make strong efforts to avoid cross-site scrip ng (XSS)
flaws, which can be used to steal session IDs. For more
details, see the A3: Cross-Site Scrip ng (XSS) topic in this
module.
Do not a empt to implement session management on
your own. Use the session management provided by the
development framework that you use.
Ensure that IDs are created randomly and from a
sufficiently large space.
Ensure that exis ng sessions are invalidated on the
server on logout.
Ensure that a new session is created at login me.
Let’s look at how you can protect your Web applica on against broken authen ca on
Narra on: and session management vulnerabili es.
Make a single set of strong authen ca on and session management controls
available to developers. These controls should meet all the authen ca on and session
management requirements defined in OWASP’s Applica on Security Verifica on
Standard areas V2 Authen ca on, and V3 Session Management. These controls
should also have a simple interface. Consider the ESAPI Authen cator and User APIs as
good examples to emulate, use, or build upon.
Also, make strong efforts to avoid cross-site scrip ng flaws, which can be used to steal
session IDs. For more informa on, see Cross-Site Scrip ng, the next topic in this
module.
Do not a empt to implement session management on your own. Use the session
management provided by the development framework that you use.
Ensure that IDs are created randomly and from a sufficiently large space.
Ensure that exis ng sessions are invalidated on the server on logout.
In addi on make sure that a new session is created at login me.
NOTE: For more informa on, see these TEAM Mentor ar cle(s): Cookieless Authen ca on,
Sensi ve Cookie in HTTPS Session Without Secure A ribute, and How to Test for Session
Hijacking Bugs.
A3: Cross-site Scrip ng (XSS)

A3: Cross-Site Scrip ng (XSS)
Cross-site scrip ng (XSS) vulnerabili es occur when an applica on dynamically includes
unvalidated user input in a Web page. The input might include malicious scripts.
Threats related to XSS include:
Stealing the user’s session informa on that is usually stored in a session cookie.
Execu ng malicious code in the user’s browser.
Gaining complete control of the user’s system.
Storing malicious content in the database that will get executed by other users when it is
viewed.
Select your entry from the drop-down list, and click Submit.
Cross-site scrip ng (XSS), vulnerabili es occur when an applica on dynamically

Narra on: includes unvalidated user input in a Web page. The input might include malicious
scripts. Cross-site scrip ng is also known as script injec on or HTML injec on.
Cross-site scrip ng vulnerabili es allow an a acker to steal the user’s session
informa on stored in a session cookie, execute malicious code in the user’s browser,
gain complete control of the user’s system, and store malicious content in the
database that is executed by other users when it is viewed.
Cross-site scrip ng vulnerabili es are potent because the malicious code executes in
the context of the vic m’s session, allowing the a acker to bypass normal security
restric ons.
Consider the password-reset form shown here. As you see in its ASP.NET code, when
an invalid email address is entered, it is reflected back to the user as part of an error
message. No ce what happens when data that is in the wrong format is entered.
Select your entry from the drop-down list, and click Submit.
Defacement and Phishing with XSS Vulnerabili es
An a acker can leverage a cross-site scrip ng vulnerability to modify the appearance

Narra on: and behavior of affected Web sites.
A er finding a script injec on bug in the target applica on, the a acker cra s a
malicious link that forces the Web applica on to generate a forged login page.
The a acker then a empts to trick a vic m into opening the malicious link by
including it in a fake email message.
When clicked, the link submits the malicious payload to the server, and the a acker’s
fake login form is returned to the vic m’s browser. Because the server is legi mate
and its cer ficate is valid, the vic m trus ully submits login creden als. The fake login
page sends the vic m’s user name and password to the a acker instead of to the Web
applica on.
With the vic m’s user name and password, the a acker can now access the vic m’s
account on the affected applica on.
H Ch k f C Si S i
How to Check for Cross-Site Scrip ng
Follow these steps to check for cross-site scrip ng:

1. Determine if the feature that is being tested uses user input.
3. Create a fuzz list, which contains a variety of payloads that you can use to fuzz the
backend business
logic that is being used. You want to inject malicious JavaScript, have it processed by
the backend
business logic, and render it on the end user’s browser.
4. Use a fuzzer, which uses these payloads in every request parameter that is a
target.
5. Determine whether user-supplied input is echoed in the response to a request.
6. Determine if all user-supplied input sent back to the browser is verified to be safe
(through input
valida on).
7. Determine if user input is properly escaped depending on the context of the data
before including it on
the output page.
Sample vulnerable code
Response.Write(Request.Params[“Email”]).
To check for cross-site scrip ng, follow the steps listed on-screen.
Narra on:
Determine if a specific feature uses user input without valida on and whether that
input can be used to echo a response to a request.
You can use a fuzzing tool to iden fy and exercise poten al cross-site scrip ng
vulnerabili es and determine whether there is insufficient input valida on.
The sample code shown here illustrates a poten al cross-site scrip ng vulnerability in
the “Email” parameter. If the input to the “Email” parameter is not properly validated,
it would be possible to inject code into the webpage that could be used to redirect the
user and compromise informa on.
C d R i i f XSS V l bili
Code Reviewing for XSS Vulnerabili es
During a code review, cross-site scrip ng issues can be iden fied using the following
flowchart. For more details on each step of the review process, click the corresponding
component of the chart.
Input?
If the sec on of code does not take any input from the user or from components
such as databases and untrusted services, then move on to the next sec on of
code.
Dynamic Output?
If input is not used to dynamically generate output, and if input does not appear in
error messages displayed to the user, then move on to the next sec on of code.
Input Sani zed?
If input is not sani zed prior to genera ng output, then the code is most likely
vulnerable to cross-site scrip ng vulnerabili es.
Output Encoded?
If output is not encoded, then the code is most likely vulnerable to cross-site
scrip ng vulnerabili es.
During code review, you can iden fy cross-site scrip ng issues using this flowchart.
Narra on:
Click each component of the chart for more details.
If the sec on of code does not take any input from the user or from components such
as databases and untrusted services, move on to the next sec on of code.
HTML E di
HTML Encoding
Encode all user-controlled data before outpu ng it to a Web page.
Click the tabs to view an example of an encoding-related problem and its solu on.
Example User input is included as part of the following error message:

Problem
Parameter: '<user input>' is forma ed improperly.
An a acker could a empt to inject a script by submi ng the
following input:
<script>alert(document.cookie)</script>
If this input is not properly encoded, the a acker could
perform XSS a acks.
Solu on Encode the user input into an HTML-safe encoded string to

render the a ack string harmless:
<script>alert(document.cookie)</script>
All dangerous characters are encoded, and the script is non-
executable.
You need to properly encode all user-controlled data before using it as output to a
Narra on: Web page.
Consider the scenario shown here in which user input is included as part of an error
message. An a acker could a empt to inject a malicious script as shown.
If the malicious input is processed by the applica on without being properly encoded,
the a acker could then perform XSS a acks.
The solu on is to encode the user input into an HTML-safe encoded string. The a ack
string would be rendered harmless, as shown here. With all dangerous characters
encoded, the script is rendered non-executable.
Click the tabs to view an example of an encoding-related problem and its solu on.
HTML E d M h d
HTML Encode Method
As indicated earlier, HTML encoding is a good method to reduce the risk from XSS a acks.
Most modern programming languages have encoding libraries built right into the language
that you can easily use.
For example, in the .NET Framework, the built-in HttpUtility.HtmlEncode method
can be used to convert a string into an HTML-encoded string.
using System.Web;
string encodedString =
HttpUtility.HtmlEncode(formText);
Narra on: As indicated earlier, HTML encoding is a good method to reduce the risk from XSS
a acks. Most modern programming languages have encoding libraries built right into
the language that you can easily use.
As shown in this .NET Framework code example, the H pU lity.HtmlEncode method
can be used to convert a string into an HTML-encoded string.
A XSS Lib
An -XSS Library
The An -XSS Library has an HtmlEncode method, which is a more robust version of HttpUtility.HtmlEncode.
This library uses the principle of inclusion to protect against XSS a acks. It first defines a set of acceptable characters, and
then encodes anything outside this set, including invalid characters and characters that could be used in an a ack.
The An -XSS Library has an HtmlEncode method, which is a more robust version of
Narra on: H pU lity.HtmlEncode.
This library differs from most encoding libraries in that it uses the principle of inclusion
to provide protec on against cross-site scrip ng a acks. The library first defines a set
of acceptable characters, and then encodes anything outside this set, including invalid
characters and characters that could be used in an a ack.
The principle of inclusion approach provides a higher degree of protec on against
cross-site scrip ng a acks, as shown in the example on the screen.
HTTP-only Cookies
A cookie set with the H pOnly a ribute is not accessible by client-side scripts and therefore
cannot be stolen via a cross-site scrip ng a ack.The use of HTTP-only cookies protects
against cross-site scrip ng exploits that are aimed at stealing session cookies.
The HTTP response header shown sets an HTTP-only cookie.
Set-Cookie:
USER=123; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly
The Web page shown is vulnerable to a cross-site scrip ng vulnerability. Use the drop-down
list to enable or disable HTTP-only cookies, and click Submit to test the outcome of the
configura on.
Microso Internet Explorer 6 introduced a feature to help mi gate the risk of cross-
Narra on: site scrip ng. This feature allows developers to label cookies used by their applica on
as HTTP only. A cookie set with the H pOnly a ribute is not accessible by client-side
scripts and therefore cannot be stolen via a cross-site scrip ng a ack.
The use of HTTP-only cookies protects against cross-site scrip ng exploits that are
aimed at stealing session cookies.
The HTTP response header shown sets an HTTP-only cookie.
The Web page shown is vulnerable to a cross-site scrip ng vulnerability. Use the drop-
down list to enable or disable HTTP-only cookies, and click Submit to test the outcome
of the configura on.
F R i
Frame Restric ons
A script from a given domain is not allowed to access content from another domain.
This restric on applies in many scenarios, including situa ons involving frames and
IFRAMEs. These HTML elements allow a single page to load other Web pages within
the same browser window. However, the DOM of one frame can only be accessed
from another frame if both are on the same domain.
If these restric ons were not in place, it would be possible for a malicious Web site
to manipulate data pertaining to another Web site, thereby pu ng that Web site’s
users at risk.
Some of the specific restric ons include:
window.loca on.href—This property can be set to navigate, but cannot be read
across frames. All other window.loca on.href func onality is blocked.
document.loca on.href—This property can be set to navigate, but cannot be
read across frames. All other document.loca on.href func onality is blocked.
iframe.src—This property can be set to navigate, but cannot be read across
frames.
Narra on: Scripts must follow certain security restric ons to protect sensi ve user informa on.
For example, a script from a given domain is not allowed to access content from
another domain.
This restric on applies in many scenarios including situa ons involving frames and
IFRAMEs. These HTML elements allow a single page to load other Web pages within
the same browser window. However, the DOM of one frame can only be accessed
from another frame if both are on the same domain.
If these restric ons were not in place, it would be possible for a malicious Web site to
manipulate data pertaining to another Web site, thereby pu ng that Web site’s users
at risk.
Some of the specific restric ons are shown.

An insecure direct object reference occurs when a developer

exposes a reference to an internal implementa on object. These
objects include:
Files
Directories
Database keys
Without an access control check or other protec on, a ackers
can manipulate references to internal implementa on objects
and access unauthorized data.
The major threats related to insecure direct object references
include:
Anonymous users can gain access to private content.
Unauthorized users can perform opera ons on assets owned
by other users.
An insecure direct object reference occurs when a developer exposes a reference to an

Narra on: internal implementa on object, such as a file, directory, or database key. Without an
access control check or other protec on, a ackers can manipulate these references to
access unauthorized data.
The major threats related to insecure direct object references include the possibility
that anonymous users can gain access to private content, and unauthorized users can
perform opera ons on assets owned by other users.
H Ch k f I Di Obj R f
How to Check for Insecure Direct Object Reference
To check if an applica on is vulnerable to insecure direct object references, follow

these steps:
1. Iden fy user input points – such as query string parameters, POST body
parameters, or cookies – that
the applica on uses to decide which object to display to the user.
2. Iden fy if the applica on returns data not associated with the user, by modifying
the parameters.
Perform these tests using user accounts that have different privilege levels.
Example
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt =
connection.prepareStatement(query , ... );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery();
This code is poten ally vulnerable as it returns account informa on without
verifying that the reques ng user has permissions to access the informa on.
A user can access another user's account details by modifying the acct query string
parameter as shown.
http://example.com/app/accountInfo?acct=notmyacct
To check for insecure direct object references, take the following steps:
Narra on:
First iden fy and validate user input points that the applica on uses to determine
which object can be displayed to an end user.
Then, iden fy if the applica on returns data that is not associated with the user.
It is important to perform these tests using various user accounts, preferably with
different privilege levels.
Shown here is code that is poten ally vulnerable to a direct object reference
vulnerability. This example returns account informa on without verifying that the
reques ng user has the necessary permissions to access the informa on.
H T f I Di Obj R f
How to Test for Insecure Direct Object References
To test for insecure direct object references:

1. Iden fy where an applica on uses user input to reference
objects directly.
The objects could be used to access files, database informa on,
or applica on
pages such as ASP.NET web pages.
2. Manipulate the value of the parameters used to reference
objects, and determine
if it is possible to retrieve the target objects. To do this, it would
be necessary
to bypass the authoriza on logic in the applica on.
At least two or more users should test in order to cover various
owned objects and func ons.
To test for insecure direct object references, first iden fy where an applica on uses
Narra on: user input to reference objects directly. The objects could be used to access files,
database informa on, or applica on pages such as ASP.NET web pages.
Then, manipulate the value of the parameters used to reference objects, and
determine if it is possible to retrieve the target objects. Target objects belong to other
users, and to retrieve them it would be necessary to bypass the authoriza on logic in
the applica on.
At least two or more users should test in order to cover various owned objects and
func ons.
H P A i I Di Obj R f
How to Protect Against Insecure Direct Object References
To protect against insecure direct object references

vulnerabili es, you can use the following approaches:
1. Use per-user or per-session indirect object references.
For example, instead of using the resource's database key, a
drop down list of
six resources authorized for the current user could use numbers
1 to 6 to
indicate the value the user selected. The applica on has to map
the
per-user indirect reference back to the actual database key on
the server.
OWASP’s ESAPI includes both sequen al and random access
reference
maps that developers can use to eliminate direct object
references.
2. Verify access control each me an object is referenced.
Now, let’s look at some approaches to protect against insecure direct object reference
Narra on: vulnerabili es.
You should use per-user or per-session indirect object references to prevent a ackers
from directly targe ng unauthorized resources. For example, instead of using the
resource's database key, a drop down list of six resources authorized for the current
user could use numbers 1 to 6 to indicate which value the user selected. The
applica on has to map the per-user indirect reference back to the actual database key
on the server.
OWASP’s ESAPI includes both sequen al and random access reference maps that
developers can use to eliminate direct object references.
You should also verify access control each me an object is referenced. This ensures
that the user is authorized to view or use the requested object.
NOTE: For more informa on, see the TEAM Mentor ar cle Insecure Direct Object References.

Even if you do everything else right, a misconfigura on can leave your system open to
Narra on: a ack.
Many products are shipped without secure defaults. It is therefore cri cal to define,
implement, and maintain secure configura on se ngs. This includes keeping all
so ware up-to-date, including all code libraries used by the applica on.
Be sure to stay informed about new vulnerabili es, and about tools that can help you
update your so ware and inform you of new vulnerabili es.
Threats related to security misconfigura on include the possibility that exis ng
features of the system can be misused by an a acker, that the server can be exploited
to gain access to the system, and that sensi ve informa on can be disclosed.
How to Check for Security Misconfigura on
To check for security misconfigura on, ask

yourself the following ques ons:
How out of date is the system so ware? This
includes components such as the opera ng
system, the web or applica on server, the
database so ware, and other applica ons or
libraries used to support the overall system.
If you are using a specific development
framework, such as ASP.NET or PHP, are the
se ngs of those frameworks set to their secure
values?
When handling applica on errors, how much
informa on is revealed? Eliminate occurrences
where stack traces or other overly informa ve
messages are provided to end users.
Are there any unnecessary ports or services
accounts (in par cular, default accounts) enabled
or installed?
To check for security misconfigura on vulnerabili es, there are several aspects of the
Narra on: infrastructure to consider.
Check if your system so ware is current, including the opera ng system, the web or
applica on server, the database so ware, the authen ca on system, administra ve
tools, and other applica ons or libraries that support the system. Note if you are
running older versions that contain known vulnerabili es.
Check if your development framework se ngs are set to secure values. And, examine
error-handling messages to see if they unnecessarily reveal too much informa on to
the user.
Finally, keep a list of defined ports required for the applica on’s opera on under
change control. Compare this list periodically to the open ports in the system, to
determine whether an undocumented change has occurred, and to facilitate intrusion
detec on system (IDS) monitoring.
H P A i S i Mi fi
How to Protect Against Security Misconfigura on
To protect your Web applica on against

security misconfigura on vulnerabili es,:
Establish a repeatable hardening
process that makes it fast and easy to
deploy another environment that is
properly locked down.
Implement a process for keeping
informed about and deploying all new
so ware updates and patches in a mely
manner to each deployed environment.
Develop a strong applica on
architecture that provides good
separa on and security between
components.
Periodically scan or audit your
applica on to detect future
misconfigura ons or missing patches.
To protect your Web applica on against security misconfigura on vulnerabili es,

Narra on: establish a repeatable hardening process that makes it fast and easy to deploy
another environment that is properly locked down. You should configure the
development, quality analysis, and produc on environments iden cally. Automate this
process to minimize the effort required to set up a new secure environment.
You should also establish a process for keeping informed about and deploying all new
so ware updates and patches in a mely manner to each deployed environment. This
needs to include all code libraries.
Next, develop a strong applica on architecture that provides good separa on and
security between components.
Finally, you should periodically perform scans and audits to detect future
misconfigura ons or missing patches.
NOTE: For more informa on, see the TEAM Mentor ar cle Server Misconfigura on.
M d l S
Module Summary
A1: Injec on Injec on vulnerabili es occur when untrusted data is sent to an

interpreter as part of a command or query.
When tes ng an applica on for injec on vulnerabili es, it is important
to understand the context in which your applica on will be interpre ng
your input. Look for control characters that apply to the context and can
be used to perform injec on.
To protect against injec on a acks, ensure that you keep untrusted
data separate from commands and queries.
Click each topic above to learn more.
Click here to review this topic again.
A2: Broken Broken authen ca on and session management vulnerabili es occur

Authen ca on when applica on func ons related to authen ca on and session
and Session management are not implemented correctly.
Management
You can check for broken authen ca on and session management
vulnerabili es in your Web applica on by checking if creden als and
session IDs are properly protected.
To protect your Web applica on against broken authen ca on and
session management vulnerabili es, use a single set of strong
authen ca on and session management controls. You should also avoid
XSS flaws in your Web applica on, which can lead to the of session
IDs.
A3: Cross Site A cross-site scrip ng (XSS) a ack is a type of injec on a ack that
Scrip ng (XSS) primarily affects HTML and JavaScript. XSS flaws occur whenever an
applica on takes untrusted data and sends it to a Web browser without
proper valida on and escaping.
To test a Web applica on for cross-site scrip ng vulnerabili es, check if
all user-supplied input sent back to the browser is verified to be safe
through input valida on. Also check if user input is properly escaped
before it is included in the output page.
You can prevent XSS vulnerabili es by keeping untrusted data separate
from ac ve browser content.
A4: Insecure Insecure direct object references occur when a Web applica on does
Direct Object not validate a client’s access to a resource.
References
Code reviews and tes ng are effec ve at iden fying direct object
reference vulnerabili es.
You can prevent insecure direct object references by using per-user or
per-session indirect object references and verifying access controls each
me an object is referenced.
A5: Security Security misconfigura on can occur anywhere in your applica on stack.
Misconfigura on
You can check for and fix security misconfigura on vulnerabili es by
performing a repeatable security hardening process across the en re
stack.
To protect your system against security misconfigura on, establish a
repeatable security hardening process and a strong applica on
architecture that provides good separa on and security between
components.
Module 2 - Tes ng for the OWASP Top 10: Part 2

Module Overview
This module explains how to test for the last five
vulnerabili es iden fied in the OWASP Top 10 list
and the mi ga ons you can use to reduce the
risk for your applica on.
Topics covered in this module:
A8: Cross-Site Request Forgery
A9: Using Components with Known
Vulnerabili es
Module Objec ves
A er comple ng this module, you will be able to:
Determine if a Web applica on is vulnerable
to the last five security vulnerabili es iden fied
in the OWASP Top 10 list.
Explain how to protect the applica on against
these security vulnerabili es.
Narra on: This module explains how to test for the last five vulnerabili es on the OWASP Top 10 list and
the mi ga ons you can use to reduce the risk for your applica on.
A er comple ng this module, you will be able to determine if a Web applica on is vulnerable
to the last five security vulnerabili es iden fied in the OWASP Top 10 list and explain how to
protect the applica on against these security vulnerabili es.

Sensi ve data exposure occurs when Web

applica ons do not protect sensi ve data with
appropriate encryp on or hashing.
Examples of sensi ve data include:
Credit card details
Social security numbers
Authen ca on creden als
A ackers may steal or modify weakly protected
data to conduct iden ty the , credit card fraud, or
other crimes.
Narra on: Sixth on the OWASP Top 10 list is sensi ve data exposure. This vulnerability occurs
when Web applica ons do not protect sensi ve data, such as credit cards, social
security numbers, and authen ca on creden als, with appropriate encryp on or
hashing. A ackers may steal or modify weakly protected data to conduct iden ty
the , credit card fraud, or other crimes.
S i D E C C
Sensi ve Data Exposure: Common Causes
Common condi ons that can lead to exposure of

sensi ve data include:
Lack of transport layer security. Transmi ng
data in plaintext, without using SSL/TLS, allows for
intercep on of sensi ve informa on via man-in-
the-middle a acks. For example, the Firesheep
tool monitors open wireless networks and sniffs
user session informa on from some social
networking sites. This allows the a acker to take
over the session and impersonate the user. Use of
SSL/TLS prevents this kind of a ack.
Insufficiently protected creden als. A ackers
can more easily gain access to authen ca on
creden als if they are not well protected. (Usually,
some other vulnerability has to be present for the
a acker to recover the creden als.) He can use
them to impersonate the user whose creden als
have been compromised.
Insecure cryptographic storage. Insecure
cryptographic storage can result from issues such
as use of custom cryptography, insecure
implementa on of strong algorithms, use of
insecure algorithms, and insecure key storage. It
can allow a ackers to gain access to sensi ve data
at rest.
Sensi ve data exposure is commonly caused by lack of transport layer security (TLS),
Narra on: insufficiently protected creden als, and insecure cryptographic storage. Let’s take a
look at each of these condi ons.
Transmission of data without transport layer security (TLS) allows a ackers to
intercept sensi ve informa on using man-in-the-middle a acks. One common a ack
vector is exposed by the Firesheep tool. Firesheep monitors open wireless networks for
informa on about user sessions from some social networking sites. Once that
informa on has been sniffed from the network, the a acker can take over the user's
session. This allows the a acker to impersonate the user. Use of SSL/TLS prevents this
kind of a ack.
Insufficiently protected creden als make it easier for an a acker to gain access to
authen ca on creden als. (Usually, another vulnerability has to be present for the
a acker to recover the creden als.) Once the a acker has the creden als, he can
impersonate the user whose creden als have been compromised. A ackers usually
target privileged accounts to take over the applica on. They may then leverage other
vulnerabili es to take over the applica on pla orm and use it to pivot to other
a acks.
Finally, insecure cryptographic storage can result from issues such as use of custom
cryptography, insecure implementa on of algorithms, use of weak algorithms, and
insecure key storage. This can allow an a acker to gain access to sensi ve data at
rest.
NOTE: For more informa on, see the TEAM Mentor ar cles Insecure Transport and Network
Eavesdropping A ack.
For more informa on, see the TEAM Mentor ar cle Insufficiently Protected Creden als.
M i h Middl A k
Man-in-the-Middle A ack
The following scenario describes a man-in-the-middle a ack.

The user accesses a website through the URL shown and logs in.
http://www.testapp.com/login.aspx
The URL begins with HTTP, so the login creden als are sent in clear text.
A man-in-the-middle a acker can use a tool such as Firesheep or Wireshark to sniff
the creden als and use them to log in to the website.
Some mes the login page is accessible only over HTTPS, but pages inside are
accessible over HTTP. In that case, an a acker could sniff the user’s session cookie
(SESSID) instead of the user’s creden als. The stolen SESSID can then be used to log
in to the user’s session.
The following scenario describes a man-in-the-middle a ack that can occur when data
Narra on: is transmi ed in plaintext, without transport layer security.
The user accesses a website through the URL shown and logs in.
No ce that the URL begins with HTTP, meaning that the login creden als are sent in
clear text.
A man-in-the-middle a acker can use a tool such as Firesheep or Wireshark to sniff
the creden als and use them to log in to the website.
Some mes the login page is accessible only over HTTPS, but pages inside are
accessible over HTTP. In that case, an a acker could sniff the user’s session cookie
instead of the user’s creden als. The stolen SESSID can then be used to log in to the
user’s session.
I C hi S S i
Insecure Cryptographic Storage: Scenarios
Let’s look at some sensi ve data exposure scenarios caused by lack of or poor cryptographic
storage.
Click each tab to view different scenarios of insecure cryptographic storage of data.
Unencrypted No cryptography is used when storing sensi ve informa on.

storage
The informa on is stored with no effort taken to protect it using
encryp on or integrity verifica on techniques.
Custom Custom cryptographic algorithms or home-grown encryp on or

cryptography hashing algorithms are used to protect data.
It is very difficult to create cryptographic algorithms that are
secure from cryptanalysis. Custom versions of well-known
algorithms, such as Rijndael/AES, can contain minor errors that
could lead to a complete failure in the cryptographic processes
and data security.
Insecure Insecure implementa on of strong algorithms. For example:

implementa on
Using a secure implementa on of Rijndael/AES directly,
instead of through a strong cipher block mode such as CBC.
Padding Oracle a acks, where a strong cryptographic process
can be made insecure due to failures in other areas such as
excep on and error handling.
Using low-level cryptographic APIs directly, or using strong
algorithms in ways that make them weak.
Simply hashing passwords and storing the hashed value, which
can allow rainbow tables to be used against your hash.
Insecure Use of insecure and broken algorithms will leave your data
algorithms insecure.
These algorithms include outdated and weak algorithms such as
RC3/RC4, DES, MD5, and SHA1.
Insecure key Use of hard-coded keys and insecure key storage can make it
storage easier for a ackers to decrypt your data.
Storing any cryptographic keys directly in code can lead to:
Disclosure of the keys if source code is leaked.
Reverse engineering if the a acker obtains the binary.
Difficulty in cycling cryptographic keys.
Let’s look at some sensi ve data exposure scenarios caused by lack of or poor
Narra on: cryptographic storage.
One common scenario results from the absence of cryptography when storing
sensi ve informa on. In other words, sensi ve informa on is stored with no effort
taken to protect it using encryp on or integrity verifica on techniques.
Another common scenario involves use of custom cryptographic algorithms or home-
wri en implementa ons of public algorithms to protect data. Implemen ng custom
cryptography is never recommended. Crea ng secure custom cryptography is
extremely difficult. Implemen ng custom versions of well-known algorithms, such as
Rijndael/AES, is also not recommended; even a minor error can lead to a complete
failure in the cryptographic processes and data security.
Insecure cryptographic storage can also occur due to insecure use of strong
algorithms; for example, using a secure implementa on of Rijndael/AES directly,
instead of through a strong cipher block mode such as CBC. Padding Oracle a acks
also fall within this scenario, where a strong cryptographic process can be made
insecure due to failures in other areas such as excep on and error handling. Simply
hashing passwords and storing the hashed value can allow rainbow tables to be used
against your hash.
Using insecure and weak algorithms can also cause insecure cryptographic storage.
Don’t use broken or weak algorithms, such as RC3/RC4, DES, MD5, and SHA1.
Another insecure cryptographic storage scenario involves the use of hard-coded keys
and insecure key storage. Storing any cryptographic keys directly in code can lead to
their poten al disclosure if source code is leaked. It also allows for reverse engineering
if an a acker acquires the binary.
Click each tab to view different scenarios of insecure cryptographic storage of data.
How to Check for Sensi ve Data Exposure
To check for sensi ve data exposure in your Web applica on, look for the following
condi ons:
Sensi ve data transmi ed without SSL/TLS.
Sensi ve data stored in an unencrypted form.
Custom algorithms used to protect data at rest or provide integrity verifica on.
Even in-house implementa ons of known algorithms such as AES can be
problema c.
Direct use of low-level cryptographic APIs. For example, directly using the
encrypt method from an AES class without a strong cipher mode like CBC can lead
to severe cryptographic weaknesses.
Use of outdated or known insecure algorithms, such as RC3, RC4, DES, MD5, and
SHA1.
Storage of cryptographic keys or other constants in code or in other insecure
loca ons.
To check for sensi ve data exposure in your applica on, look for the condi ons listed
Narra on: on-screen.
Look for sensi ve data that is transmi ed or stored unencrypted, custom algorithms
or in-house implementa ons of known algorithms, use of low-level cryptographic APIs
directly, use of outdated or known insecure algorithms, and insecure storage of
cryptographic keys.
H P A i S i D E
How to Protect Against Sensi ve Data Exposure
To protect against sensi ve data exposure, take the

following steps:
Use SSL/TLS for all sensi ve communica ons.
Configure SSL to use strong cipher suites. Use valid
cer ficates.
During code review, ensure that sensi ve data is
properly encrypted and keys are properly stored.
Do not use any customized or in-house
cryptography. Use well known, peer-reviewed APIs
such as those found in many popular programming
frameworks.
Use high-level cryptographic APIs that properly
use cryptographic algorithms. Do not use low-level
APIs directly.
Do not use outdated or insecure algorithms. Use
industry-approved strong algorithms such as AES
with a 256 bit key size, the SHA2 family of hashing
algorithms (SHA256, SHA512), and RSA for public
key opera ons using key sizes of 2048 bits or
greater.
Protect your Web applica on against sensi ve data exposure by taking the following
Narra on: steps:
Use SSL/TLS for all sensi ve communica ons, configuring SSL to use strong cipher
suites, and using valid cer ficates.
Perform code review to ensure that proper steps are taken to cryptographically secure
sensi ve data. (Note that it is very difficult for automated tools to iden fy this issue.)
Ensure that custom or in-house cryptography is not used. You should not implement
your version of well-known cryptographic algorithms. Instead, use well known, peer-
reviewed APIs such as those found in many popular programming frameworks.
Always ensure that high-level cryptographic APIs that properly use cryptographic
algorithms are used. You should not use low-level APIs directly.
Finally, ensure that outdated or insecure algorithms are not used. You should use
industry-approved strong algorithms such as AES with a 256 bit key size, the SHA2
family of hashing algorithms (SHA256 and SHA512), and RSA for public key opera ons
using key sizes of 2048 bits or greater.
NOTE: For more informa on, see the TEAM Mentor ar cles Missing Encryp on of Sensi ve Data
and Use Strong Cryptographic Algorithms.

Missing func on level access

control o en manifests as failure
to restrict URL access.
Many Web applica ons validate
URL access rights before rendering
protected links and bu ons.
However, if applica ons don’t
perform similar access control
checks each me these pages are
accessed, a ackers can forge URLs
to access hidden pages. A failure
to restrict URL access occurs when
Web applica ons fail to perform
access control checks each me
protected pages are accessed.
Major threats related to missing
func on level access control
include:
Anonymous users gaining
access to private content.
Unauthorized users performing
opera ons on assets owned by
other users.
The next OWASP Top 10 vulnerability is missing func on level access control, which
Narra on: o en manifests as failure to restrict URL access.
Many Web applica ons validate URL access rights before rendering protected links
and bu ons. However, if applica ons don’t perform access control checks each me
these pages are accessed, a ackers can forge URLs to access hidden pages. A failure
to restrict URL access occurs when Web applica ons fail to perform access control
checks each me protected pages are accessed.
Missing func on level access control can allow unauthorized users to gain access to
private content and to perform opera ons on assets owned by other users.
Mi i F L lA C l S i
Missing Func on Level Access Control: Scenarios
Let’s look at a few scenarios of missing func on level access control.
Click each tab to view scenarios of missing func on level access control.
Scenario You try to protect private content that exists on a given URL by not
#1 exposing the URL to the public.
In this scenario, there may be an administra ve URL that performs
privileged ac ons when it is accessed and the URL is only linked from
within an administra ve console. However, there is no protec on in place
to stop other users from accessing and exercising the func onality of the
administra ve URL if they can find it.
Scenario You use a mul -user photo management applica on.

#2
When logged in, you may view your own photos. However, if you know
the URL to another user's photos, you would be able to view them if no
addi onal steps were required to verify that you had access to those
photos.
Let’s look at two examples that show how missing func on level access control
Narra on: vulnerabili es can occur.
This vulnerability can occur when you try to protect private content that’s located at a
URL that isn’t exposed to the public. In this scenario, there may be an administra ve
URL that performs privileged ac ons when it is accessed, and the URL is only linked
from within an administra ve console. However, there is no protec on in place to stop
other users from accessing and exercising the func onality of the administra ve URL.
This vulnerability can also occur in a mul -user photo management applica on. When
logged in, you can view your own photos. However, if you know the URL to another
user's photos, you would be able to view them if no addi onal steps were required to
verify that you had access to those photos.
Click each tab to review these scenarios of missing func on level access control.
How to Check For Missing Func on Level Access Control
To check your applica on for missing func on level access control vulnerabili es,
Narra on: iden fy sensi ve ac ons performed by the applica on and check if an unauthorized
user or a user of lower privileged role can perform them.
Check if the UI shows links to unauthorized func onality for any user.
Confirm that func on level authoriza on checks are performed on both the client and
server side.
Perform tests with user accounts that have different privilege levels. For example,
check if a user can directly invoke a func on accessible only to administrators.
The sample code shown here is executed when a user a empts to view his or her own
profile. The userId is passed as a GET parameter query string and retrieved by the
applica on. The applica on then determines if the user is authen cated in the
sessionID_valid() func on. If it is, it queries the database for the profile of the userID
passed to it by the user, retrieves the user’s profile, and displays it to the user.
Note that there was no authoriza on checking done at all. The profile ID of *any* user
was retrieved - all the user had to do was authen cate to the applica on and send
over a different user ID.
H P A i Mi i F L lA C l
How to Protect Against Missing Func on Level Access Control
To protect applica on content

whose access must be limited to
certain users or classes of users,
use role-based authoriza on. This
will help ensure that users have
access only to authorized
resources.
Note that use of obscure naming
schemes or randomized URLs is
not sufficient to protect URLs from
unauthorized access.
To protect applica on content whose access must be limited to certain users or classes
Narra on: of users, use role-based authoriza on. This will help ensure that users have access
only to authorized resources.
Note that use of obscure naming schemes or randomized URLs is not sufficient to
protect URLs from unauthorized access.
NOTE: For more informa on, see the TEAM Mentor ar cle Use Role-based Authoriza on.

Now let’s move on to the cross-site request forgery (CSRF) vulnerability.

Narra on:
A CSRF a ack causes a logged-in user’s browser to perform ac ons on behalf of that
user without their knowledge or authoriza on. A ackers accomplish this by causing
the vic m’s browser to send a malicious HTTP request along with valida on data such
as a session cookie to bypass authen ca on checks.
Any ac on performed by a user that does not require a mandatory token passed as a
parameter is vulnerable to CSRF.
A CSRF a ack happens as follows: First, a user logs on to a legi mate Web server. The
Web server then authen cates the user and provides a session ID stored in a cookie to
the user.
Then the user is tricked into opening a malicious website, from which the user’s
browser automa cally retrieves and executes HTML code that launches a URL poin ng
to the legi mate server. This URL is the CSRF exploit and is usually designed to perform
some kind of privileged ac on on behalf of the logged in user by taking advantage of
the creden als stored by the browser.
With CSRF, a user can perform sensi ve opera ons unknowingly. Examples include
performing a fund transfer, dele ng a user profile, adding a new administra ve user
to the system, upgrading a user’s role from a normal user to that of an administrator,
and upda ng or dele ng sensi ve data specific to the applica on’s business.
How to Check for Cross-Site Request Forgery
To check your Web applica on for CSRF vulnerabili es, you should validate that each
Narra on: link and form contains an unpredictable token for each request or user. Without this
unpredictable token, a ackers can forge malicious requests.
Next, you should verify that the token cannot be changed and is validated on each
request. Focus on the links and forms that invoke state-changing func ons; those are
the most important CSRF targets.
You should also ensure that session cookies, source IP addresses, and other
informa on automa cally sent by the browser are not used to protect against CSRF
vulnerabili es, because this informa on can be included in forged requests.
Finally, you should ensure that the token is regenerated on every request, or at least
on every valid user session, and mapped to a specific user.
In the sample code shown, a form is submi ed. There are a number of user-controlled
parameters, including tle, ac on, and a hidden form field called wpTextbox1. All of
these are submi ed to the applica on each me the form is submi ed.
The en re form is also embedded inside an IFRAME. The IFRAME submits the form
each me the page loads as shown in the line document.wikiedit.submit().
So, if an a acker can hardcode malicious values in the wikiedit form field, those
entries are posted each me someone visits the page.
No ce that no random token is submi ed along with the form. This means that the
applica on does not defend against CSRF.
NOTE: Code example is sourced from:

h ps://www.mediawiki.org/wiki/Secure_coding_and_code_review_for_MediaWiki/Tutorial#CSRF
H P A i C Si R F
How to Protect Against Cross-Site Request Forgery
To protect your Web applica on against CSRF vulnerabili es:

Generate and validate an unpredictable token in the
body or URL of each HTTP request.
Minimize exposure of the tokens.
Consider using a framework that automa cally includes
unpredictable tokens. Examples of such frameworks include:
– OWASP CSRFGuard -
h p://www.owasp.org/index.php/CSRFGuard
– OWASP ESAPI - h p://www.owasp.org/index.php/ESAPI
Now, let’s look at how you can protect a Web applica on against CSRF vulnerabili es.
Narra on:
To prevent a CSRF a ack, generate and validate an unpredictable token in the body or
URL of each HTTP request.
Minimize the exposure of the token. Tokens should be unique per user session or per
request. Ideally, include the unique token in a hidden field. This causes the value to be
sent in the body of the HTTP request. Although you can include this unique token in
the URL or a URL parameter, the URL could be exposed to a malicious user, which can
compromise the secret token.
Finally, consider using a framework that automa cally includes unpredictable tokens.
OWASP’s CSRFGuard can be used to automa cally include such tokens in your Java EE,
.NET, or PHP applica on. OWASP’s ESAPI includes token generators and validators that
developers can use to protect their transac ons.

Exploi ng known flaws in components is par cularly a rac ve to a ackers because:
A ackers generally learn about flaws at the same me as everyone else, giving them a
window of a ack before systems are updated or patched. Some sites are never patched.
Exploit code is o en widely available shortly a er a flaw is made public.
With flaws in commonly used components, a ackers can easily automate massive a acks
and even compile lists of vulnerable sites through search engines.
Click each tab to learn about the major threats, some examples of vulnerabili es, and how
to check for such vulnerabili es.
Major Known vulnerabili es can be exploited to circumvent exis ng security

Threats controls and give a ackers access to the server.
Example The Heartbleed bug is a very serious vulnerability in the popular OpenSSL
cryptographic so ware library. It allows a ackers to steal informa on that
should normally be protected by SSL/TLS encryp on.
For detailed informa on on the Heartbleed bug, see the Heartbleed site at
h p://heartbleed.com/.
How to To check if an applica on is using components with known vulnerabili es,

Check you need to:
1. Iden fy all so ware components used by the applica on and determine
any security advisories for
the version of the so ware used by checking the Common Vulnerabili es
and Exposures and
Na onal Vulnerabili es Database website.
2. Confirm that all your so ware is up to date. This includes the OS,
Web/App Server, DBMS,
applica ons, and all code libraries.
Exploi ng known flaws in components is par cularly a rac ve to a ackers because

Narra on: they generally learn about flaws at the same me as everyone else, giving them a
window of a ack before systems are updated or patched. Some sites will never get
patched. Also, exploit code is o en widely available shortly a er a flaw is made public.
With flaws in commonly used components, a ackers can easily automate massive
a acks and even compile lists of vulnerable sites through search engines.
Click each tab to learn about the major threats, some examples of vulnerabili es, and
how to check for such vulnerabili es.
R di i C i hK V l bili
Remedia on against Components with Known Vulnerabili es
To help remediate known vulnerabili es, install all vendor-

released patches that fix the vulnerability.
If the vendor doesn’t release a patch, consider installing
opera onal compensatory controls.
To help remediate known vulnerabili es, install all vendor released patches that fix the
Narra on: vulnerability.
If the vendor doesn’t release a patch, consider installing opera onal compensatory
controls.
NOTE: For more informa on, see the TEAM Mentor ar cle Using Components with Known
Vulnerabili es.

Web applica ons frequently redirect and forward users

to other pages and Web sites, and use untrusted data to
determine the des na on pages. Without proper
valida on, a ackers can redirect vic ms to phishing or
malware sites, or use forwards to access unauthorized
pages.
Unvalidated redirects and forwards occur when
parameters used for crea ng redirects and forwards are
not properly validated. In this case, an a acker can:
Cra a redirect URL that sends a user to a malicious
page.
Execute code on the user's system.
Install malware on the user's computer without the
user's knowledge.
Web applica ons frequently redirect and forward users to other pages and Web sites,
Narra on: and use untrusted data to determine the des na on pages. Without proper
valida on, a ackers can redirect vic ms to phishing or malware sites, or use forwards
to access unauthorized pages.
Unvalidated redirects and forwards occur when parameters used for crea ng redirects
and forwards are not properly validated. Unvalidated redirects and forwards can be
used to force users to Web pages or sites that they did not intend to visit, and even to
execute malicious code or install malware without their knowledge.
How to Check for Unvalidated Redirects and Forwards
You can check for unvalidated redirects and forwards in your Web applica on as
Narra on: follows.
Confirm whether the applica on uses any user-supplied data, such as query string
parameters or cookies, to determine how to redirect the user. Next, confirm whether
the applica on validates user-supplied data that is used to create redirects and
forwards. Finally, determine if it is possible to redirect a user out of the applica on to
an a acker-controlled page by manipula ng the data used to create the redirect.
Consider the sample code shown. This code could be called when the applica on
wants to display content from another site to the user, while they are s ll browsing
the original applica on.
The user clicks a link, which results in a request to a URL. The inten on is to redirect
the user to the website internalapp1.testapp.com so that the user can view the
products on that web page.
However, a malicious user could change that link as shown, and send the modified link
to a user. Because the link starts with www.testapp.com, the user clicks it, but is
redirected to the a acker’s evil website, per the line of code response.sendRedirect
(url).
H P A i U lid d R di dF d
How to Protect Against Unvalidated Redirects and Forwards
If you must use redirects or forwards in your Web

applica on, be very careful about how they are created.
Use the following techniques to mi gate unvalidated
redirects and forwards:
1. Validate input used to calculate the des na ons of
redirects and forwards.
Use whitelist valida on to ensure that only authorized
des na ons
may be used.
2. Use an internal lookup table to redirect users to a
specific resource,
rather than sending them directly to a resource specified
in
an ini al request or URL.
If you use redirects or forwards in your Web applica on, be very careful about how
Narra on: you do so.
To protect your Web applica on against unvalidated redirects and forwards, ensure
that any input used to build a redirect or forward conforms to strict checks. If user
input is used to create any redirects or forwards, validate it to ensure that it does not
send a user to a malicious loca on or execute malicious code in the user’s browser.
Also, use an internal lookup table to redirect users to a specific resource, instead of
sending them directly to a resource specified in an ini al request or URL.
NOTE: For more informa on, please see the TEAM Mentor ar cle Open Redirect.
Module Summary
A6: Sensi ve Sensi ve data exposure occurs when Web applica ons do not protect
Data Exposure sensi ve data, such as credit cards, social security numbers, and
authen ca on creden als, with appropriate encryp on or hashing.
A ackers can steal or modify weakly protected data to conduct iden ty
the , credit card fraud, or other crimes.
To prevent sensi ve data exposure, use SSL/TLS for communica ons,
configure SSL/TLS to use strong cipher suites, use valid cer ficates, and
properly implement secure cryptographic storage.
A7: Missing Missing func on level access control occurs when applica ons do not
Func on Level validate URL access rights before rendering protected links and bu ons. If
Access applica ons don’t perform access control checks each me these pages
Control are accessed, a ackers can forge URLs to access hidden pages.
With missing func on level access control, unauthorized users can gain
access to private content, and can perform opera ons on assets owned by
other users.
Use role-based access control to ensure that users have access only to
those resources for which they are authorized.
A8 : Cross-site A cross-site request forgery a ack forces the browser of a logged-on vic m
Request to send a forged HTTP request, including the vic m’s session cookie and
Forgery any other automa cally included authen ca on informa on, to a
vulnerable Web applica on. The vic m ends up unknowingly performing
ac ons on behalf of the a acker.
You can prevent CSRF a acks by using unpredictable tokens in the body of
each HTTP request and minimizing the exposure of the token.
A9: Using Exploi ng known flaws in components is par cularly a rac ve to a ackers
Components because they generally learn about flaws at the same me as everyone
with Known else, giving them a window of a ack before systems are updated or
Vulnerabili es patched. Some sites are never patched. Exploit code is o en widely
available shortly a er a flaw is made public.
To avoid using components with known vulnerabili es, install all vendor-
released patches that fix the vulnerability. If the vendor doesn’t release a
patch, consider pu ng opera onal compensatory controls in place.
A10: Unvalidated redirects and forwards occur when Web applica ons
Unvalidated frequently redirect and forward users to other pages and Web sites, and
Redirects and use untrusted data to determine the des na on pages. Unvalidated
Forwards redirects and forwards can allow a ackers to redirect vic ms to phishing
or malware sites, or use forwards to access unauthorized pages.
You can protect your Web applica on by using lookup tables to ensure that
users can only be redirected to safe and authorized des na ons.
TEAM Mentor eKnowledge
Provides faster and be er remedia on guidance within the developer’s environment

TEAM Mentor is an interac ve Applica on Security eKnowledge base with thousands of ar cles on how
to prevent vulnerabili es during applica on development. Use TEAM Mentor to find guidance for
implemen ng the applica on security controls that are relevant to your par cular applica on in your
development language. With op onal plugins to the most popular Sta c and Dynamic code analysis
tools, TEAM Mentor provides users with quick and easy access to comprehensive security guidance that
is accurate and relevant to specific code security ques ons. Integra ng security scanning and guidance
into a development workflow ul mately results in quicker produc on of more secure and stable
applica ons.
Narra on:
Thank You
Thank you. This concludes the How to Test for the OWASP Top 10 course.
Narra on: Thank you. This concludes the How to Test for the OWASP Top 10 course.

How To Test For The OWASP Top 10

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

How To Test For The OWASP Top 10

Caricato da

Copyright:

Formati disponibili

10/3/2017 How to Test for the OWASP Top 10

How to Test for the OWASP Top 10

Course Overview and Objec ves

Module 1: Tes ng for the OWASP Top 10: Part 1

An injec on vulnerability is created in code

An injec on vulnerability is created in code whenever untrusted data is used as part of

LDAP In this example, accomplishing LDAP injec on is dependent on whether

Let’s look at how you can protect your applica on

A2: Broken Authen ca on and Session Management

The broken authen ca on and

Session ID The following example shows how a session ID is stored in a cookie.

User visits h p://sampletestapp.com/login.aspx

On successful login, the SESSID cookie has a value 23e435ef114d78ad23e435ef114d78ad.

You can iden fy broken authen ca on and session management vulnerabili es in

Follow these steps to help protect your Web applica on

A3: Cross-site Scrip ng (XSS)

Cross-site scrip ng (XSS), vulnerabili es occur when an applica on dynamically

Defacement and Phishing with XSS Vulnerabili es

An a acker can leverage a cross-site scrip ng vulnerability to modify the appearance

Follow these steps to check for cross-site scrip ng:

Input Sani zed?

Example User input is included as part of the following error message:

Solu on Encode the user input into an HTML-safe encoded string to

A4: Insecure Direct Object References

An insecure direct object reference occurs when a developer

An insecure direct object reference occurs when a developer exposes a reference to an

To check if an applica on is vulnerable to insecure direct object references, follow

To test for insecure direct object references:

To protect against insecure direct object references

A5: Security Misconﬁgura on

How to Check for Security Misconﬁgura on

To check for security misconﬁgura on, ask

To protect your Web applica on against

To protect your Web applica on against security misconﬁgura on vulnerabili es,

A1: Injec on Injec on vulnerabili es occur when untrusted data is sent to an

A2: Broken Broken authen ca on and session management vulnerabili es occur

Module 2 - Tes ng for the OWASP Top 10: Part 2

A6: Sensi ve Data Exposure

Sensi ve data exposure occurs when Web

Common condi ons that can lead to exposure of

The following scenario describes a man-in-the-middle a ack.

Unencrypted No cryptography is used when storing sensi ve informa on.

Custom Custom cryptographic algorithms or home-grown encryp on or

Insecure Insecure implementa on of strong algorithms. For example:

How to Check for Sensi ve Data Exposure

To protect against sensi ve data exposure, take the

A7: Missing Func on Level Access Control

Missing func on level access

Scenario You use a mul -user photo management applica on.

How to Check For Missing Func on Level Access Control

To protect applica on content

A8: Cross-Site Request Forgery (CSRF)

Now let’s move on to the cross-site request forgery (CSRF) vulnerability.

How to Check for Cross-Site Request Forgery

NOTE: Code example is sourced from:

To protect your Web applica on against CSRF vulnerabili es:

A9: Using Components with Known Vulnerabili es

Major Known vulnerabili es can be exploited to circumvent exis ng security

How to To check if an applica on is using components with known vulnerabili es,

Exploi ng known ﬂaws in components is par cularly a rac ve to a ackers because

To help remediate known vulnerabili es, install all vendor-

A10: Unvalidated Redirects and Forwards

Web applica ons frequently redirect and forward users