OWASP Top 10 - Threats and Mitigations

Print
OWASP Top 10 - Threats and Mitigations

Table of Contents:
Course Overview and Objectives
Module 1: OWASP Top 10 Threats: Part 1

Module Overview and Objectives
OWASP 2010 and 2013
Threat 1: Injection
What is Risk?
Threat 1: Injection, the Web's Greatest Risk
How Injection Works
SQL Injection Overview
SQL Injection Overview (Contd.)
SQL Injection in Action
Advanced SQL Injection
SQL Injection Impact: Real-World Examples
Preventing SQL Injection Vulnerabilities
Additional Mitigation Techniques
Threat 2: Broken Authentication and Session Management

The Session Lifecycle
Knowledge Check
Broken Authentication and Session Management: Best Practices
Threat 3: Cross-Site Scripting (XSS)

Threat 3: Cross-site Scripting (XSS)
Stored vs. Reflected XSS
The Mechanics of XSS Attacks
Stored XSS Attack
Stored XSS Attack
The Impact of XSS
A Real-World Example of XSS
Preventing XSS: A Two-Step Approach
Preventing XSS: Escaping Web Application Output
Preventing XSS: The Importance of Character Sets
Threat 4: Insecure Direct Object References

Identifying Insecure Direct Object References
Exploiting a Direct Object Reference
Prevent Insecure Direct Object References
Threat 5: Security Misconfiguration

A Substantial Attack Surface
Ways to Misconfigure
Defending the Operating System
Defending the Web Server
Defending the Database
Defense in Depth: Other Strategies
Module Summary

Threat 6: Sensitive Data Exposure

Insecure Cryptographic Storage Overview
Common Cryptographic Storage Mistakes
Selecting Cryptographic Algorithms
Generating Random Numbers
Hashing With Salt Overview
Weakness of Unsalted Hashes
How Salted Hashes Work
Key Derivation Functions
Key Management: Best Practices
Insufficient Transport Layer Protection Overview
Attacks on SSL and TLS
Summary of Attacks on SSL and TLS

Selecting Cipher Suites
Prioritizing Cipher Suites
Securely Implementing TLS
Best Practices for Handling SSL/TLS Certificates
Threat 7: Missing Function Level Access Control

Failure to Restrict URL Access Illustrated - Path Traversal Vulnerabilities
Authorization Strategies
File and Directory Enumeration
Threat 8: Cross-Site Request Forgery (CSRF)

Preventing CSRF
Threat 9: Using Components with Known Vulnerabilities

Auditing External Components
Threat 10: Unvalidated Redirects and Forwards

Finding Vulnerable Components
Protecting Redirects
OWASP 2007 Top Ten Vs. OWASP 2010 Top 10

Past Top Risks: OWASP 2007 Top Ten
Module Summary
Locating Additional Resources
TEAM Mentor eKnowledge
Course Overview and Objectives

The Open Web Application Security Project, or OWASP, is an open-source,
non-profit initiative dedicated to improving the security of web
applications.OWASP develops standards and provides guidance on
development, testing, and tools. OWASPs mission is to make software
security visible, so that individuals and organizations worldwide can make
informed decisions about true software security risks. More information
about OWASP can be found at www.owasp.org.
The OWASP Top 10 list is an educational tool that describes the greatest
threats that web application developers face. Securing a web application is
an enormous task, and the OWASP Top 10 list helps you prioritize your
efforts by addressing those flaws that pose the most significant security
risks.
This course describes the top 10 threats that web application developers
face. It explains how to identify and eliminate common security flaws in
your own web applications and mitigate exposure to attack.
Course Objectives:
After completing this course, you will be able to:
Identify the most significant and prevalent security flaws that impact web
applications.
Explain mitigation techniques to remediate common security flaws in your
web application.
Narration: Hi there, Im Michelle, and I will guide you as we look at the most significant security flaws that
impact web applications. As this course progresses, we will look at the various mitigation techniques
that you can use to remediate common security flaws.
The Open Web Application Security Project, or OWASP, is an open-source, non-profit initiative
dedicated to improving the security of web applications. OWASP develops standards and provides
guidance on development, testing, and tools. OWASPs mission is to make software security visible,
so that individuals and organizations worldwide can make informed decisions about true software
security risks. More information about OWASP can be found at www.owasp.org.
The OWASP Top 10 list is an educational tool that describes the greatest threats that web
application developers face. Securing a web application is an enormous task, and the OWASP Top 10
list helps you prioritize your efforts by addressing those flaws that pose the most significant security
risks.
This course describes the top 10 threats that web application developers face. It explains how to
identify and eliminate common security flaws in your own web applications and mitigate exposure
to attack.
After completing this course, you will be able to identify the most significant and prevalent security
flaws that affect web applications. You will also be able to describe mitigation techniques to
remediate common security flaws in your web application.

This module provides an overview of the differences between the
OWASP Top 10 lists of 2010 and 2013. It then covers the first five
threats in the OWASP Top 10 list in detail, which include:
Threat 1: Injection
Module Objectives:
After completing this module, you will be able to:
Understand the methodology used to determine risk.

Describe the first five threats in the OWASP Top 10 list and their
mitigation techniques.
Narration: This module provides an overview of the differences between the OWASP Top 10 lists of 2010
and 2013. It then covers the first five threats in the OWASP Top 10 list in detail, which
include:
Threat 1: Injection
Threat 3: Cross-Site Scripting
After completing this module, you will understand the methodology used to determine risk.
You will also be able to describe the first five threats in the OWASP Top 10 list and their
OWASP 2010 and 2013

The following table provides a summary of the differences between OWASP 2010 and OWASP 2013 vulnerabilities:
Narration: The table on the screen shows a summary of the differences between the OWASP 2010 and
OWASP 2013 list of top ten vulnerabilities. New 2013 items resulting from merging or
renaming 2010 items are indicated accordingly in the item titles.
Threat 1: Injection
What is Risk?
Narration: Before we discuss each type of threat, let's first make sure that we understand the
methodology used to determine risk.
In OWASP, risk is the potential for a particular security flaw or attack to lead to a
negative impact on a business or organization.
Many different attackers, attack vectors, security weaknesses, and security controls
can affect a web application. In the right combination, these components could
provide paths that lead directly to threats to your technical or business operations.
To determine risk, OWASP considers the prevalence of the flaw, the number of agents
(attackers) able to find and exploit this flaw, and the likeliness that this flaw will have
a significant impact on technical or business operations.
Of course, for any particular organization, the number of attackers, the security
controls in place, and the actual impact on operations will vary. So, it is important to
interpret each of the top 10 threats individually for your situation.
Threat 1: Injection, the Web's Greatest Risk
Narration: Now that weve taken a quick look at the methodology used to determine threats,
let's examine each of the threats in detail.
The first threat is caused by an injection. But what is an injection attack and what
causes it?
Injection attacks are rated by OWASP as the greatest threat to web applications. By
crafting special input, an attacker can potentially manipulate server operations,
targeting the most critical components of the web application.
Injection attacks occur when a user embeds instructions in such a way that an
interpreter treats them as commands rather than data.
Many web applications dynamically build and send commands to external interpreters
such as databases, XML parsers, LDAP servers, or command shells. If users can trick
the web application into sending input data as actual commands, they can potentially
cause the interpreter to execute any commands they want.
Now, why are injection attacks especially considered high risk?
They require little effort to learn, discover, and execute, making them available to
more attackers.
Many applications are vulnerable because developers often overlook flaws or fail to
properly defend against these attacks.
In addition, injection attacks expose the most sensitive parts of a web application,
such as the database or the underlying operating system.
How Injection Works
Narration: The following example will help you understand how injection works.
Injection works by manipulating user input to exploit a web application.
If the web application does not filter user input properly, a user could inject
commands into the expected input.
Consider a web server that sends email by running a mailer executable through a shell
or command interpreter. The application may ask the user to enter an email address,
which is added as a parameter to a mailer command. If the web application does not
filter user input properly, a user could inject commands into the expected input.
In this example, the web application appends the user input as shown, without
validating that the data contains only an email address.
Many shell interpreters allow you to use && to execute multiple commands on a
single line. In this case, the application sends the email and then outputs a directory
listing to a file named dir.txt.
SQL Injection Overview

SQL injection is by far the most common form of injection attack.
Narration: We have seen what an injection attack is and how it works; now, let's look at its most
common formthe SQL injection attack.
Here are some real-world examples of SQL injection attacks.
If you would like to learn more about these attacks, click the relevant image.
SQL Injection Overview (Contd.)
Narration: SQL injection manipulates web application input to change the behavior of a query
sent to the database.
SQL injection could allow an attacker to bypass security restrictions, access sensitive
data, delete or modify data, or even execute stored procedures. Although some SQL
injection techniques are very elaborate, even a beginner can execute basic attacks.
What makes SQL injection an even greater threat is the development of tools to
automate more advanced techniques, along with the continual discovery of flaws in
widely used web applications.
This jeopardizes the security of thousands of websites.
With SQL injection, simply failing to validate a single input could allow an attacker to
bypass all other efforts you have made to firewall servers, harden operating systems,
and limit user permissions.
SQL Injection in Action
Narration: This example shows how SQL injection works.

An attacker can launch an SQL injection attack simply by modifying a URL parameter
to change the logic of an SQL statement.
In the example on the screen, an application shows all orders for a particular
customer. One way an application can do this is to pass the customers ID on the URL.
The pseudo code to perform the orders lookup might look like the code shown.
When the user browses to the specified URL, the web application displays a list of all
orders for that user.
An application that dynamically creates SQL queries from unfiltered input is vulnerable
to SQL injection. In our example, consider what would happen if the user entered the
additional input to the URL as shown.
Notice how the user can modify the logic of the SQL statement simply by changing the
customer-id parameter on the URL. This exploit is by no means limited to URL
parameters; an attacker might be able to inject SQL through form fields, cookie
values, session variables, and even browser headers.
Advanced SQL Injection
Narration: Although SQL injection in the previous example was very simple, SQL injection
techniques can be quite complex and powerful. These include unions, errors, stored
procedures, and timing.
So, what happens when the code examples shown are executed? Move your mouse
over each line of code to find out!
SQL Injection Impact: Real-World Examples

Drupal
Drupal is an
open source
content
management
platform. In
October 2014 it
confirmed a
vulnerability in
the Drupal
version 7's
database
abstraction API
that allowed an
attacker to
send specially
crafted
requests
resulting in
arbitrary SQL
execution.
Depending on
the content of
the requests
this can lead to
privilege
escalation,
arbitrary PHP
execution, or
other attacks.
WordPress
A flaw in the
WordPress
plugin WPSlimstat
discovered in
March of 2015
allowed
hackers to
perform an SQL
Injection attack
against the
website by
breaking the
plugins weak
secret key,
potentially
allowing
attackers to
take over an
entire site. In
response,
SlimStat
tightened its
SQL queries
and
strengthened
its encryption
key.
Worldview
The UK's
Information
Commissioner's
Office (ICO)
fined
Worldview Ltd
for "a
vulnerability in
the code that
retrieved rate
information on
the web page.
This meant that
user input was
not properly
validated so
that an
attacker was
able to inject
SQL queries in
order to
perform a blind
SQL injection
attack.
Narration: To better understand the impact of SQL injection attacks, let's consider some realworld attacks that occurred on three websites: Drupal, WordPress, and Worldview.
Drupal is an open source content management platform. In October 2014, it
confirmed a vulnerability in the Drupal version 7's database abstraction API that
allowed an attacker to send specially crafted requests resulting in arbitrary SQL
execution. Depending on the content of the requests this can lead to privilege
escalation, arbitrary PHP execution, or other attacks.
A flaw in the WordPress plugin WP-Slimstat discovered in March of 2015 allowed
hackers to perform an SQL Injection attack against the website by breaking the
plugins weak secret key, potentially allowing attackers to take over an entire site.
In response, SlimStat tightened its SQL queries and strengthened its encryption key.
The UK's Information Commissioner's Office (ICO) fined Worldview Ltd for "a
vulnerability in the code that retrieved rate information on the web page. This meant
that user input was not properly validated so that an attacker was able to inject SQL
queries in order to perform a blind SQL injection attack."
Click each example to learn more.
Preventing SQL Injection Vulnerabilities

Prepared
Statements
With prepared statements, the database performs the following

tasks on the query before receiving user input:
Parsing
Compiling
Optimizing
Parameters, or bind variables, are sent to the database
separately, resulting in a clear distinction.
Parameterized
Stored
Procedures
Although parameterized stored procedures are typically safe,

you still must consider the following:
Avoid dynamically generating SQL statements with user input
from within the stored procedure. If necessary, you must take
appropriate measures to filter and sanitize user input.
Avoid or take extra precautions when using system stored
procedures that perform sensitive operations such as
sp_execute, execute, or exec.
Carefully consider user permissions to take advantage of the
stored procedures and mitigate potential exposure.
Note that if you build dynamic SQL from the parameters passed
to stored procedures, you again expose the database to SQL
injection attacks. When building dynamic SQL inside a stored
procedure, you must validate all parameter values and treat
them as if they were untrusted.
Input Validation
Validation of every user input is an important defense against

injection (and against most of the OWASP Top 10
vulnerabilities). Input validation minimizes risk and is easy to
implement on existing applications.
Take extra care with input validation--it is easy to neglect it or to
overlook some inputs. Also, keep in mind that even when it is
consistently implemented, input validation does not completely
eliminate injection vulnerabilities.
Input validation includes whitelist validation, blacklist validation,
and escaping special characters.
In whitelist validation, you specify a set of data types, patterns,
lengths, and characters to allow. All data that does not match
this approved set is blocked. Always use some form of whitelist
validation on user input. For example, if you expect numeric
input, always check that the user-supplied data is in fact a
number, as illustrated by the following pseudo code:
id=GET(customer-id)
If not numeric(id) then
raise error
end if
Blacklist validation, although not nearly as effective, lets you
specify a set of bad data or data patterns to block and take
appropriate action against any input that matches this set.
Escaping special characters. When creating code for a particular
technology, determine which of the characters are "special."
After you have identified these characters, you need to prevent
them from appearing in input, or you need to properly escape
them.
Narration: You can prevent SQL injection vulnerabilities by using prepared statements,
parameterized stored procedures, and input validation. Let's look at each of these
techniques in detail.
The primary and most consistent defense against SQL injection is to use
parameterized queries in the form of prepared statements. These statements allow
you to pass user input as parameters instead of dynamically building SQL statements.
The OWASP website provides code libraries and samples in various languages for
parameterizing SQL queries.
Parameterized stored procedures are normally a good alternative to prepared
statements, if using them makes more sense for your particular environment.
Parameterized stored procedures are similar to parameterized queries except that the
SQL itself resides on the database server.
Validating every user input is crucial to defending against injection attacks (and
against most of the OWASP Top 10 vulnerabilities). Input validation minimizes risk and
is easy to implement on existing applications.
Input validation includes whitelist validation, blacklist validation, and escaping special
characters.
Click each technique to learn more.
Additional Mitigation Techniques

Here are some additional
mitigation techniques to
defend against injection
attacks.
1. Use blacklist validation
prudently to help detect
actual attacks and
complement other
security measures.
2. Implement proper
exception handling and
never
return raw error
messages to the web
browser.
3. Perform all web
queries with minimal
privileges
necessary for the
application.
4. Harden the underlying
operating systems and
applications on the web
and database servers.
5. Select only the fields
you need in a query and
avoid using SELECT * if
not necessary.
6. Use the LIMIT clause in
SQL statements that
return a fixed number of
results; if you
expect one result, use
LIMIT 1.
7. When executing
external programs or
dynamically evaluating
scripts, be extra
cautious to ensure that
user input cannot
modify the intent of
those operations.
8. Be consistent with the
character sets used
throughout your
application, preferably
using UTF-8. Specify
character sets explicitly
whenever possible and
never assume defaults.
9. Always normalize file
paths and check the
result to ensure the file is
within the bounds
of your application.
Narration: We have now covered some techniques to prevent injection attacks from occurring.
Here are some additional techniques to defend against injection attacks:
Although not effective as a primary defense, blacklist validation used prudently can
help detect actual attacks and can complement other security measures.
Implement proper exception handling and never return raw error messages to the
web browser.
Perform all web queries with minimal privileges necessary for the application.
Harden the underlying operating systems and applications on the web and database
servers.
Select only the fields you need in a query and avoid using SELECT * if not necessary.
Use the LIMIT clause in SQL statements that return a fixed number of results; if you
expect one result, use LIMIT 1.
When executing external programs or dynamically evaluating scripts, use extra

caution to ensure that user input cannot modify the intent of those operations.
Be consistent with the character sets used throughout your application, preferably
using UTF-8. Explicitly specify character sets whenever possible and never assume
defaults.
Always normalize file paths and check the result to ensure the file is within the bounds
of your application.
Threat 2: Broken Authentication and Session

Management
Narration: Let's look at the second threat: broken authentication and session management.
Broken authentication and session management vulnerabilities are those in which an
attacker exploits flaws to impersonate other users either through session hijacking,
session manipulation, or credential discovery.
These flaws are usually the result of poor session control and isolation, weak
password recovery and account management functions, and inadequately secured
transmission or storage of user credentials.
Examples of broken authentication and session management include forgotten
password functionality, relying on an IP address for a session, and having inadequate
timeouts for inactive sessions. Let's see an example of forgotten password
functionality to understand this threat better.
Many Web applications include functionality for forgotten passwords. Users submit
their usernames to the application, which then directs them to a password recovery
page. Recovery methods include providing answers to secret questions to obtain a
forgotten password, or submitting a user name or email address to receive temporary
password information that can be used to reset the password.
Attackers often exploit this functionality to identify valid user names for the
application. Developers often forget that if an attacker can retrieve a user name, the
puzzle is half solved. An attacker cannot do much by just knowing a password, but can
potentially achieve a lot by knowing the user name.
The Session Lifecycle

User session management is the process of authenticating, authorizing, and managing users from login until session
termination. Although the application initially authenticates a user based on username, password, and in some
cases, a second factor of authentication, all subsequent session authentication relies on a unique session identifier.
Because this single session identifieror tokenis equivalent to the users credentials for the duration of the
session, it is critical to take all precautions necessary to protect it from attack. The following diagram illustrates a
typical session lifecycle.
Narration: User session management is the process of authenticating, authorizing, and

managing users from login until session termination. Although the application initially
authenticates a user based on username, password, and in some cases a second
factor of authentication, all subsequent session authentication relies on a unique
session identifier.
Because this single session identifieror tokenis equivalent to the users credentials
for the duration of the session, it is critical to take all precautions necessary to protect
it from attack. The diagram illustrates a typical session lifecycle.
Knowledge Check
Here is a diagram depicting the steps in a typical session lifecycle.
Drag the numbered steps to the correct placeholder circles.
Narration: Here is a diagram depicting the steps in a typical session lifecycle.

Drag the numbered steps to the correct placeholder circles.
Broken Authentication and Session Management: Best Practices

User Logins
Password and
Password
Policies
Session Tokens
Cookie Security
Cryptography
Always use SSL-encrypted forms for user login.

Avoid pop-up windows that do not show the address bar and SSL
validation icon.
Validate form input.
Never use hidden form fields for storing authentication-related
information.
Consider countermeasures for handling brute-force attacks and
credential harvesting.
Consider supporting third-party authentication providers such as
Google or Facebook.
Use generic error messages.
Avoid using the remember me functionality with high-value
applications.
Provide users with a logout button to manually terminate a
session.
Implement strong yet usable and practical password complexity
requirements.
Ensure that all passwords have fixed but reasonable expiration
dates.
Always notify users of password changes via email or SMS, but
never send the actual passwords.
Always ask for the previous password when setting a new
password.
Expire all current sessions after changing passwords.
Do not automatically assign temporary passwords.
Provide two-factor authentication features for sensitive
applications. Hardware devices, software tokens, or SMS onetime-passwords greatly enhance account security.
Store session identifiers in a generic variable that does not allow
fingerprinting or profiling.
Ensure that the session ID is sufficiently long and is created using
strong random number generators.
The session ID should only contain a single session identifier and
never contain any other identifying information.
Always store session identifiers in cookies and never rely on
sending session IDs via URL parameters, hidden form fields, or
custom HTTP headers.
Generate new session identifiers after user login, immediately
after privilege escalation or role change, or after sensitive
operations such as password changes.
Use well-tested framework or platform session management
features instead of implementing your own.
Never accept user-provided session identifiers if the application
did not generate that ID for the user.
Never transmit session-related content over non-TLS
connections, including creative assets such as style sheets and
graphics.
Always set both absolute and relative time limits on session
identifiers to ensure proper session expiration.
Leverage the built-in platform whenever possible. Avoid creating
your own custom session management systems.
Only store session identifiers in session cookies. Never store
session-related values in persistent cookies.
Always set the Secure cookie attribute to ensure that the
application always transmits cookies over secure connections.
Always set the HttpOnly cookie attribute to ensure that scripts
cannot access cookies via the DOM document.cookie object.
Carefully plan Domain and Path cookie attributes to clearly
define the bounds of cookie use.
Always send user credentials and session tokens over secure
encrypted channels, even for private internal communications.
Although TLS content is encrypted, the URL itself is not, and it
should never reveal sensitive information.
Always use certificates signed by an organizational certificate
authority for private intranet applications and by a recognized
and trusted certificate authority for public applications. Never
use self-signed certificates, even for internal applications.
Do not mix secure and non-secure content in secure areas of the
application.
Be familiar with regulations and standards required for your
organization and industry.
Narration: User authentication and session management have a long history in information
technology. Account compromise is perhaps the oldest security threat we face.
Through years of developing new techniques and learning from past mistakes, the
industry has developed a long list of best practices.
Some rules are simple and seemingly obvious. However, due to the compounding
nature of security threats, it is important to understand and strictly follow even the
most basic of these rules.
To better understand how to make secure authentication and session management an

integral part of any web application, lets review best practices for user logins,
password and password policies, session tokens, cookie security, and cryptography.
Click each category to learn more.

Threat 3: Cross-site Scripting (XSS)
Narration: Let's now move on to the third type of threat, which is cross-site scripting.
So, what is cross-site scripting and why is it a threat?
Cross-site scripting is a form of injection attack.
Cross-site scripting can occur whenever the application accepts user input without
proper validation, and then uses the input to generate output, such as site content or
a response to a client, without proper escaping.
Cross-site scripting flaws in an application allow attackers to exploit other users.
Although cross-site scripting is a form of injection, it is unique in both scope and target
and warrants its own classification.
Despite its prevalence, the risks of cross-site scripting are often underestimated. So,
what are the risks?
An attacker can use cross-site scripting to:
Access and modify the structure, appearance, and behavior of browser content or
simply redirect the user to a site that contains malicious content.
Execute client-side scripts, exploiting the users trust of your web application.
Perform actions on your site on behalf of the client.
Access sensitive session and cookie information, and access private and sensitive client
information and even spy on all actions the client performs on your website.
Stored vs. Reflected XSS

Stored XSS
In a stored XSS attack, also known as a persistent attack, an attacker

sends malicious input that is stored in the applications database. The
malicious input is then displayed as a normal part of the sites
content.
When a user views or requests the stored content, the malicious code
is executed.
Reflected
XSS
In a reflected XSS attack, also known as a non-persistent attack, the

attacker gets the user to send malicious input to a particular URLfor
example, by sending the user email with a link to click.
By clicking the link, the user sends the malicious input to the web
application. The application then uses that input to generate a
response.
This is the most common form of XSS attack.
Additional
Categories
XSS has two additional categories based on where the injection

occurs: Traditional XSS vulnerabilities occur when the server itself
modifies the data, whereas DOM-based vulnerabilities occur when
modification occursusually via JavaScriptwithin the clients web
browser while rendering the page.
Narration: Cross-site scripting attacks usually fall into two categories: Stored cross-site scripting
and reflected cross-site scripting.
Cross-site scripting has two additional categories based on where the injection occurs:
traditional cross-site scripting and DOM-based cross-site scripting.
Click each category to learn more.
The Mechanics of XSS Attacks
Narration: So far, we have a basic understanding of cross-site scripting attacks and their types.
But how does a cross-site scripting attack work?
By understanding basic cross-site scripting attacks, you can also understand the most
sophisticated ones. Although these attacks may be very simple, the consequences can
be quite serious.
Cross-site scripting attacks can be applied in a wide variety of ways, but they all
exploit the basic concept that the user trusts your website. If attackers can inject
HTML and JavaScript, they can change the behavior of a page to accomplish their
objectives. Let's look at an example.
If attackers inject HTML and JavaScript, they can change the behavior of a page to
accomplish their objectives, as shown here.
Stored XSS Attack

An attacker can inject a stored XSS attack, as shown in this example.
Drag the icons to the correct placeholder circles to indicate the correct sequence followed
by an attacker.
Narration: An attacker can inject a stored cross-site scripting attack, as shown in this example.
Drag the icons to the correct placeholder circles to indicate the correct sequence
followed by an attacker.
Stored XSS Attack

The stored XSS attack can become much more serious, depending on the malicious code
injected by the attacker, as shown here. Drag the icons to the correct placeholder circles to
indicate the correct sequence.
Narration: The stored cross-site scripting attack can become much more serious, depending on
the malicious code injected by the attacker, as shown in this example. Drag the icons
to the correct placeholder circles to indicate the correct sequence followed by an
attacker.
The Impact of XSS
Narration: In the previous examples, you saw how an attacker can use cross-site scripting to gain
information about a sites administrator. Of course, attackers can employ cross-site
scripting to attack any site visitor as well.
Lets look at attempting the question shown to see if you can identify what impact
cross-site scripting vulnerabilities can have on your web application.
A Real-World Example of XSS
Narration: Let's now look at a real-world example of how cross-site scripting works.
In December 2012, the social media site Tumblr fell victim to a malicious cross-site
scripting worm that caused offensive posts to appear on numerous blogs. The
vulnerability simply required a logged-in Tumblr user to view one of these posts to
further spread the malicious content.
The vulnerability quickly spread to nearly 90,000 users and forced Tumblr to
temporarily suspend all posting capabilities to prevent the worm from spreading
further.
Preventing XSS: A Two-Step Approach

Input
Validation
Output
Sanitizing
Use whitelist validation to allow data that matches a set of

approved parameters, and block all other data.
Escape all untrusted data using the method most appropriate for
the type of output.
Explicitly define character encoding and output mime types.
Narration: We've learned about cross-site scripting attacks, how they work, and seen some realworld examples of such attacks. Now, how do you prevent them?
To prevent cross-site scripting attacks, use input validation and output sanitizing
(escaping). To do this correctly, you must understand the structure of your
applications input and output.
Preventing XSS: Escaping Web Application Output

Following is a list of recommendations
for securing common types of output
data.
HTML elements. Use HTML entity
encoding along with an HTML
sanitization library.
HTML attributes. Use more aggressive
HTML and validation, and avoid placing
untrusted data in unsafe attributes such
as style, link, and onclick.
URL parameters. Use URL encoding. URL
encoding replaces unsafe ASCII
characters with a "%" followed by two
hexadecimal digits. Here is an example
of URL encoding:
Input string: Sample input here is $270
Encoded output:
Sample%20Input%20Here%20is%20$270
SRC or HREF attributes. Use specific URL
validation and canonicalization as
appropriate for your application, use
whitelist URL validation if possible, and
limit protocols to http and https.
Style and CSS values. Place un-trusted
data in property values only. Use strict
whitelist validation on all data, and use
hex encoding to avoid breaking out of
context.
JavaScript variables. Limit untrusted
data to data values that would be
enclosed in strings, and ensure that all
JavaScript variables are quoted. Hexencode data to avoid breaking out of
context, and avoid backslash escaping.
Narration: So how does escaping Web application output help in preventing cross-site scripting?
Preventing cross-site scripting attacks involves more than simply encoding all output.
You must carefully consider the context and any sub-contexts of output data to
implement the appropriate prevention measures. Here is a list of recommendations
for common types of output data.
For HTML elements, use HTML entity encoding along with an HTML sanitization
library.
For HTML attributes, use more aggressive HTML and validation, and avoid placing
untrusted data in unsafe attributes such as style, link, and onclick.
Use URL encoding in URL parameters.
With URL links, SRC, or HREF attributes, use specific URL validation and
canonicalization as appropriate for your application, use whitelist URL validation if
possible, and limit protocols to http and https.
For style and CSS values, place un-trusted data in property values only. Use strict
whitelist validation on all data, and use hex encoding to avoid breaking out of context.
And, for JavaScript variables, limit untrusted data to data values that would be
enclosed in strings, and ensure that all JavaScript variables are quoted. Hex-encode
data to avoid breaking out of context, and avoid backslash escaping.
Preventing XSS: The Importance of Character Sets

To ensure consistent character sets
throughout your application, do the
following:
Explicitly specify a character set (such
as UTF-8) wherever possible, including
in databases, script interpreters, web
platforms, and on XML/XHTML
content, such as:
<?xml version="1.0"
encoding="UTF-8"?>
Specify a character set when using
encoding or other conversion functions
that allow you to indicate character
sets, such as with htmlspecialchars in
PHP.
Verify character sets as part of the
input validation process.
Narration: Let's now examine the importance of character sets in preventing cross-site scripting.
To complement input validation and output escaping, ensure that your application
uses a consistent character set. Many cross-site scripting evasion techniques take
advantage of character-set ambiguity. To ensure consistent character sets throughout
your application, you need to:
Explicitly specify a character set (such as UTF-8) wherever possible, including in
databases, script interpreters, web platforms, and on XML/XHTML content.
Specify a character set when using encoding or other conversion functions that allow
you to indicate character sets, such as with htmlspecialchars in PHP, and verify
character sets as part of the input validation process.

In a direct object reference, an
application directly refers to an object
such as a filename, user account, or
database record.
Even with extensive input validation,
this can potentially allow attackers to
predict or guess other objects that they
may not be authorized to access,
leading to exposure of sensitive system
and user information.
When designing a web application, it is
easy to mistakenly assume that users
cannot access content that they cannot
see.
Failure to control access to this content
is an (often unintentional) attempt at
security through obscurity.
The Insecure Direct Object References
threat reflects flaws in system design
where access to sensitive data or assets
is not fully protected, and data objects
are exposed by the application. This
exposure occurs when developers
assume that users always adhere to the
basic rules of the application.
Narration: The next threat we'll discuss is insecure direct object references. To understand this
threat better, let's make sure that we understand what a direct object reference is.
In a direct object reference, an application directly refers to an object such as a
filename, user account, or database record.
Even with extensive input validation, this can potentially allow attackers to predict or
guess other objects that they may not be authorized to access, leading to exposure of
sensitive system and user information.
When designing a web application, it is easy to mistakenly assume that users cannot
access content that they cannot see.
Failure to control access to this content is an (often unintentional) attempt at security
through obscurity.
The Insecure Direct Object References threat reflects flaws in system design where
access to sensitive data or assets is not fully protected, and data objects are exposed
by the application. This exposure occurs when developers assume that users always
adhere to the basic rules of the application.
Identifying Insecure Direct Object References
Narration: How can you identify an Insecure Direct Object References threat?
These threats are difficult to identify with automated tools. To exploit this
vulnerability, a hacker needs to identify the flawed interface and also predict the
pattern to identify an insecure object such as file or user name.
To protect against this threat, you instead need to perform a code review, followed by
a walkthrough of the website to help identify interfaces that provide access to
sensitive content. You can then verify that the object is not directly accessible based
on common information such as user name, email address, user ID, or predictable
object names, such as business reports that include the organization or client name.
Common implementation areas where these objects could be exposed include URLs
and links, hidden variables, drop-down list boxes, and JavaScript arrays.
Exploiting a Direct Object Reference
Narration: So how exactly is a direct object reference exploited?

It involves three steps:
First, identify a potentially exploitable direct object reference. Next, experiment with
how to exploit the flaw and bypass any input validation that might exist. Then, predict
or guess other object names to access.
The example here shows a customer download page that contains direct object
references to a filename and a customer ID.
What are your observations when you see this image?
Looking at this URL, there are two values that stand out: a reference to a file name,
and a reference to a customer ID.
Lets look at another example.
What can you conclude from this image?
As illustrated here, an attacker might try to guess another file name to see if the
application permits downloading other products. Although this may not work, it might
indicate that the customer ID does not have access to this file.
By guessing other customer IDs or simply trying all possible IDs, the attacker may
eventually discover the customer that *does* have access to the file.
So how do you address these problems?
The best way to eliminate this vulnerability is through indirect object access. Indirect
object access uses random, non-informative object identifiers that are valid only for
the current context (such as a user session). This normally requires maintaining a hash
table or a list applicable only to the current user session.
Prevent Insecure Direct Object References

Use an
Indirect
Reference
Map
You can use an indirect reference map to create an alternative ID or

name for server side objects or data to ensure that the exact ID or
name is not exposed to the end user. The object ID can be anything
from a file name, to an internal customer, to a user ID. An indirect
reference map maintains a non-sequential and random identifier
for a server-side resource. The end user can view only the alternate
ID and not the actual ID of the object. This mapping can be stored
temporarily in the server cache or in a permanent mapping table.
Consider a scenario in which your application allows a user to
download a confidential file. Instead of saving files with obvious
names, you should instead use a randomly generated identifier as
the file name and maintain a mapping table with a user-friendly file
name internally. In the client-side link, you display the user-friendly
file name, and when the user requests the resource, you use the
mapping table to obtain the actual (random) file name. This way,
the user retrieves the file without knowing the actual name under
which it is stored.
Verify User
Authorization
If you use an alternate or random object ID, you are just reducing
the chances that the user might be able to predict the resource
identifier. The chances of an attack are reduced but not completely
eliminated. If the attacker gets information about the alternative
object ID (maybe from the browser history information on a shared
computer), he can still send a resource request in a legitimate
manner and retrieve the required information. Therefore, it is
crucial to verify the users authorization to make sure that the user
is valid and can request the resource. You can address this scenario
with database-based validation more easily than you can with
application code.
Consider an example in which you retrieve critical report contents
from a database for a particular customer with the following query:
Example:
SELECT * FROM Monthly_Budget_Reports WHERE CustID="111"
If the attacker can manipulate the CustID field from the UI, he can
probably pass a different ID to access reports of other customers as
well. To mitigate this, you can easily add validation in SQL by
checking the user authorization as follows:
SELECT * FROM Monthly_Budget_Reports INNER JOIN
ReportAccessControlbyOrg On ReportAccessControlbyOrg.OrgId =
Monthly_Budget_Reports.OrgId WHERE CustID="111" AND
ReportAccessControlbyOrg.OrgId = loggedInUser_OrgId
However, the contents accessed could be stored outside of the
database, perhaps in a file system. In this scenario, you may also
need to ensure that other methods of file retrieval are also
protected, because the attacker may attempt access by direct HTTP
requests to objects or FTP.
Narration: How can insecure direct object references be prevented?

You can prevent insecure direct object references by reducing a user's ability to
determine object IDs and names. Avoid disclosing the actual IDs or names of objects
and verify user authorization every time sensitive objects, files, or contents are
accessed.
You can use an indirect reference map to create an alternative ID or name for server
side objects or data to ensure that the exact ID or name is not exposed to the end
user. The object ID can be anything from a file name, to an internal customer, to a
user ID. An indirect reference map maintains a non-sequential and random identifier
for a server-side resource. The end user can view only the alternate ID and not the
actual ID of the object. This mapping can be stored temporarily in the server cache or
in a permanent mapping table.
If you use an alternate or random object ID, you are just reducing the chances that the
user might be able to predict the resource identifier. The chances of an attack are
reduced but not completely eliminated. If the attacker gets information about the
alternative object ID (maybe from the browser history information on a shared
computer), he can still send a resource request in a legitimate manner and retrieve the
required information. Therefore, it is crucial to verify the users authorization to make
sure that the user is valid and can request the resource. You can address this scenario
with database-based validation more easily than you can with application code.

Although an applications
code is vital to its
security, the platform it
runs on is also very
important. The
misconfiguration of
security-related settings
within operating systems,
web services, and
databases contribute to
your applications attack
surface.
Narration: The fifth threat is the security misconfiguration threat.

Although an applications code is vital to its security, the platform it runs on is also
very important. Improperly secured operating systems, web server applications, and
databases all contribute to the overall attack surface. Most security misconfiguration
mistakes are common, and these common errors are the preferred attack vector and
the easiest to exploit.
On the next few screens, we will look at the different ways in which security is
misconfigured and how you can prevent these mistakes.
A Substantial Attack Surface
Narration: Web and application server platforms play a key role in the security of a web
application. Each application server adds to the overall attack surface, and some
application servers provide a number of auxiliary services for their associated web
applications, including data storage, directory services, mail, and messaging. The
attack surface resulting from all of these services can be quite large, requiring
significant effort to manage their configuration.
Lets understand this better with the help of an example.
Drag each attack surface to its appropriate circle.
Ways to Misconfigure
Narration: To understand how security misconfiguration occurs, consider the following scenario.
An application server is configured in such a manner that stack traces can be resent to
users. This setting leads to a risk of exposing underlying vulnerabilities.
Can you identify the security configuration error that occurred?
Defending the Operating System

Some key approaches to
hardening the operating
system (OS) include:
Take a minimalist
approach and only install
what is necessary for
your purpose.
Strictly limit user
accounts and disable or
rename default accounts.
Establish strong password
policies for the OS and all
installed applications.
Use a packet filter or
firewall to restrict access
and isolate the machine
on the network.
Keep the system up-todate with the latest
operating system, web
server, database, and
other software patches.
Set file and directory
permissions to the least
necessary to run the
required applications.
Review OS settings that
can improve system
security.
Ensure that proper
system auditing and log
file management is in
place.
Avoid installing software
development and
debugging tools on the
server.
Install anti-virus and
other security software
as appropriate.
Consider using a
hardening guide or tool
appropriate for your
operating system.
Ensure that the server is
physically secure.
Narration: Here are some key approaches to hardening the operating system (OS).
Take a minimalist approach and only install what is necessary for your purpose.
Strictly limit user accounts and disable or rename default accounts.
Establish strong password policies for the OS and all installed applications.
Use a packet filter or firewall to restrict access and isolate the machine on the
network.
Keep the system up-to-date with the latest operating system, web server, database,
and other software patches.
Set file and directory permissions to the least necessary to run the required
applications.
Review OS settings that can improve system security.
Ensure that proper system auditing and log file management is in place.
Avoid installing software development and debugging tools on the server.
Install anti-virus and other security software as appropriate.
Consider using a hardening guide or tool appropriate for your operating system.
Ensure that the server is physically secure.
Defending the Web Server

Key approaches to
improving the security of
web servers include:
Install only the modules
or services necessary for
your application.
Use appropriate file and
directory permissions to
strictly control access to
web content directories.
Disable directory
browsing.
Review web server
settings that can improve
platform security.
Remove default, demo,
backup, temporary, and
other directories not
appropriate for a
production server.
Remove, rename, or
restrict IP address access
to administrative
directories.
Disable or reconfigure
error reporting features
so that users never see
detailed error messages.
Disable or block HTTP
methods not needed for
your application.
Modify server headers to
not reveal server
platform and version.
Review script interpreter
and application
framework settings to
ensure that proper limits
and security settings are
in place.
Consider using a
hardening guide or tool
appropriate for your web
server and application
framework.
Ensure that the server is
physically secure.
Narration: Let's now look at how you can improve the security of web servers.
Install only the modules or services necessary for your application.
Use appropriate file and directory permissions to strictly control access to web content
directories.
Disable directory browsing.
Review web server settings that can improve platform security.
Remove default, demo, backup, temporary, and other directories not appropriate for a
production server.
Remove, rename, or restrict IP address access to administrative directories.
Disable or reconfigure error reporting features so that users never see detailed error
messages.
Disable or block HTTP methods not needed for your application.
Modify server headers to not reveal server platform and version.
Review script interpreter and application framework settings to ensure that proper
limits and security settings are in place.
Consider using a hardening guide or tool appropriate for your web server and
application framework.
Defending the Database

Key approaches to improving the
security of database servers
include:
Remove or disable unnecessary
database features or services.
Strictly limit user accounts and
disable or rename default
accounts.
Use a packet filter or firewall to
tightly restrict access to database
ports.
Remove any demo, testing,
training, and all other databases
not necessary for the web
application.
Carefully configure user roles and
permissions to strictly limit access
for web application accounts.
Never use DBA, root, or system
accounts for general database
access.
Consider using a hardening guide
or tool appropriate for your
database platform.
Disable stored procedures that
are not required for the
application.
Ensure that the server is physically
secure.
Narration: So far, we have looked at how we can improve the security of the operating system
and web servers. Now let's look at how we can defend database servers.
Remove or disable unnecessary database features or services.
Strictly limit user accounts and disable or rename default accounts.
Use a packet filter or firewall to tightly restrict access to database ports.
Remove any demo, testing, training, and all other databases not necessary for the
web application.
Carefully configure user roles and permissions to strictly limit access for web
application accounts. Never use DBA, root, or system accounts for general database
access.
Consider using a hardening guide or tool appropriate for your database platform.
Disable stored procedures that are not required for the application.
Defense in Depth: Other Strategies

Following are key measures you can take to further mitigate security misconfigurations:
Regularly audit the full system configuration.

Use software to perform regular vulnerability scanning of the web server.
Where possible, manage system configuration settings with version control software.
Deploy intrusion detection systems to identify any overlooked misconfigurations.
Monitor search engines to identify changes made to your web application and identify
possible information leaks.
Utilize log analysis or event management software to identify unusual system activity.
Narration: Are there additional ways to improve the system security? Yes!
Here are measures you can take to further mitigate security misconfiguration.
Regularly audit the full system configuration.
Use software to perform regular vulnerability scanning of the web server.
Where possible, manage system configuration settings with version control software.
Deploy intrusion detection systems to identify any overlooked misconfigurations.
Monitor search engines to identify changes made to your web application and identify
possible information leaks.
Utilize log analysis or event management software to identify unusual system activity.
Module Summary
Threat 1: Injection
In this topic, you learned about the first threat in the OWASP
Top 10 list, injection. You learned what an injection attack is,
why it is a high-risk threat, and how it works.
You also learned about SQL injection and how to prevent SQL
injection vulnerabilities.
Click each objective above to learn more.
Click here to review this section again.
Threat 2: Broken
Authentication and
Session Management
In this topic, you learned about the second threat in the OWASP
Top 10 list: Broken Authentication and Session Management.
You saw examples that demonstrated the threat. You learned
about how to make secure authentication and session
management an integral part of any web application by
reviewing best practices for user logins, password and password
policies, session tokens, cookie security, and cryptography.
Threat 3: Cross-Site
Scripting (XSS)
In this topic, you learned about cross-site scripting. You learned

what XSS is, why it is considered a threat, and the risks
associated with it.
You also learned about the two categories of XSS
attacksstored and reflectedin detail, with the help of realworld examples.
Then, you learned about the different techniques that can be
used to prevent XSS attacks: input validation and output
sanitizing.
Threat 4: Insecure
Direct Object
References
In this topic, you learned about the insecure direct object

references threat.
You learned about direct object references and the concept of
insecure references.
You learned how to identify an insecure direct object reference
threat and how a direct object reference can be exploited.
You also learned how to prevent these threats.
Threat 5: Security
Misconfiguration
In this topic, you learned about the different ways that security
can be misconfigured and the methods by which you can
prevent misconfigurations.
You also learned key approaches to hardening the operating
system, improving the security of web servers, and improving
the security of database servers. In addition, you learned how to
further mitigate security misconfigurations.

This module provides an overview of the remaining five threats of
the OWASP Top 10 list, in the following topics:

Module Objective:
After completing this module, you will be able to:
Explain the final five threats in the OWASP Top 10 list and their
Narration: This module provides an overview of the remaining five threats of the OWASP Top 10 list, in
the following topics:

Threat 8: Cross-Site Request Forgery
After completing this module, you will be able to explain the final five threats in the OWASP
Top 10 list and their mitigation techniques.
Narration: In the first module, we covered the first five threats in the OWASP Top 10 list. In this
module, we'll look at the next five threats in detail.
The next threat we will discuss is sensitive data exposure. This threat further
comprises two steps: insecure cryptographic storage and insufficient transport layer
protection. First, let's look at insecure cryptographic storage.
Cryptography is a critical aspect of information security.
Heavy mathematical theory and unfamiliar technology frequently cause some
developers to avoid or postpone implementing strong cryptography.
Quite often, strong encryption comes late in the development process as an
afterthought or as a low-priority enhancement.
Strong encryption is a fundamental and vital part of protecting the systems most
sensitive secrets. Although the learning curve may seem steep, best practices for basic
cryptography are easy to learn and implement. The alternativefailure to properly
secure the data that users place in your trustcan negatively impact your
organizations reputation.
But what should you keep in mind when storing data using cryptography?
Although we use cryptography in several areas of applications, here we will
specifically focus on cryptographic storage. Next, well look at how to protect against
the risks of insufficient transport layer protection.
In terms of storing data, there are two key considerations: Using symmetric
encryption algorithms such as AES to securely store data, requiring a specific keyor
passwordto retrieve the data; and using one-way hashing algorithms such as SHA256 to store hashes used to verify user passwords.
Insecure Cryptographic Storage Overview
Narration: To understand what insecure cryptographic storage is, lets look at an example.
An application is designed such that debit card information is encrypted in the
database. The purpose of this encryption is to avoid end user exposure.
But, the drawback here is that the database works to decrypt any queries against the
columns of the debit card automatically.
This functioning of the database could be exploited by an SQL injection attack; the
damage being that all the debit card information is then retrieved in cleartext.
Can you identify the insecure data storage error that occurred in this scenario?
Common Cryptographic Storage Mistakes

When storing sensitive data,
avoid these common errors.
Failure to encrypt sensitive
data.
Using homegrown
algorithms.
Using weak, out-of-date
algorithms.
Using insufficient key
lengths.
Using weak random number
generation.
Failure to use salt with
password hashes.
Poor key management.
Let's look at how to avoid
these errors when storing
sensitive data.
Narration: When storing sensitive data, avoid these common errors:

Failure to encrypt sensitive data.
Using homegrown algorithms.
Using weak, out-of-date algorithms.
Using insufficient key lengths.
Using weak random number generation.
Failure to use salt with password hashes.
Poor key management.
Let's look at how to avoid these errors when storing sensitive data.
Selecting Cryptographic Algorithms

Avoid errors when storing sensitive data by
selecting appropriate cryptographic
algorithms.
Appropriate algorithms and minimum key
lengths change over time and may differ.
If your organization operates in a regulated
industry, regulations and standards can
often provide guidance on using the correct
algorithm and key length.
Always be aware of the minimal acceptable
algorithms and key lengths, and stay well
ahead of these minimums.
More information and current
recommendations can be found at:
http://www.keylength.com
http://csrc.nist.gov/groups/ST/toolkit
http://en.wikipedia.org/wiki/Key_size
Keep in mind that other algorithms such as
MD5 or SHA1 are inadequate and should be
phased out of all applications.
Narration: You can avoid errors when storing sensitive data by selecting appropriate
cryptographic algorithms.
Whether encrypting data or storing passwords in the form of hashes, always select
algorithms that meet minimum acceptable standards. It is difficult to prove with
certainty that any particular algorithm is without flaws.
Over time, certain algorithms have withstood scrutiny and, with proper key lengths,
are the only acceptable ones to use. Always know the minimal acceptable algorithms
and key lengths, and stay well ahead of these minimums.
Keep in mind that other algorithms such as MD5 or SHA1 (both used for hashing) are
inadequate and should be phased out of all applications.
Generating Random Numbers
Narration: Another way of minimizing errors when storing sensitive data is to use random
numbers.
The strength of any cryptographic operation relies largely on the ability to use highquality random numbers. Although computers can generate what appear to be
random numbers, it is actually very difficult to generate truly unpredictable
randomness.
Cryptography that uses weak sources of randomness is ultimately vulnerable to
attack.
You can use random number generators (RNGs) to generate numbers randomly.
There are three types of RNGs: algorithm-based, weak, and strong.
Click each image to learn more.
Hashing With Salt Overview
Narration: Passwords are critical information that need to be secured with high priority.
Password hashes are the only acceptable manner of storing user passwords.
You do not need to store the actual password; comparing the results of a hashing
algorithm is sufficient to prove that a password matches what was originally stored.
However, password hashes are vulnerable to brute-force attacks and require
strategies to make such attacks more difficult.
If you run a password through a hashing algorithm, you will always get the same
result. To prevent attackers from simply collecting large databases of hashes, you use
a salt.
So, what is a salt?
A salt is random data added to the hashing process to ensure that every hash of a
password produces a unique result. The salt is saved as a pseudo-secret that the
application later uses when comparing passwords. The salt ensures that an attacker
must always compute the hash in a brute-force attack.
Weakness of Unsalted Hashes

Hash functions allow you to verify user passwords without having to store the actual passwords.
If you use unsalted hashes, the passwords are not stored securely enough.
The table shown is a common but obsolete method that many websites use to store and verify passwords using unsalted
MD5 hashes.
Narration: Hash functions allow you to verify user passwords without having to store the actual
passwords.
However, if you use unsalted hashes, the passwords are not stored securely enough.
Let's look at this with an example.
The table shown here is a common but obsolete method that many websites use to
store and verify passwords using unsalted MD5 hashes.
In the table, you can see that the users athompson and cwhite both have the same
hash.
Because an unsalted hashing algorithm always produces the same hash for a
particular password, we know that they both have the same password. This is
significant because, if you know the password of one of these users, you also know the
password for all other users with the same hash.
This is why leaks of unsalted password hashes quickly get cracked, and why the 2012
LinkedIn hash leak mentioned previously resulted in so many exposed user
passwords.
How Salted Hashes Work
Narration: You have seen the table generated with the use of unsalted hashes.
Now let's look at the table generated with salted hashes.
Observe that the second table now shows password hashes with the addition of a salt.
Although users athompson and cwhite still have the same password, their stored
hashes are now different.
Salt values greatly increase the resilience of password hashes. Although actual
implementations vary, a salt is similar to a password on top of the users password. By
adding a random value to each user password, every hash is unique, even if two
passwords are the same. Also, because you are protecting the password itself, you can
store the salt along with the hash.
Key Derivation Functions

Key derivation functions
increase the size and entropy
of a password before hashing
to accomplish the following:
Hinder brute-force attacks by
increasing the cost in both
CPU cycles and memory
overhead.
Increase the bit length and
entropy of short passwords.
Reduce exposure to
cryptanalytic and timing
attacks by working from keys
of standard length and high
entropy.
Add additional salt and
optionally a master key or
password.
Key derivation functions only
ensure a certain cost in
brute-force attacks on
passwords of any size, and
protect weak passwords
from certain attacks.
Algorithms such as PBKDF2,
bcrypt, and scrypt are all
common key-derivation
functions.
Narration: You can also secure data by strengthening the keys used.
Key derivation functions, also called key stretching or strengthening functions, can
strengthen password hashes. These algorithms perform cryptographic functions over
many hundreds or thousands of iterations, applying a salt or master key in each
iteration.
Key derivation functions do not compensate for weak passwords. These functions
increase the size and entropy of a password before hashing to protect them from
certain attacks.
Algorithms such as PBKDF2, bcrypt, and scrypt are all common key-derivation
functions.
Key Management: Best Practices
Narration: Let's look at a scenario and determine the best practice for the scenario in relation to
protecting encryption keys.
The most basic vulnerability scenario is when developers include the key as part of an
if statement in the application. If the users input matches the keys character string,
access is granted.
When using symmetric encryption, it is critical that you follow best practices for
protection of the encryption keys.
Never hard-code encryption keys in your application.
Carefully plan file system permissions to protect files that contain encryption keys.
If possible, store encryption keys outside of the web content directories.
Build the application to support periodic key changes and establish a regular schedule
for changing keys.
Do not include encryption keys in backups; back up and store them separately.
Insufficient Transport Layer Protection Overview
Narration: Insufficient transport layer protection is the other threat included under Threat 6,
Sensitive Data Exposure. Let's look at this threat in detail.
A vital part of protecting sensitive data is ensuring that you encrypt network
communications with transport layer security, or TLS. Without TLS, session IDs and
sensitive data are exposed and vulnerable, and can be intercepted by an attacker.
Note that TLS is similar to and based on the older protocol called secure sockets layer
(SSL). However, all versions of SSL have significant security flaws and are considered
unsafe to use. Therefore, your application should support only TLS for secure
communicationsat minimum TLS v1.0, but preferably TLS v1.1 or later.
The table on screen lists the security status for each version of SSL and TLS.
Attacks on SSL and TLS
Narration: Though you should only use TLS and not SSL, in reality SSL is still widely in use.
Therefore, it is important that you understand the common threats against both SSL
and TLS. Lets discuss these threats.
Although many widely-deployed software libraries such as OpenSSL are considered
mature products, they are by no means free of vulnerabilities. Recent discoveries have
shown that even well-established software is still prone to critical security faults.
Heartbleed, discovered in 2014, is a buffer over-read flaw in OpenSSL that allows
anyone to view segments of server memory, revealing private keys, passwords, and
other secrets.
Numerous other attacks on SSL have evolved over the years; lets look at some of the
most common of these attacks.
Version Rollback or Downgrading
These attacks force a client or server to downgrade or rollback to an older protocol
version or a weaker cipher suite. Attacks such as FREAK and Logjam, for example, both
cause the connection to downgrade to weak 512-bit encryption keys that are easy to
attack. SSL Stripping is another variation of downgrading that causes a web client to
not use encryption at all, for example connecting with HTTP instead of HTTPS.
Compression Flaws
In some cases, compression can introduce flaws allowing an attacker to decrypt small
portions of the traffic, such as a cookie or session token. CRIME is an attack against
TLS-level compression that can expose sensitive cookies. TIME and BREACH both
attack HTTP-level message body compression to reveal data in a server response.
Padding Oracle Attacks
Block ciphers such as CBC and EBC use padding to ensure that every block is the same
size. Padding Oracle attacks use feedback from a server to determine which padding is
valid for an encrypted message. This gives enough information to decrypt the
message.
Renegotiation Attacks
Flaws in the way SSL and TLS handle handshake renegotiation allow for an attacker to
inject plaintext into client requests. Although the attacker cannot decrypt this traffic,
the ability to inject plaintext could enable other more serious attacks.
RC4 Attacks
RC4 has long been a widely-implemented stream cipher used with SSL and TLS.
Although known vulnerabilities exist with RC4, due to the manner in which it is used
with SSL and TLS, it was still considered secure for some time. However, recent
research has shown that RC4 is no longer considered sufficiently secure for use with
TLS.
BEAST
Browser Exploit Against SSL/TLS (BEAST) is a chosen plaintext attack against SSL 3.0
and TLS 1.0. The attack involves injecting a malicious JavaScript or other applet into
the same origin of the web site and sniffing the network to obtain cookie and other
HTTP headers. Mitigation largely depends on the client using up-to-date browser
software.
BERserk is vulnerability with Mozillas NSS crypto library that allows forgery of RSA
signatures, leaving users open to man-in-the middle attacks. Both Mozilla Firefox and
Google Chrome were affected by this vulnerability.
In recent years, researchers have discovered serious vulnerabilities in many products
including Java, Apples iOS and OS X, GNUTLS and Microsofts Schannel. Therefore, it is
critical to keep server software and libraries up to date.
Summary of Attacks on SSL and TLS

Here is a summary of common attacks on SSL and TLS.
Narration: This table summarizes the common attacks on SSL and TLS.
As you can see, secure connections can be difficult to achieveserver configuration
and up-to-date software are critical. Lets see some of the options available to help
ensure secure connections.
Selecting Cipher Suites
Narration: Cipher suites are a critical determining factor of the strength of a TLS session.
A cipher suite is a collection of ciphers used for various aspects of a secure connection.
A server and client will negotiate a cipher suite that both ends can support. Although
it is not necessary to understand the exact naming mechanism for cipher suites, it is
important to be able to identify which suites are safe to use and in which order you
should use them.
Lets discuss some basic rules.
Never use a cipher suite with NULL encryption as these do not encrypt the TLS traffic.
Never use a cipher suite with Anon as these do not verify certificates.
Never use a cipher suite with an EXPORT-grade cipher as these only provide 40- or 56bit security.
Never use a cipher suite that includes RC4, MD5, or DES, although 3DES is satisfactory
for backwards compatibility.
Note that if you support TLS 1.0, you should also disable any CBC-mode ciphers to
prevent version rollback attacks.
For more information, refer the TEAM Mentor article Use Only Strong TLS Algorithms.
NOTE:
Prioritizing Cipher Suites
Narration: The priority of a cipher suite is just as important as the selected suites because this
allows the server to negotiate the most secure combination available. You should
prioritize cipher suites as follows:
Prefer any cipher suite with ECDHE, AES, and GCM as this is currently the strongest
combination of ciphers.
Next, prefer any cipher suites that use DHE; both ECDHE and DHE allow the server to
support Perfect Forward Secrecy which ensures that a compromise of a session key
will not allow for decryption of past or future communications.
Next, prefer AES 128 over AES 256. Although AES 256 is stronger than AES 128, the
current consensus is that AES 128 is the better choice and should be a higher
preference.
Include 3DES last for backwards compatibility, if necessary.
Securely Implementing TLS
Narration: Lets discuss the important points for securely implementing TLS.
Use TLS to protect all network communications, even for internal network traffic.
For web sites, if possible, disable HTTP and implement HTTP Strict Transport Security
(HSTS) to force all traffic to use HTTPS.
Completely disable SSL and only allow TLS, except in extreme and restricted scenarios
where necessary to communicate with legacy hardware or software. If possible,
disable TLS 1.0 or implement a plan for phasing out TLS 1.0 support.
Disable support for TLS compression and renegotiation initiated by the client.
Keep all software and encryption libraries up to date to protect from the latest
threats.
Use the Secure flag on all authentication cookies.
Keep sensitive information such as session tokens off the URL.
Use vulnerability scanners to identify and assess all SSL and TLS implementations on
your network.
For more information, see SSL Server Test.

NOTE:
Best Practices for Handling SSL/TLS Certificates

Follow these best practices
for handling SSL or TLS
certificates:
Never use self-signed
certificates because they
provide little security over
non-encrypted
communications and provide
a false sense of security.
Do not use X.509 certificates
with an RSA or DSA key less
than 2048 bits.
Do not use X.509 certificates
signed using MD5 hash, due
to known collision attacks.
Store private keys in a secure
location, never on the server
itself.
Keep certificates up-to-date
and include all applicable
domain names so that the
user is never presented with
a certificate error.
Use extended validation (EV)
certificates if appropriate for
your organization.
Consider using HSTS, HTTP
Public Key Pinning, and OCSP
Stapling.
Narration: Let's now look at the best practices for handling SSL or TLS certificates.
Never use self-signed certificates. They provide little security over non-encrypted
communications and provide a false sense of security.
Do not use X.509 certificates with an RSA or DSA key less than 2048 bits.
Do not use X.509 certificates signed using MD5 hash, due to known collision attacks.
Store private keys in a secure location, never on the server itself.
Keep certificates up-to-date and include all applicable domain names so that the user
is never presented with a certificate error.
Use extended validation (EV) certificates if appropriate for your organization.
Consider using HSTS, HTTP Public Key Pinning, and OCSP Stapling.

Most applications have at least
some requirements for restricting
access to sensitive application
functions. Insufficient access
controls could allow attackers to
access administrative features,
AJAX endpoints, or other
unprotected files in your web
content directories. Examples of
attacks might include path
traversal, directory browsing, file
and directory enumeration, and
unauthorized file access.
The greatest risk of these
vulnerabilities is exposure of
sensitive user data or information
that could facilitate other attacks.
Common examples of failing to
restrict URL access include failure
to:
Prevent directories from listing
contents when no default
document exists.
Authenticate AJAX or other APPI
requests properly.
Restrict access to administrative
and maintenance features.
Protect log files, backups, test files,
hidden files, or temporary files.
Map file extensions to mime types
to control how they are handled.
Check for directory traversal when
accessing files based on user input.
Restrict access to folders on FTP
servers.
Narration: We have covered six of the Top 10 OWASP 2010 threats list so far. Let's look at the
next threat: missing function level access control.
Most applications have at least some requirements for restricting access to sensitive
application functions. Insufficient access controls could allow attackers to access
administrative features, AJAX endpoints, or other unprotected files in your web
content directories. Examples of attacks might include path traversal, directory
browsing, file and directory enumeration, and unauthorized file access.
The greatest risk of these vulnerabilities is exposure of sensitive user data or
information that could facilitate other attacks.
Common examples of failing to restrict URL access include failure to:
prevent directories from listing contents when no default document exists;
authenticate AJAX or other APPI requests properly; restrict access to administrative
and maintenance features; protect log files, backups, test files, hidden files, or
temporary files; map file extensions to mime types to control how they are handled;
check for directory traversal when accessing files based on user input; and restrict
access to folders on FTP servers.
Failure to Restrict URL Access Illustrated - Path Traversal

Vulnerabilities
Narration: Lets look at some of the vulnerabilities caused by failure to restrict URL access,
starting with the path traversal vulnerability.
Path traversal occurs when an application does not properly check user input and
allows access to files outside the intended file path.
By including a dot-dot-slash (../), an attacker might be able to traverse directories in
the file system.
The application must validate all user input that affects file system operations.
Let's look at an example.
Consider that you are accessing a web application with the URL as shown.
What do you think could be a problem here?
This example downloads a file attachment. An attacker can see that it refers to an
actual file name, and might try to access other files.
How can an attacker do damage here?
If the application does not properly check for directory traversal, an attacker might be
able to access other files on the system.
Note that due to a variety of encoding techniques, checking for specific character
sequences such as dot-dot is prone to error. You must completely resolve and
normalize the path using operating system functions, and then check to ensure that
the user is authorized to access that path or file.
Authorization Strategies
Here are some guidelines to
help ensure proper URL
authorization throughout a
web application. Adherence
to these strategies requires
careful planning and an
organized approach to user
permissions.
Clearly separate public,
private, and administrative
content by placing them in
separate physical directories.
Deny access to all protected
pages and sensitive functions
by default. Then, check user
permissions to explicitly
grant access.
Consider role-based security
to define clear boundaries
and check user roles before
allowing access to functions,
data, files, URLs, and
services.
Supplement security
boundaries through userbased access control and file
system permissions.
Centralize authorization
functions and policy
management. Avoid hardcoded policy enforcement in
individual modules.
When making authorization
decisions based on workflow
or other state, always
consider unexpected state
conditions that might occur.
Always make authorization
decisions on the server side,
never in client-side code.
Narration: Here are some guidelines to help ensure proper URL authorization throughout a web
application. Adherence to these strategies requires careful planning and an organized
approach to user permissions.
Clearly separate public, private, and administrative content by placing them in
separate physical directories.
Deny access to all protected pages and sensitive functions by default. Then, check user
permissions to explicitly grant access.
Consider role-based security to define clear boundaries and check user roles before
allowing access to functions, data, files, URLs, and services.
Supplement security boundaries through user-based access control and file system
permissions.
Centralize authorization functions and policy management. Avoid hard-coded policy
enforcement in individual modules.
When making authorization decisions based on workflow or other state, always
consider unexpected state conditions that might occur.
Always make authorization decisions on the server side, never in client-side code.
File and Directory Enumeration

Often in one of the first steps
in an attack, the attacker
enumerates files and
directories to find useful
information or identify
known vulnerabilities. This
process, sometimes called
forced browsing, involves
submitting lists of URLs to
see if they exist.
These URLs may include
unprotected log files or
backup directories, or may
involve looking for specific
applications known to be
vulnerable.
It is important to identify
unprotected and potentially
vulnerable files by:
Manually reviewing web
content directories for
unneeded, sensitive, or outof-date files.
Running automated
vulnerability scanners on
your web server to identify
vulnerabilities that an
attacker might also be able
to find.
Reviewing web logs and web
log statistics to identify
possible abuse of
unidentified vulnerabilities.
Employing a web application
firewall or intrusion
detection system to block or
at least identify unknown
vulnerabilities.
Narration: Often in one of the first steps in an attack, the attacker enumerates files and
directories to find useful information or identify known vulnerabilities. This process,
sometimes called forced browsing, involves submitting lists of URLs to see if they exist.
These URLs may include unprotected log files or backup directories, or may involve
looking for specific applications known to be vulnerable.
It is important to identify unprotected and potentially vulnerable files by:
Manually reviewing web content directories for unneeded, sensitive, or out-of-date
files.
Running automated vulnerability scanners on your web server to identify
vulnerabilities that an attacker might also be able to find.
Reviewing web logs and web log statistics to identify possible abuse of unidentified
vulnerabilities, and employing a web application firewall or intrusion detection system
to block or at least identify unknown vulnerabilities.

Narration: The eighth threat is cross-site request forgery.

Cross-site request forgery is a technique that uses cross-site scripting, browser flaws,
social engineering, and other methods to cause a user to perform an undesired action
in their current authenticated user context.
How does it work? Well, instead of trying to steal your password, attackers can use
cross-site request forgery to get you to take action for them.
An example of cross-site request forgery is the previously mentioned Tumblr worm.
That attack exploited cross-site scripting and created a new post that further spread
the attack. The attacker who created the first malicious post never compromised
anyones account. The attack was designed so that just viewing the post would cause
the user to unknowingly reblog the same post under their account.
Lets look an example in detail. Consider a web application that has a form for adding
new users, and after submitting the form, the resulting URL appears.
Although an attacker cannot access this URL without being an administrator, he can
use a cross-site request forgery attack to get the administrator to access it on his
behalf.
In this example, an attacker does not have access to the particular admin page for
adding a user, but can trick the administrator's web browser to visit that URL, thinking
that it is grabbing an image.
First, the attacker fills out the feedback form and includes an image tag that links to
the URL for creating a user.
Later, an admin views the feedback, and the browser interprets the image tag as if it
were HTML. This causes the browser to visit the URL to retrieve the image. However,
the image tag directs the admin's browser to visit the URL that creates a new admin
user. Instead of displaying an image, it has allowed the attacker to create a new
admin user account.
Preventing CSRF
DoubleSubmitted
Cookies
Using double-submitted cookies is a simple technique in which you

include session tokens in hidden form fields. When a user submits a
form, the session token in the form must match the token in their
cookie. Otherwise, the form submission fails.
Per-Request
Nonces
Per-request nonces provide an even stronger safeguard by

generating a random one-time tokenor noncein every form sent
to the user. The server tracks this nonce and accepts a form
submission only if the nonce matches the one originally sent to the
user.
OWASPs CSRFGuard project provides CSRF protection modules for
Java, PHP, and .NET.
Narration: How can you prevent cross-site request forgery attacks?

You can easily prevent cross-site request forgery attacks by using double-submitted
cookies and per-request nonces.
Click each method to learn more.
Threat 9: Using Components with Known

Vulnerabilities
Exploiting known flaws in
components is
particularly attractive to
attackers because:
Attackers generally learn
about flaws at the same
time as everyone else,
giving them a window of
attack before systems are
updated or patched.
Some sites will never get
patched.
Exploit code is often
widely available shortly
after a flaw is made
public.
With flaws in commonly
used components,
attackers can easily
automate massive attacks
and even compile lists of
vulnerable sites through
search engines.
Open-source applications
are easy for attackers to
review and find
unpublished
vulnerabilities.
Some open source
projects, although
popular, may not have
the development
resources or may be too
new to have been fully
reviewed for security
flaws. (On the other
hand, some open source
projects receive
significant public review,
and therefore few flaws
escape unnoticed.)
Narration: Keep in mind that even when you consistently follow security best practices, your
websites might still get hacked.
This is where we come to the ninth threat, which is using components with known
vulnerabilities.
Exploiting known flaws in components is particularly attractive to attackers. Because
attackers typically learn about flaws at the same time as everyone else, they can often
exploit a flaw before it is remedied.
In addition, a growing dependence on open source software and other external
components means increased exposure to vulnerabilities in these components.
With increasing popularity of open source projects, application frameworks that
reduce development time, and CMS plugin features that make it easy to install entire
modules, external code could easily make up 50% or more of a modern applications
code base, making the application more susceptible to attacks.
Auditing External Components

Use the following strategies and techniques:
Carefully consider the risks of using any third-party components. Only use those produced
by reputable developers and that have received extensive security review.
Maintain lists or repositories of components approved for use in your organization.
Identify all third-party components in existing applications and their versions, including any
child components.
Subscribe to notifications for new and updated versions of all components you use and
keep all components up-to-date.
Use both manual and automated reviews to identify security flaws in any components you
implement, whenever possible.
Be aware of and document configuration and other implementation details necessary for a
components security.
Prevent your application from displaying names and version numbers of included
components, if possible.
Narration: To secure external libraries, frameworks, or components, you need to adopt some
unique strategies.
Carefully consider the risks of using any third-party components. Only use those
produced by reputable developers and that have received extensive security review.
Maintain lists or repositories of components approved for use in your organization.
Identify all third-party components in existing applications and their versions,
including any child components. For example, some frameworks may rely on multiple
external libraries that you must also track.
Subscribe to notifications for new and updated versions of all components you use and
keep all components up-to-date. Consider search engine alerts to learn about
vulnerabilities as they are made public.
Use both manual and automated reviews to identify security flaws in any components
you implement, whenever possible.
Be aware of and document configuration and other implementation details necessary
for a components security.
If possible, prevent your application from displaying names and version numbers of
included components.

Narration: The last threat on the list is unvalidated redirects and forwards.
Web applications often use URL redirection to handle moved resources, abbreviate
URLs, load-balance, or track outgoing links.
Although redirecting is convenient and essential for some applications, when
implemented improperly, it can expose the user to phishing and other attacks.
Users believe they are clicking a known or trusted URL but are instead redirected to a
different, possibly malicious URL.
Although primarily implemented as a phishing attack, an attacker might also exploit
the vulnerability in conjunction with cross-site scripting or cross-site request forgery
attacks.
Finding Vulnerable Components
Narration: What components are vulnerable to unvalidated redirects and forwards, and how can
you identify them?
Components that redirect based on any user input, including less obvious input
sources such as HTTP headers, cookie contents, hidden form fields, reverse DNS
lookups, or other data that a user can modify, are all examples of vulnerable
components.
To identify these vulnerable components or weaknesses, you may need to perform a
deep and creative review of all code.
Elements to look for include files with keywords such as redirect, go, and link. You also
need to check for URL parameters such as URL, ReturnURL, and redirect.
Although some redirect URLs may be obvious, an attacker could potentially exploit
redirects in a number of ways. These include:
Pages that include iframe content or pop-up windows based on user input.
Pages that grab and include remote content based on user input.
Login pages that redirect back to where a user was before logging in.
Protecting Redirects
Whitelists
Maintain a list of valid domains or URLs and restrict

redirection to only the items on the list.
Lookup Tables
Use a redirect ID or keyword that the application uses to

look up the actual URL to redirect to.
Intermediate Warning
Pages
In some cases, you may need to specifically warn users

that they are leaving the current site.
Nonces and Message

Authentication Codes
(MACs)
When redirecting from a form submission, nonces and

MACs can ensure that redirect URLs originated from your
application.
Application Firewalls
and Intrusion
Detection Systems
Although not effective enough to prevent the problem,

application firewalls or intrusion detection systems can
help identify and block known vulnerabilities, unusual URL
patterns, or attempts to obfuscate malicious input.
Narration: By definition, using redirects and forwards on a web page creates a vulnerability. If
the page is compromised, the URL can be changed and users can be unknowingly
redirected to a nefarious web page. Therefore, before implementing redirects or
forwards, always consider more secure alternatives.
If redirects or forwards are necessary, you can use a number of strategies to protect
them from attackers. These include whitelists, lookup tables, intermediate warning
pages, nonces and MACs, and application firewalls and intrusion detection systems.
Click each strategy to learn more.
OWASP 2007 Top Ten Vs. OWASP 2010 Top 10

Past Top Risks: OWASP 2007 Top Ten
Narration: Every few years, OWASP re-evaluates and re-prioritizes its list of top ten web
application security risks.
As you can see from the table, malicious file execution and information leakage
and improper error handling are two risks in the 2007 Top Ten that were not included
in the 2010 list. However, they are worth reviewing.
First, let's look at the malicious file execution threat.
Malicious file execution vulnerabilities are still found in many applications. Developers
sometimes directly use or concatenate potentially hostile input with file or stream
functions, or they improperly trust input files. In addition, on many platforms,
frameworks allow external object references, such as URLs or file system references.
When data is not properly validated, it can lead to arbitrary, remote, and hostile
content being included, processed, or invoked by the web server. This can allow
attackers to perform remote code execution or remote root kit installation and
completely compromise the system.
To prevent malicious file execution vulnerabilities, use strict input validation and
carefully planned file permissions.
Finally, let's look at the information leakage and improper error handling threat.
Poorly-configured applications can unintentionally leak information about their
configuration and internal structure through information provided in error messages.
Even vague error messages can be useful to an attacker.
To prevent information leakage, never reveal too much information to users if an error
occurs. Save detailed debugging information to a separate, protected log file, and use
search engine alerts to monitor your web domain for error messages.
Module Summary
Threat 6: Sensitive
Data Exposure
In this topic, you learned about protecting sensitive data through

cryptography and secure transport protocols.
You learned about insecure cryptographic storage in an example
scenario. In addition, you learned about common cryptographic
storage errors and how to avoid them by using appropriate
cryptographic algorithms, RNGs, and hashed, salted algorithms.
You learned about the best practices for managing keys.
You learned about insufficient transport layer protection and the
security status for each version of the SSL and TLS protocols.
You learned how to securely implement TLS with the help of an
example. Finally, you learned about the best practices for proper
TLS implementation and for handling SSL or TLS certificates.
Threat 7: Missing
Function Level
Access Control
In this topic, you saw some common examples of failing to restrict

URL access and path traversal vulnerabilities.
You also learned about the guidelines for proper URL authorization
in a web application.
Threat 8: Cross-Site
Request Forgery
(CSRF)
In this topic, you learned about cross-site request forgery.

You learned about CSRF with the help of an example, and you
learned how to prevent CSRF attacks: use double-submitted
cookies and per-request nonces.
Threat 9: Using
Components with
Known
Vulnerabilities
In this topic, you learned why components with known

vulnerabilities are attractive targets for attack, and you learned
strategies to audit these components in order to help secure your
application.
Threat 10:
Unvalidated
Redirects and
Forwards
In this topic, you saw an example that showed how unvalidated

redirects and forwards occur. You also learned about how to find
vulnerable components and how to protect redirects by using
whitelists, lookup tables, intermediate warning pages, nonces and
MACs, and application firewalls and intrusion detection systems.
Locating Additional Resources

For more information on OWASP Top 10 - Threats and Mitigation, you can refer to
https://www.owasp.org.
Narration:
TEAM Mentor eKnowledge

Provides faster and better remediation guidance within the developers environment
TEAM Mentor is an interactive Application Security eKnowledge base with thousands of articles on how
to prevent vulnerabilities during application development. Use TEAM Mentor to find guidance for
implementing the application security controls that are relevant to your particular application in your
development language. With optional plugins to the most popular Static 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 questions. Integrating security scanning and guidance
into a development workflow ultimately results in quicker production of more secure and stable
applications.
Narration:

OWASP Top 10 - Threats and Mitigations

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OWASP Top 10 - Threats and Mitigations

Uploaded by

Copyright:

Available Formats

Print

OWASP Top 10 - Threats and Mitigations

Module 1: OWASP Top 10 Threats: Part 1

Threat 2: Broken Authentication and Session Management

Threat 3: Cross-Site Scripting (XSS)

Threat 4: Insecure Direct Object References

Threat 5: Security Misconfiguration

Module 2: OWASP Top 10 Threats: Part 2

Threat 6: Sensitive Data Exposure

Summary of Attacks on SSL and TLS

Threat 7: Missing Function Level Access Control

Threat 8: Cross-Site Request Forgery (CSRF)

Threat 9: Using Components with Known Vulnerabilities

Threat 10: Unvalidated Redirects and Forwards

OWASP 2007 Top Ten Vs. OWASP 2010 Top 10

Course Overview and Objectives

Module 1: OWASP Top 10 Threats: Part 1

Module Overview and Objectives

Understand the methodology used to determine risk.

OWASP 2010 and 2013

Threat 1: Injection, the Web's Greatest Risk

How Injection Works

SQL Injection Overview

SQL Injection Overview (Contd.)

SQL Injection in Action

Narration: This example shows how SQL injection works.

Advanced SQL Injection

SQL Injection Impact: Real-World Examples

Preventing SQL Injection Vulnerabilities

With prepared statements, the database performs the following

Although parameterized stored procedures are typically safe,

Validation of every user input is an important defense against

Additional Mitigation Techniques

When executing external programs or dynamically evaluating scripts, use extra

Threat 2: Broken Authentication and Session

The Session Lifecycle

Narration: User session management is the process of authenticating, authorizing, and

Narration: Here is a diagram depicting the steps in a typical session lifecycle.

Broken Authentication and Session Management: Best Practices

Always use SSL-encrypted forms for user login.

To better understand how to make secure authentication and session management an

Threat 3: Cross-Site Scripting (XSS)

Stored vs. Reflected XSS

In a stored XSS attack, also known as a persistent attack, an attacker

In a reflected XSS attack, also known as a non-persistent attack, the

XSS has two additional categories based on where the injection

The Mechanics of XSS Attacks

Stored XSS Attack

Stored XSS Attack

The Impact of XSS

A Real-World Example of XSS

Preventing XSS: A Two-Step Approach

Use whitelist validation to allow data that matches a set of

Preventing XSS: Escaping Web Application Output

Preventing XSS: The Importance of Character Sets

Threat 4: Insecure Direct Object References

Identifying Insecure Direct Object References

Exploiting a Direct Object Reference

Narration: So how exactly is a direct object reference exploited?

Prevent Insecure Direct Object References

You can use an indirect reference map to create an alternative ID or

Narration: How can insecure direct object references be prevented?

Threat 5: Security Misconfiguration

Narration: The fifth threat is the security misconfiguration threat.