Fundamentals of Application Security

Fundamentals of Application Security
07/01/2015

Table of Contents:
Course Overview and Objectives
Introduction
Introduction
What is security?
What is software security?
Cost of Security Defects
Threat Terminology
Module Summary
Challenge Security Misconceptions

The Changing Attack Profile
Functional Testing versus Security Testing
Security Bugs
All Software Has Bugs
Patches Do Not Guarantee Security
Internal Threats
Module Summary
OWASP
OWASP
Introduction to OWASP
SQL Injection
Key Concepts of SQL Injection
Preventing SQL Injection
Cross-site Scripting (XSS)

Key Concepts of Cross-site scripting (XSS)
Impact of XSS
Identifying XSS Flaws
Preventing XSS Flaws
Broken Authentication and Session Management

Session Hijacking
Preventing Session Hijacking
Example of Session Fixation
Insecure Direct Object Reference

Key Concepts of Insecure Direct Object Reference
Directory Traversals
Addressing Directory Traversal Issues
Cross-Site Request Forgery (CSRF)

Key Concepts of Cross-Site Request Forgery (CSRF)
Executing CSRF Attacks
Preventing CSRF
Security Misconfiguration
Security Misconfiguration: Dynamic Threat Environment
Mitigating Security Misconfiguration: Repeatable Hardening
Insecure Cryptographic Storage

Poorly Implemented Cryptography
Failure to Restrict URL Access
Insufficient Transport Layer Protection
Secure Sockets Layer and Transport Layer Security (SSL and TLS)
Internet Protocol Security (IPSec)
Unvalidated Redirects and Forwards

Mitigating Unvalidated Redirects and Forwards
Table Indirection Technique
Threats from earlier OWASP Top 10 List

Malware
Malicious File Execution
Information Leakage and Improper Error Handling

Preventing Information Leakage and Improper Error Handling
Module Summary
Security Principles
https://sony.absorbtraining.com/courses/clients/317/Courses/Sony/fund_of_appli_security_for_sony_170513/CourseFiles/print.htm#
1 / 57
07/01/2015
Security Principles
Structural Security
Principle of Least Privilege
Test Everything
Module Summary
Security Goals and Controls

Authentication
Authentication
Authentication Considerations
Authorization
Authorization Considerations
Module Summary
Security in the SDLC

Establishing Security Requirements
Categorizing Threats
Prioritizing Threat Mitigation
Developing Secure Code
Overview of Security Testing
Testing for Specific Types of Vulnerabilities
Leveraging Security Testing Tools
Stop and Think!
Module Summary
Locating Additional Resources (1 of 3)
eknowledge Solutions
2 / 57
07/01/2015
Course Overview and Objectives

Just like functionality, performance, and reliability, security is another
crucial component of an applications quality. Recognizing the risk that
software vulnerabilities represent, understanding their root causes, and
addressing these issues early in the software development lifecycle are
essential for being able to help your organization build secure software.
Course Prerequisites
This course requires that you meet the following prerequisites:
Programming knowledge and experience.
Course Objectives
Upon completion of this course, you will be able to:
Understand the attacker mindset and what is at risk.
Recognize the importance of managing software security risk and the
consequences of failing to do so.
Challenge security misconceptions.
Understand common security vulnerabilities and their mitigations.
Understand security principles.
Understand key security goals and controls.
Understand how security fits into the software development life cycle
(SDLC).
Just like functionality, performance, or reliability, security is another crucial component of an
Narration: applications quality. But what does software security mean? And why should you care about it?
Recognizing the risk that software vulnerabilities represent and understanding their root causes is
essential to enable you to help your organization build secure software. This course will teach you the
activities that an organization needs to undertake to ensure that the software it develops can
withstand malicious attacks.
This course assumes that you possess basic computer skills and a basic knowledge of the software
development process.
By the end of this course, you will be familiar with the main characteristics of a secure software
development lifecycle and the activities that your organization should perform to develop secure
software. Furthermore, you will recognize the need to address software security in your everyday
work.
Introduction
Introduction
Module Overview
This module will help you understand the importance of designing
and maintaining software security throughout the software
development lifecycle. You will learn the fundamentals of secure
software design, how to align security decisions with corporate
policies and strategies, and how software security failures can lead
to meaningful business risks.
Module Objectives
After completing this module you will be able to:
Understand the importance of software security.
Understand the cost of security defects.
Understand threat and risk management terminology.
Distinguish between types of attackers and their motivations.
This module will help you understand the importance of designing and maintaining software
Narration: security throughout the software development lifecycle. You will learn the fundamentals of
secure software design, how to align security decisions with corporate policies and strategies,
and how software security failures can lead to meaningful business risks. The module defines
threat terminology and helps you understand how threats are evaluated using threat modeling
techniques. Also demonstrated are guidelines on identifying attacks and understanding the
attackers motivations. Finally, the module explains why a consistent assessment methodology
is required to ensure secure software implementations.
What is security?
3 / 57
07/01/2015
What is security?
Information security seeks to protect the confidentiality, integrity, and availability of protected
Narration: information and systems. These three principles of information security are called the CIA
triad. Confidentiality means that private or proprietary information is protected from
unauthorized disclosure.
Integrity refers to the need to protect information from being modified or deleted by
unauthorized users.
Maintaining availability of protected systems ensures that information and business functions
will be reliably accessible.
What is software security?
Software security is the design and implementation of application functionality intended to

ensure the confidentiality, integrity, and availability of protected information and systems.
Software security must align with:
Confidentiality
Integrity
Software security is not the same as network security. Network security focuses on restricting
communication paths between systems. Software security focuses on the run-time logic within
applications and the processing of data passed inside of an allowed communication path.
Software security is the design and implementation of application functionality intended to
Narration: ensure the confidentiality, integrity, and availability of protected information and systems.
Software security is just one component of the larger effort of developing robust, reliable code.
Insecure code is often also unstable, unreliable code, although this is not always true.
Many people confuse software security with network security. Network security primarily
focuses on the protection of an organizations servers and computer infrastructure with the
help of firewalls and intrusion-detection techniques. These mechanisms control the flow of
data between networked systems.
On the other hand, software security focuses on protecting information and resources made
accessible by applications and programs running on computer systems.
A good software security policy can trace its roots to larger corporate risk-management
policies. Software security is most effective when developed with the framework of an overall
security and risk-management strategy adopted by your organization.
4 / 57
07/01/2015
The cost of removing a security vulnerability increases exponentially as one progresses along
the software development lifecycle. Industry studies have shown that the total cost of removing
a security vulnerability during testing is less than 2 percent of the cost of removing it after
deployment. Removing a defect even earlier, during design, is far cheaper than removing it
during testing.
The longer it takes to find a security bug, the more money is spent fixing it. Imagine that a
Narration: security bug is found in a piece of popular desktop software; it would be expensive to fix. There
is the immediate damage to the reputation of the software vendor and customers could incur
losses as a result of active exploitation. The vendor must make a patch, warn all their
customers, and provide them with the patch. The patch must be tested and deployed. If you
are interested in reducing your total cost of securing your application, make it a point to
discover security vulnerabilities as quickly as possible in your application. Do not wait until your
customer discovers a vulnerability, or falls victim to a security breach, before you fix it.
Threat Terminology
5 / 57
07/01/2015
Module Summary
Understand
the
importance
of software
security
Understand the importance of software security

Security is defined as protecting information and systems from
unauthorized access, use, disclosure, disruption, modification, or
destruction. Confidentiality, integrity, and availability are the three main
components of information security and they form the CIA triad. Software
security means ensuring proper functioning of the software or an
application running on an organizations network even after an
unauthorized, malicious attack takes place.
It is critical for every organization to understand the risks a security failure
can cause and implement effective risk-management techniques in order
to reduce the likelihood of a costly incident.
You may click each objective above in order to learn more.
Click here to go over this section again.
Understand
the cost of
security
defects
Understand the cost of security defects

Organizations need to assess the software they develop at various stages
of the software development life cycle. The cost of finding bugs in the
initial stage is much less compared to finding bugs at later stages.
Understand
threat and
risk
management
terminology
Understand threat and risk management terminology

To get a deeper insight of software security, you need to be well-versed
with various terms associated with threats and security. Threats can be
categorized based on the goals and purposes of the attacks. By analyzing
risks, you can determine the probability of the occurrence of a problem. It
also helps you to identify the impact of a problem if it were to occur.
Distinguish
between
types of
attackers
and their
motivations
Distinguish between types of attackers and their motivations

In order to conduct proper threat modeling and design appropriate
defenses, it is important to understand the different types of attackers,
recognize their motives, and appreciate their skill sets. Not all software
requires the same level of security, so accurate asset identification and
threat modeling is essential to a well-designed risk management plan.
6 / 57
07/01/2015

Module Overview
This module highlights common misconceptions around
application security. We will explain each of these
misconceptions, explaining the risks these misunderstandings can
pose as well as steps you can take to avoid these common pitfalls.
Module Objectives
Describe common security misconceptions.
Explain how to avoid common security misconceptions.
This module highlights common misconceptions around application security. We will explain
Narration: each of these misconceptions, explaining the risks these misunderstandings can pose as well as
steps you can take to avoid these common pitfalls.
The Changing Attack Profile
Most people tend to think of security as a network problem. Their answer is to protect the
boundary of a system using firewalls and antivirus software.
The truth is that security is a software problem and network insecurities usually result from
flaws in applications running on the system or poor configurations.
It is estimated that over 70 percent of attacks against a companys network are at the
Application Layer, not at the system or network layer.
Most people tend to think of security as a network problem and the common answer to
Narration: security questions is to protect the boundary of a system with firewalls and Antivirus software.
However, in reality, security is a software problem. Most insecurities, including network
insecurities, result from flaws in applications running on the system or because of poor
configurations.
According to Gartner, over 70 percent of attacks on a companys network are at the
Application Layer, not at the system or network layer.
Network security does little to protect sites from an application-layer attack. For example, a
properly constructed and encrypted SSL Web request bypasses the firewall and is completely
unseen by a Network Intrusion Detection System. With that said, if attackers gain access
through the application layer, they can bypass most of the intrusion detection, hide behind SSL,
and enter an application database directly. Therefore, the general hack method is that an
attacker will attempt to penetrate the layer thats appropriate for the asset theyre trying to
hack.
7 / 57
07/01/2015
Functional Testing:
Functional testing verifies that the application does what it is supposed to do.
It includes applying inputs to verify correct outputs.
Functional testers ask "What is the software supposed to do?"
Security Testing:
Security testing involves verifying that the application does not do what it is not supposed to
do.
It includes applying inputs and verifying that no bad things occur.
Security testers ask "What is the software not supposed to do?"
Development teams have been performing functional testing for decades and the process is
Narration: pretty well entrenched. Usually, we have a test plan that tells us what the application is
supposed to do.
Say, for example, our test plan tells us to apply input A and that the application should
generate output B. As a functional tester, thats what we doapply A, watch for B and when
we see it, we mark the test case as passed. What we are doing here is verifying that the
application did what it was supposed to do. But this is both too much and not enough for
security testing. Its too much because security testers dont bother with what the application
is supposed to do. Its not enough because we should also be concerned with what the
application is not supposed to do!
In other words, when we apply input A, we should not care about output B that is supposed to
occur. Instead, we should try to verify that a vulnerable output C does not occur. So unlike
functional testing, security testing anticipates and tests for insecure behaviors.
Security Bugs
Security bugs are much harder to spot than
functional bugsthey often have no visible (to the
human eye) behavior.
To find security bugs:
Think about side effects and what sensitive data
might be exposed to.
Think backwardsthat is, instead of thinking
what should happen, we need to think about what
shouldnt happen.
When testing for security bugs, keep in mind that these types of bugs can be much harder to
Narration: spot than a functional bug. They are often the result of side effects or the interactions of
multiple bugs that result in an exploitable outcome. Security testing requires you to think first
about the possible threats to an application, the undesirable outcomes, and then progress
from the threat to the attacks that could realize that threat.
8 / 57
07/01/2015
All software will have bugs, even the best developers make mistakes. Some of these bugs will
inevitably result in security vulnerabilities. Factor time into your projects to think specifically
about security. If you conduct assessments of security early, find security bugs before its too
late, you may save a lot of time and money.
Even the best developers make mistakes. Practically speaking, all software has bugs, and some
Narration: of those bugs, regardless of the security controls used, will result in a security vulnerability that
may cause harm to your users or data. It is a common fallacy that security features will protect
against all security problems. A security feature is typically designed to protect against one
specific attack such as encryption protecting against eavesdropping. Encryption cannot protect
against SQL injection, buffer overflows, and other very common vulnerabilities.
Consider vulnerability assessments as a benefit to application development. U.S. $1 spent up
front on vulnerability assessment saves U.S. $10 during development and U.S. $100 after
release. Finding vulnerability in your design means that you have the opportunity to redesign
more securely. However, if you find vulnerabilities during the development phase, you need to
spend time and money on changing the design, which will have a cascading impact on your
implementation. If you find vulnerabilities during testing or after the software has been
released, you need to change the design and rewrite code to close the vulnerabilities.
Patches Do Not Guarantee Security
Releasing a patch may result in the resolution of a known security vulnerability but even patches
can have bugs. When deciding to patch, evaluate the risk of introducing new bugs and new
vulnerabilities against the damage caused by the vulnerability you are patching.
When you do patch a vulnerability, take the time to understand the root cause. Otherwise, you
may patch a symptom and have to continue re-patching as attackers discover workarounds and
related vulnerabilities.
Whether you are modifying, fixing, or patching code, all maintenance tasks must be evaluated
Narration: for risk so that maintaining your application does not introduce security flaws that were not
there prior to maintenance. Patches can fix security vulnerabilities and other bugs, and can
improve the usability or performance of your application. Though meant to fix problems,
poorly designed patches can sometimes introduce new problems.
When deploying a patch, bear in mind that patches only fix symptoms of known problems.
Patches prevent an attacker from using a known attack vector. There may be other problems
in your software that you do not know about yet. In addition, patches do not always address
the root cause of problems and may actually introduce new functional or security bugs.
Internal Threats
9 / 57
07/01/2015
Internal Threats
Insider attacks are a threat that needs to be considered when developing your application:
Attackers may already be inside the defended perimeter.
29 percent of all distinguishable attacks are from insiders.
Internal attackers have far more access to data and systems than outsiders.
The clueless and careless insiders also may bring external threats inside.
Need to consider internal threats in your solution design.
Internal systems are not always safer from attack than external systems.
Internal sources of threats cannot be ignored because its estimated that 29 percent of all
Narration: attacks are conducted by insiderseither intentionally or by executing viruses unintentionally.
Often attackers bounce the attack off of an internal user through XSS or a Trojan horse
program so the risk is almost as high as the external threat.
Insiders have far more access to data and systems than an external attacker and as a result
they can cause much more damage. They can directly steal data from the data store and
transport that data out of the organization. Common methods for transporting data are small
USB flash memory devices or sending the outbound data encrypted as an SSL transaction using
the fast network bandwidth. The data can even be chunked into small files to not set off the
suspicious of data leakage products on a network.
Clueless insiders can also bring external threats inside by using an infected laptop, clicking an email with a virus, and by browsing malicious sites that can attack your systems.
Consider internal threats in your solution design, treat all users as potentially hostile, and treat
internal data feeds to an application as not trusted. Remember that even the most trusted
user can be a hacker!
Module Summary
10 / 57
07/01/2015
Module Summary
Describe
common
security
misconceptions
Describe common security misconceptions

Developers may have the misconception that security is important at
the network and operating system levels and that its not important at
the application level, however, networks and operating systems can do
very little to prevent attacks.
Similarly, developers also tend to believe that patches, functional tests,
Java and .NET, cryptography, client-side security checks, and firewalls
are good enough to protect applications. However, these too have their
shortcomings and cannot prevent application-level attacks.
Explain how to
avoid common
security
misconceptions
Explain how to avoid common security misconceptions

Its very important for you to implement robust security in your
application code and conduct regular security tests. When conducting
security tests, you should look out for behaviors that should not
happen. Additionally, you should be wary of internal attacks and design
your system with the insider threat in mind. If you choose to use tools
such as Static Analysis Tools, Dynamic Analysis Tools, and Application
Vulnerability Scanners, be aware of their strengths and weaknesses so
they can be used most effectively.
Implementing security in application early helps prevent loss of money.
If you spend U.S. $1 on implementing application security during the
design phase, you may save U.S. $10 if the same problem was
discovered during the development phase and U.S. $100 after the
applications release.
11 / 57
07/01/2015
OWASP
OWASP
Module Overview
Open Web Application Security Project (OWASP) is an open-source
application security project. This module will help you understand
what OWASP is all about.
Module Objectives
Understand OWASP and its importance.
Name each of the OWASP top 10 vulnerabilities.
Understand the basics of the vulnerabilities and their impact.
This module will help you understand what Open Web Application Security Project (OWASP) is.
Narration: First, you will be introduced to what OWASP stands for and why it is important in the software
development lifecycle. Then, this module will provide details about the top 10 vulnerabilities
listed under OWASP and describe how these vulnerabilities can evolve over time as new
attacks are discovered. By the end of this module, you will know about the basics of
vulnerabilities and their impact on application software.
Introduction to OWASP
Open Web Application Security Project (OWASP)
OWASP was founded in 2003 and focuses on improving the security of Web application software.
OWASP is an open-source Web application security project. Members of this project include a
variety of security experts from around the world who have shared their expertise to produce a
list of the most critical Web application security flaws.
OWASP Top 10 is a document created for Web application security, which highlights the 10 most
important Web application vulnerabilities.
Note: The official OWASP Web site is www.owasp.org.
A popular trend, which started originally with the SANS Institute, is for organizations to publish
Narration: annual Top 10 lists of each years most common security vulnerabilities. Since 2003, the Open
Web Application Security Project (OWASP.org) has published such a list for Web application
security. The Open Web Application Security Project (OWASP) is a worldwide free and open
community focused on improving the security of Web applications.
Security experts from around the world gather to share their expertise with each other and
come up with the top 10 security vulnerabilities of the year. These vulnerabilities, collated as
the OWASP Top Ten, provide a powerful awareness document for Web application security and
represent a broad consensus about the most critical Web application security flaws. Therefore,
adopting the OWASP Top Ten is an effective first step towards changing the software
development culture within your organization into one that produces more secure code.
SQL Injection
Key Concepts of SQL Injection
SQL injection is a software vulnerability that occurs when data entered by users is sent to
the SQL interpreter as a part of an SQL query.
SQL injection exploits security vulnerabilities at the database layer. By exploiting the SQL
injection flaw, attackers can create, read, modify, or delete sensitive data.
Attackers provide specially crafted input data to the SQL interpreter and trick the
interpreter to execute unintended commands.
SQL injection is a software vulnerability that occurs when data entered by users is sent
Narration: to the SQL interpreter as a part of an SQL query. SQL injection exploits security
vulnerabilities at the database layer. By exploiting the SQL injection flaw, attackers can
create, read, modify, or delete sensitive data.
Attackers utilize this vulnerability by providing specially crafted input data to the SQL
interpreter in such a manner that the interpreter is not able to distinguish between the
intended commands and the attackers specially crafted data. The interpreter is tricked
into executing unintended commands.

12 / 57
07/01/2015

In order to prevent or mitigate SQL injection vulnerabilities:
Use input validation for length, type, syntax, and business rules.
Grant least privileges to those with database permissions.
Use strongly typed parameterized queries.
Show care when using stored procedures.
SQL injection can be prevented if you adopt an input validation technique in which user
Narration: input is authenticated against a set of defined rules for length, type, and syntax and
also against business rules.
You should ensure that users with the permission to access the database have the least
privileges. Additionally, do not use system administrator accounts like sa for Web
applications. Also, you should always make sure that a database user is created only for
a specific application and this user is not able to access other applications. Another
preventive measure is to remove all stored procedures that are not in use.
Use strongly typed parameterized query APIs with placeholder substitution markers,
even when calling stored procedures
Show care when using stored procedures since they are generally safe from SQL
injection. However, be careful as they can be injectable (such as via the use of exec() or
concatenating arguments within the stored procedure).
13 / 57
07/01/2015
Cross-site Scripting (XSS)

XSS is a Web-based attack performed on vulnerable Web applications.
In XSS attacks, the victim is the user and not the application.
In XSS attacks, malicious content is delivered to users using JavaScript.
The 3 type of XSS vulnerabilities are:
Persistent
Reflective (non-persistent)
DOM-based
As the name suggests, Cross-site scripting (XSS) is a Web-based security vulnerability in
Narration: which a user instead of a Web application is attacked. During such an attack, a
vulnerable Web application is exploited to deliver malicious content to users via script.
This content can include HTML or JavaScript code and appear as a persistent, a
reflective or non-persistent, or a DOM-based attack.
Impact of XSS
By exploiting XSS vulnerabilities, an attacker can perform malicious actions, such as:
Hijack an account
Spread Web worms
Access browser history and clipboard contents
Control the browser remotely
Scan and exploit intranet appliances and applications
Note: In an attack exploiting XSS vulnerabilities, anything that can be scripted, can be used
to attack a user.
When attackers succeed in exploiting XSS vulnerabilities, they can gain access to
Narration: account credentials. They can also spread Web worms or access the users computer
and view the users browser history or control the browser remotely. After gaining
control to the victims system, attackers can also analyze and use other intranet
applications.
Identifying XSS Flaws

XSS vulnerabilities may occur if:
Input coming into Web applications is not validated.
Output to the browser is not HTML encoded.
XSS allows an attacker to embed malicious script to be run by an unsuspecting browser,
using:
JavaScript
VB Script
ActiveX
HTML
Flash
Be suspicious any time user-provided input is echoed to the page, such as from:
Form input
Reverse DNS lookup
Hidden tags
An XSS flaw is likely to occur if the input data coming into Web servers is not validated
Narration: at the source or if data output to the user is not HTML encoded.
When incoming data isnt validated, XSS flaw allows attackers to embed malicious script
that can be executed on an unsuspicious Web browser using JavaScript, VB Script,
ActiveX, HTML, or Flash.
HTML encoding the output to the user will make sure any script is rendered as text and
not executed by the browser.
Additionally, you should be suspicious any time user-provided input is echoed on the
page. This applies to input such as form input, reverse DNS lookup, and hidden tags.
14 / 57
07/01/2015

In order to avoid the XSS vulnerabilities, you can perform the following actions:
URLEncode all user input returned as part of URLs (convert ?, &, /, <, >, and spaces to their
respective URL encoded equals).
HTMLEncode all user input returned as part of HTML.
Convert all user input to a single character encoding before parsing.
To prevent XSS vulnerabilities, you should URLEncode all user input that is returned as
Narration: part of URLs. This will convert ?, &, /, <, >, and spaces to their respective URL encoded
equals. Additionally, you should HTMLEncode all user input returned as part of HTML.
This will also convert special characters into their respective HTML encoded equals.
Last but not the least, you should convert all user input to a single character encoding
before parsing. This applies to Single/Double Hex Encoding, Unicode Encoding, and UTF8 Parsing.
15 / 57
07/01/2015
Broken Authentication and Session Management

Session Hijacking
Session hijacking is the alteration of session data to impersonate the session data of
another user, taking over the users session. Session hijacking can be done in several
ways:
Attacker intercepts the communication between the client and server and steals a valid
session ID.
Attacker tries to steal session information from the cookies stored in the users
computer.
Guess a predictable session ID.
The Web is inherently connectionless and stateless and developers rely on data sent to
Narration: the client and returned with each new request to track the users session. Improper
handling of such information can lead to an attack where an attacker alters session
data and impersonates the session data of another user, hijacking the users session.
After attackers know where this information is stored, they simply alter the information
in such a way that the server will view it as the valid session of another user whose
session is hijacked.
Session hijacking can be done in several ways. For example, an attacker can intercept
the communication between a client and a server and steals a valid session ID.
Alternatively, an attacker can try to steal session information from the cookies stored
on the users computer. Finally, if session IDs are predictable an attacker could guess a
valid one.
Preventing Session Hijacking
In order to prevent or mitigate Session hijacking:

Use secure random session IDs such as JSESSIONID.
Bind the session ID to another piece of identifying information, e.g. users IP address.
Expire sessions on logout and after a set period of inactivity.
To develop a secure application, you should restrict the instances of session hijacking by
Narration: following some simple guidelines.
Most Web frameworks provide us with secure random session IDs such as JSESSION ID.
You need to ensure that all other session data should be stored on the server side and
referenced with this JSESSION ID. Using a secure random ID will make guessing difficult
for an attacker and will not be able to guess another valid session ID.
An application developer should also bind the session ID to some other piece of
identifying information, such as the IP address of the user. This will make it more
difficult for an attacker to use a stolen, valid session ID.
As soon as a user logs out of a session, the session should expire. The session should also
expire after a set period of inactivity. This ensures that an attacker will not be able to
replay a valid session at a later stage.
16 / 57
07/01/2015
Example of Session Fixation

Lets observe an example where an attacker induces a client to establish a session with
Narration: the target software using a session identifier provided by the attacker.
Analysis indicates that the attacker either has used a malicious link or has leveraged on
an earlier attack, such as XSS.
As soon as user requests for a specified application with a valid session ID, the
application authenticates the user. However, the attacker already knows the same
session ID. Therefore, the attacker will now be able to use the session identifier for
their own transactions.
So what does this imply? The attack leverages the fact that the target software either
relies on client-generated session identifiers or maintains the same session identifiers
after privilege elevation.
How to prevent such instances? To prevent session hijacking it is important to invalidate
the unprivileged session ID and provide a new session ID after authentication. It is also
important to ensure correct logout, password management, and timeout functions to
help mitigate various instances of session fixation and hijacking.
17 / 57
07/01/2015
Insecure Direct Object Reference

Key Concepts of Insecure Direct Object Reference
Insecure Direct Object Reference occurs when a developer exposes a reference to an
internal implementation object.
Attackers can easily manipulate an Insecure Direct Object Reference to gain unauthorized
access to confidential objects and exploit them.
Avoid exposing direct references. If they must be used, perform an authorization check.
Insecure Direct Object Reference is a security vulnerability that occurs when a
Narration: developer accidentally or due to negligence happens to create a URL or form
parameter exposed to the user with a reference to an object, such as a file, directory,
database record, or a key, which is confidential to the organization.
Due to such an exposure, attackers can easily manipulate the reference and gain access
to other confidential objects and view or modify them.
The best protection is to avoid exposing direct object references to users by using an
index, indirect reference map, or another indirect method that is easy to validate. If a
direct object reference must be used, ensure that the user is authorized before using it.
Directory Traversals
Challenge: Request a filename from user

Problem: User may input correct filename
OR
May attempt to escape Application Directory by:
using / or \ to access root directory
using .. to access parent directory
manipulating symbolic links (i.e. shortcuts)
Directory traversals can happen when a Web application accepts a filename from the
Narration: user but doesnt validate that the filename does not allow the user to access
unintended locations in the file system.
18 / 57
07/01/2015
In order to prevent or mitigate directory traversal:

Examine code against a user-specified file
Always use Explicit paths
Define application-specific MYAPP_PATH
Use regular expressions to opt in known good paths
For example:
^[cd]:(?:\\\w+)+\\\w{1,32}\.(txt|jpg|gif)
To avoid directory traversal, you should examine application code against a userNarration: specified file. You should avoid relative or default paths. In addition, you should never
use the environment variable path for locating files because they can be changed and
cannot be relied upon. Therefore, you should always define explicit, application-specific
paths, such as MYAPP_PATH.
To do this, you can use a regular expression that will allow you to use the files present
on paths already known, verified, and secured by you. Note the sample expression
displayed on the screen. In this expression, the displayed path is alphanumeric, which
allows the application to accept txt, jpg, or gif files from the C or the D drive of the
server hosting the application.
19 / 57
07/01/2015
Cross-Site Request Forgery (CSRF)

Key Concepts of Cross-Site Request Forgery (CSRF)
CSRF is a malicious attack where the attacker exploits the users Web browser to execute
undesired actions on behalf of the user. These actions include:
Transferring funds
Changing passwords
Purchasing items using online shopping
Cross-Site Request Forgery (CSRF) is a malicious attack that tricks the users Web
Narration: browser to perform undesired actions so that they appear as if an authorized user is
performing those actions.
For example, if an attacker is able to modify the content viewed by a users browser,
perhaps with a hostile Web site, when the user is checking an online bank account, the
attacker can change the users transaction password to control the users actions and
transfer funds to the attackers account.
Executing CSRF Attacks
CSRF attackers use the functionalities of the victims browser against them.
When a user accesses a Web site and logs on to his account, the users credentials are
stored within the Web sites cookie.
The Web browser automatically associates the cookie with the actions the user performs
on the Web site.
Since the user was authenticated by the Web site, if an attacker exploits the CSRF
vulnerability at this stage, the Web application is not able to distinguish between a valid
action performed by the user or a malicious action initiated by an attacker.
To exploit CSRF vulnerability, the attacker uses the functionality of the victims Web
Narration: browser. When the victim is accessing a Web site using his login ID and password, the
victims credentials are automatically saved to the Web sites cookie. The Web browser
will always associate the user with this cookie whenever the user performs any action
on this Web site.
Since the user was authenticated by the Web site, if an attacker exploits the CSRF
vulnerability at this stage, the Web application is not able to distinguish between a valid
action performed by the user or a malicious action initiated by an attacker.
Preventing CSRF
20 / 57
07/01/2015
Preventing CSRF
The most common defense is to append challenge tokens to each request. These
challenge tokens must be associated with the users session.
Advantages of using challenge tokens are:
Attackers will not be able to provide a valid token of their own to utilize within the
attack.
Developers can ensure that the request is valid and not coming from a source other
than the user.
The most common method to prevent CSRF attacks is to append challenge tokens to
Narration: each request and associate them with the users session. By including a challenge token
with each request, the developer can ensure that the request is valid and not coming
from another source other than the user.
21 / 57
07/01/2015
After you deploy your Web application online,
it undoubtedly will encounter a number of
attacks. To prevent these attacks from being
successful, you need to follow sound
operational practices related to security.
Inadequate operational practices can lead to
security compromises using exploits of security
features or of known vulnerabilities. Improper
permissions may allow malicious users to
perform actions they shouldnt.
Misconfiguration Types
Missing patches: Patches, hotfixes, service
packs, and updates contain the latest security
fixes and need to be applied when they are
available.
Misconfigured or disabled security features:
If a security feature is disabled or not
configured, it cannot provide protection.
Default accounts: Default accounts may
allow a malicious user to automatically login
with the credentials published in product
documentation.
Unnecessary/unused services or features:
These represent an increased risk for security
problems. Bugs exist even in the best-written
code, By disabling or removing unused and
unnecessary services, code, and libraries, you
limit the amount of code that needs to be
maintained and patched. When in doubt, turn
features off, and turn them back on only if you
need them. Of course, verify all changes and
removals before putting them in production.
Administrative back doors: Administrative
back doors are known as front doors in the
hacking community. Its absolutely critical to
secure these administrative endpoints given
what they are: the keys to the kingdom. Do not
rely on a malicious user overlooking the
functionality; it can always be discovered.
Security through obscurity is no security at all.
Parts of the Stack Vulnerable to
Misconfiguration
OS
Environment/Platform
Web or Application Server
Database Server
Application(s)
Components and Libraries
Services
Narration: After you deploy your Web application online, it undoubtedly will encounter a number
of attacks. To prevent these attacks from being successful, you need to follow sound
operational practices related to security.
Inadequate operational practices can lead to security compromises using exploits of
security features or of known vulnerabilities. Improper permissions may allow malicious
users to perform actions they shouldnt.
A few misconfiguration types, such as missing patches, misconfigured or disabled
security features, default accounts, unnecessary or unused services or features, and
administrative backdoors, can render a Web application vulnerable to attacks.
These security misconfigurations can happen in any part of your system.
22 / 57
07/01/2015

The online world is a dynamic environment where
threats develop and manifest every single day. To
mitigate and maintain a secure environment, you
need a process that can quickly adapt to these
threats. A repeatable process is required to
constantly reevaluate the environment and
address new or growing threats, and should
include the following:
Updating the environment: This includes
changes like adding or removing network
segments, and changing configuration.
New products: New products or functionality
may be needed to deal with a threat that did not
exist when the application was released.
Service packs and patches: Use a regular process
to apply the latest service packs, patches, hotfixes,
and updates to all of your software, from top to
bottom.
In addition, your development, test, and staging
environments should precisely match the
production environment. If your environments
dont match, you might discover on release day
that your application doesnt work as expected.
For example, a Nasdaq breach in February of 2011,
after investigation by FBI and the secret service,
was narrowed down to unpatched Windows
systems and poor firewall configurations. While
the core trading systems most likely remained
intact, it could not be determined how much
proprietary and client information was stolen.
Unpatched systems could have been prevented by
Nasdaq avoiding downtime as a result of
investigations, loss of revenue and loss of
customer trust. Especially in this tough competitive
market, there is no reason to be faced with the
same issues as Nasdaq.
GlobalSign, a leading digital certificate provider,
was also breached late in 2011 as a result of an
unpatched piece of open source software.
Although fortunately the companies root
certificate that is used to sign other digital
certificates was not compromised, GlobalSign had
to halt certificate issuance for 9 days, face
additional audits and most importantly lost its
public trust due to the breach.
GlobalSign states that the particular open source
code was not on the list of software to be updated.
It is important to keep an accurate inventory of all
systems and software they run. You cannot protect
what you dont know you have.
Narration: Threats change constantly, and without processes that can adapt as quickly as the
threats, you cannot maintain a secure environment. A repeatable process is required to
constantly reevaluate the environment and address new or growing threats.
The process should include updating the environment with changes like adding or
removing network segments and changing configuration.
You may need to deploy new products or functionality to deal with a threat that did not
exist when the application was released. In addition, you should have a regular process
to apply the latest service packs, patches, hotfixes, and updates to all of your software,
from top to bottom.
In addition, your development, test, and staging environments should precisely match
the production environment.
For example, a Nasdaq breach in February of 2011, after investigation by FBI and the
secret service, was narrowed down to unpatched Windows systems and poor firewall
configurations. While the core trading systems most likely remained intact, it could not
be determined how much proprietary and client information was stolen. Unpatched
systems could have been prevented by Nasdaq avoiding downtime as a result of
investigations, loss of revenue and loss of customer trust. Especially in this tough
competitive market, there is no reason to be faced with the same issues as Nasdaq.
GlobalSign, a leading digital certificate provider, was also breached late in 2011 as a
result of an unpatched piece of open source software. Although fortunately the
companies root certificate that is used to sign other digital certificates was not
compromised, GlobalSign had to halt certificate issuance for 9 days, face additional
audits and most importantly lost its public trust due to the breach.
GlobalSign states that the particular open source code was not on the list of software to
be updated. It is important to keep an accurate inventory of all systems and software
they run. You cannot protect what you dont know you have.

23 / 57
07/01/2015

A well-defined process provides your first line of
protection against a dynamic threat environment. A
regular, repeatable hardening process is required to
make sure your environment is protected against the
latest threats.
Keep the following in mind as you create and
implement your process:
Research all stack components for potential
vulnerabilities
Vendor/project sites
http://www.symantec.com/security_response/
Symantec
Security Response Summarizes the current state of
active
threats and vulnerabilities in popular software
http://nvd.nist.gov/ National Vulnerability Database
is a
comprehensive list of vulnerabilities
Security sites
http://www.securityfocus.com/ Site with security
news and
vulnerabilities. They also host the popular BugTraq
mailing
list
http://www.us-cert.gov US Government Site focused
on
improving the nations cyber-security infrastructure
http://www.securitywizardry.com/radar.htm A nice
graphical
summary screen of the current state of cyber-threat
activity
Security mailing lists/aliases
BugTraq While it can be a chatty list, it provides
insite on
hot of the press discovered vulnerabilities.CISSPForum
For Security professionals discusses current issues

effecting the state of cyber Security
Search for any additional information
Review all settings and configurations
Pay close attention to security features
Look for standard recommendations for secure
configurations of
your platforms and applications from their vendors,
standards
organizations, and security organizations
Review all enabled features
Disable any unnecessary features
Repeat the process:
At regular intervals; monthly, bimonthly
Every time a deployment or configuration changes
Narration: A well-defined process provides your first line of protection against a dynamic threat
environment. A regular, repeatable hardening process is required to make sure your
environment is protected against the latest threats.
Research each component of your application stack, and subscribe to security and
patch bulletin mailing lists and news groups where updates are announced. Use the
information discovered in your research to apply updates or configure your system to
mitigate new, unpatched vulnerabilities.
Next, you should review and document all settings and configurations, paying close
attention to security features. Make sure you document any changes.
Finally, repeat the process at regular intervals, and every time a deployment or
configuration changes.
Remember to frequently review all enabled features, even though you did this when
you deployed the product. Installers often turn on features you dont need, and service
packs and even administrators may enable feature youre not aware of.
24 / 57
07/01/2015
Insecure Cryptographic Storage
25 / 57
07/01/2015
Poorly Implemented Cryptography
26 / 57
07/01/2015
Failure to Restrict URL Access
27 / 57
07/01/2015
Insufficient Transport Layer Protection

Secure Sockets Layer and Transport Layer Security (SSL and TLS)
SSL and TLS are commonly used to secure the channel between a browser and a Web
server.
It is application independent.
It allows protocols like HTTP, FTP, and Telnet to be layered transparently on top of it.
SSL supports a variety of cryptographic algorithms.
SSL/TLS is commonly used to secure the channel between a browser and a Web server.
Narration: It is application independent and allows protocols like HTTP, FTP, and Telnet to be
layered transparently on top of it.
SSL supports a variety of cryptographic algorithms. For example, during the
"handshaking" process, it uses the RSA public-key cryptosystem, and after the keys are
exchanged, it uses a number of ciphers including RC2, RC4, IDEA, DES, and triple-DES.
Internet Protocol Security (IPSec)
IPSec provides a transport level secure communication solution that can be used to secure
the data sent between two computers.
It is mostly used in Virtual Private Networks (VPNs).
It ensures confidentiality and authentication of all network traffic at the IP level.
Other features of IPSec are as follows:
It can provide some security services in the background with no impact on user or the
developer.
It does not provide user-level authentication.
It uses the philosophy that only the OS configuration needs to change and not
individual applications.
IPSec, which is mostly used in Virtual Private Networks (VPNs), provides a transport
Narration: level secure communication solution that can be used to secure the data sent between
two computers. It ensures confidentiality and authentication of all network traffic at
the IP level.
Another benefit of IPSec is that it can provide some security services in the background
with no impact on user or the developer. Also, it does not provide user-level
authentication and uses the philosophy that only the OS configuration needs to change
and not the individual applications.
28 / 57
07/01/2015

Unvalidated forwards
can allow a malicious
user to spoof your site.
The malicious user
provides the victim with
what looks like a link to
your site but actually
redirects the victim to a
malicious location.
Many authentication
systems use redirection
to return a requester to
an authorized URL after
login, so the user may
not notice that the site
is incorrect.
To protect an
application against
unvalidated redirects
and forwards, you need
to validate the input as
well as the referrer
header, which can be
controlled or
manipulated by a
malicious user.
Results
Unvalidated redirects
and forwards can result
in the following
consequences:
Complete spoof of
your site. A phishing
attack could redirect the
client to a malicious
Web site. A malicious
user can also use
redirects in combination
with a CSRF attack. For
example, if the
vulnerable action checks
the referrer to validate
that it comes from your
vulnerable site, the
unvalidated forward
makes the mitigation
insufficient.
Bypassed
authorization checks. In
most common Web
platforms, an API call
exists that directly
transfers a client to
another location,
bypassing authorization
checks. If such an API is
used to implement an
unvalidated redirector,
a malicious user simply
needs to use the
redirect as the entry
point to all other
resources on the site.
Narration: A URL that redirects you from its location to another is called a redirect or a forward.
Authentication systems often use redirects to transparently inject authentication into
an unauthenticated request for a protected resource. Redirects are also used to record
an action. For example, links to a third-party site for advertisements often use a
redirect to record that a client clicked an advertisement.
If a URL uses a parameter to indicate the redirect destination for the client, and the
input is not validated, the site is subject to unvalidated redirects and forwards. Like all
evil input threats, the key to protecting an application against unvalidated redirects
and forwards is to validate the malicious input. You must also validate the referrer
header.
Unvalidated redirects and forwards can result in a complete spoof of your site. A
phishing attack could provide a valid link to your Web site in an e-mail message. But the
link actually redirects the client to a malicious Web site. A malicious user can also use
redirects in combination with a CSRF attack. For example, if the vulnerable action
checks the referrer to validate that it comes from your vulnerable site, the unvalidated
forward makes the mitigation insufficient.
Malicious users may also be able to bypass authorization checks. In most common Web
platforms, an API call exists that directly transfers a client to another location,
bypassing authorization checks. If such an API is used to implement an unvalidated
redirector, a malicious user simply needs to use the redirect as the entry point to all
other resources on the site.
29 / 57
07/01/2015
Mitigating Unvalidated Redirects and Forwards

To mitigate unvalidated redirects and forwards, use
the following guidelines:
Never use internal transfer without authorizing the
user for the target URL. In general, it is far easier to use
a redirect method, which will issue a 302 response to
the client and ask the client to make another request
for the target URL. At that point, it will be like any
other request for the target.
Wherever possible, restrict the usage of your
forward functionality to some set of authorized users,
instead of all unauthorized users.
Use weblogs to identify potential code. Look for
HTTP status codes in the 300 series: 301, 302, 303, and
307.
Where possible, do not use redirect, or redirect to
static locations.
When redirecting to a parameter, validate the
parameter to make sure that it is an expected redirect.
Use table indirection where possible to turn a dynamic
set of potential choices into a table of valid keys. At
the very least, allow only relative redirects.
Narration: To help protect against unvalidated redirects, never use internal transfer methods
without first authorizing the client to the target URL. In general, it is far easier to use a
redirect method, which will issue a 302 response to the client and ask the client to
make another request for the target URL. At that point, it will be like any other request
for the target.
Wherever possible, restrict the usage of your forward functionality to some set of
authorized users, instead of all unauthorized users. Sometimes the hardest part of
mitigating unvalidated redirects and forwards is finding them. Scanning the Web logs
can be very helpful to finding this code. Look for HTTP status codes in the 300 series:
301, 302, 303, and 307.
Avoid redirects altogether, or redirect to a static location or a static set of locations
wherever possible. When redirecting to a parameter, validate the parameter to make
sure that it is an expected redirect.
Use table indirection to turn a dynamic set of potential choices into a table of valid keys.
Limit your forward to pass control of another page in your own Web site.
30 / 57
07/01/2015

If you have a potential set of valid locations that the
client is allowed to redirect to, consider using table
indirection. Maintain a table of allowed URIs, and then
allow the client to specify the keys into the table only
and not the actual URI itself.
When the key is returned, look up the URI in the table
and then redirect to that location.
In the following URL, the color blue indicates user
input, and the color grey is the unencoded value of the
redirect parameter.
/Login.aspx?
redirect=%2fAccount%3Fid%3d1234(/Account?id=1234)
becomes
/Login.aspx?redirectKey=13m1=1234
Even if your system requires additional data to be sent
to the location, the table indirection can still be
successful. Simply take the additional parameter and
combine it with the URI value from the table. Be careful
of any type of injection attack here; even though you
are restricting the malicious user, you still need to
validate the data in param1.
Narration: You can use the table indirection technique to mitigate unvalidated redirects and
forwards. If you have a set of valid locations that the client is allowed to redirect to,
consider using table indirection. Keep a table of the allowed URIs, and then allow the
client to specify the keys into the table only and not the actual URI itself. When the key
is returned, look up the URI in the table and then redirect to that location.
In the example on the screen, a redirection scheme for logging that takes a relative
path directly becomes a system that uses a redirect key instead. The key value will
either exist in the table or it wont, and a malicious user has little control over the
redirect destination.
31 / 57
07/01/2015

This concludes the current OWASP Top 10 list, which was released in 2010. The previous list
released in 2007 included two additional threats that were replaced by security
misconfiguration and unvalidated redirects and forwards. These threats, while no longer
included in the current top 10 list, are still important. They are:
Narration: This concludes the current OWASP Top 10 list, which was released in 2010. The previous
list released in 2007 included two additional threats that were replaced by security
misconfiguration and unvalidated redirects and forwards. These threats, while no
longer included in the current top 10 list, are still important. They are malicious file
execution and information leakage and improper error handling.
We will look at these threats in detail in the next section.
Malware
Malware can be spread as file uploads or file attachments.

Malware is a malicious program that shouldnt be executing on a system.
A Worm is a self-propagating program.
A Virus requires user action such as copying files to propagate.
A Trojan Horse purports to be a benign or helpful program but harbors malicious
behavior.
A Time Bomb may perform a malicious action after a predetermined date or time is
reached
Malware is one of the most common malicious attacks that can be used for breaching
Narration: application security. Attackers having access to upload or attach arbitrary files can
spread malware from their computers to trusted systems. Then, remote or local users
of the application may inadvertently execute these files. There are three major types of
malwares Worm, Virus, and Trojan Horse.
A Worm is a self-propagating program that takes advantage of either a vulnerability in
an operating system or a common software to breach a system and start executing
malicious codes in the system. The Worm doesnt stop here, it then searches for other
systems with some vulnerability and repeats the process to spread itself. Worms can
spread quickly and pose a major risk to a vulnerable network.
A Virus attaches them to an executable file infecting the file. When the infected file is
moved to another system and executed, other files on that system become infected
with the virus. A virus uses system resources and other programs to reproduce itself.
A Trojan Horse is named after the famous Trojan Horse in Greek mythology. A Trojan
Horse purports to be a beneficial program. However, it harbors malicious functionality
such as a keystroke logger for capturing passwords or remote access that will allow an
attacker to attack and control a system. Users are tricked into installing the malware,
which is often disguised as a browser toolbar, a media player, a video codec, or an
electronic greeting card.
32 / 57
07/01/2015

When user input is used to open files or execute commands, there is an opportunity for
malicious code execution.
Guidelines for Preventing Malicious Code Execution
Never expose file identifiers to user input.
Never use unfiltered user input to craft a filename or an OS exec input.
Dont allow user input to create server-side script or include files.
Malicious code execution can be prevented by following some guidelines. You should
Narration: never expose file identifiers to a user such that they become part of user input and can
be easily modified by them. Exposing file identifiers can also cause information leakage
by allowing the user select the filename opened by the application. Moreover, if the
application executes commands or scripts contained in the file, this can lead to the
more serious malicious code execution.
Suppose user input is part of an OS shell or an exec command. Then the user can specify
commands to execute. Therefore, you should always filter user input going into
system(), StartProcess(), java.lang.Runtime.exec(), System.Diagnostics.Process.Start()
or similar APIs.
Another malicious code execution is an include file injection. An include file injection
occurs when the user is able to specify a filename as input that gets included into a
running script under PHP. Script injection occurs when the user is able to specify input
that is interpreted by the server-side scripting engine in PHP or ASP.
33 / 57
07/01/2015

Information Leakage
Disclosing information in error messages is often
done because it helps normal users to fix errors
and help developers fix various problems.
Examples of error messages that are likely to
disclose information are ODBC error messages,
authentication error messages, and others.
Improper Error Handling
Improper error handling can provide information
that can be used for attacking a system. For
example, error messages such as:
Running V4.1 with X module, can provide
Application/platform identification information.
Error encountered at line 123 in file
this_is_a_weak_app.asp can provide application
implementation details.
Invalid password supplied for user id xxxxx.
can disclose accurate user ids.
Disclosing information in error messages is often done because it helps normal users to
Narration: fix errors and help developers fix various problems. Examples of error messages that are
likely to disclose information are ODBC error messages, authentication error messages,
and others.
Applications should handle error messages with a lot of restrictions. Improper error
handling can provide information that can be used for attacking a system. For example,
error messages should avoid application/platform identification information,
implementation details, and information related to data quality.
Preventing Information Leakage and Improper Error Handling

Determine in advance:
What is reasonable and can be disclosed.
What is not to be disclosed.
Think from an attackers perspective.
Use a standard error response for all sensitive data
errors. Such as An error has occurred while
accessing the database.
To prevent information leakage, one must segregate information based on some preNarration: defined criteria. You should determine in advance about which information is safe for
disclosure and which information needs protection.
The best way to determine the level of information confidentiality is by thinking from an
attackers perspective and determining what the attacker can do with the information.
Even while developing error-handling messages for an application you should use a
standard error response for all sensitive data errors. Just mention the macro problem,
such as An error has occurred accessing the database.
34 / 57
07/01/2015
Module Summary
Understand
OWASP and
its
importance
Understand OWASP and its importance

A popular trend, which started originally with the SANS Institute, is for
organizations to publish annual Top 10 lists of each years most common
security vulnerabilities. Since 2003, the Open Web Application Security
Project (OWASP.org) took over this task. The OWASP is a worldwide free
and open community focused on improving the security of application
software that is focused on developing an open source Web application
security community.
Name each of
the OWASP
top 10
vulnerabilities
Name each of the OWASP top 10 vulnerabilities

The OWASP Top 10 Security Flaws are Injection, Cross-Site Scripting (XSS),
Broken Authentication and Session Management, Insecure Direct Object
References, Cross-Site Request Forgery (CSRF), Security Misconfiguration,
Insecure Cryptographic Storage, Failure to Restrict URL Access,
Insufficient Transport Layer Protection, and Unvalidated Redirects and
Forwards.
Understand
the basics of
the
vulnerabilities
and their
impact
Understand the basics of the vulnerabilities and their impact

SQL injection is a software vulnerability that occurs when data entered by
users is sent to the SQL interpreter as a part of an SQL query. SQL injection
exploits security vulnerabilities at the database layer.
By exploiting the SQL injection flaw, attackers can create, read, modify, or
delete sensitive data.
Cross-site scripting (XSS) is a Web-based security vulnerability in which a
user instead of a Web application is attacked. During such an attack, a
vulnerable Web application is hacked to deliver malicious content to
users via script. This content can include HTML or JavaScript code and
appear as a persistent, a reflective or non-persistent, or a DOM-based
attack.
The Web is inherently connectionless and stateless and developers rely
on data sent to the client and returned with each new request to track the
users session. Improper handling of such information can lead to an
attack where an attacker alters session data and impersonates the session
data of another user, hijacking the users session. After attackers know
where this information is stored, they simply alter the information in
such a way that the server will view it as the valid session of another user
whose session is hijacked.
Insecure Direct Object Reference is a security vulnerability that occurs
when a developer accidentally or due to negligence happens to create a
URL or form parameter with a reference to an object, such as a file,
directory, database record, or a key, which is confidential to the
organization.
CSRF is a malicious attack where the attacker exploits the users Web
browser to execute undesired actions on behalf of the user. These
actions include transferring funds, changing passwords, and purchasing
items using online shopping.
Inadequate operational practices can lead to security compromises using
exploits of security features or of known vulnerabilities. Improper
permissions may allow malicious users to perform actions that they
shouldnt. A few misconfiguration types, such as missing patches,
misconfigured or disabled security features, default accounts,
35 / 57
07/01/2015
unnecessary or unused services or features, and administrative

backdoors, can render a Web application vulnerable to attacks.
Insecure storage is also a common vulnerability. Trusted users within the
organization network can steal unencrypted sensitive data in temporary,
hidden, and registry files. Attackers that exploit another OWASP Top 10
vulnerability can also steal this data. To avoid, this you follow steps such
as encrypting sensitive data, ensuring that encrypted data cannot be
overwritten, and keeping secrets from even trusted employees.
Although, cryptography is an effective way of protecting data, it can be
used incorrectly. Developers select inappropriate ciphers or weak
algorithms such as MD5, SHA-1, and RC3 to encrypt data.
Attackers can also use a technique called forced browsing to bypass Web
site security and access data source files and source code directly. To
prevent forced browsing, you should use ACLs, remove unnecessary files
from Web accessible directories, use virtual directories for Web access
and separate secure directories data, and define the list of file types
available for remote reading.
Sensitive data can also be leaked when applications transmit it across
networks. To ensure security during the communication of sensitive data,
you should secure the channel between communication end points using
technologies such as SSL/TLS and IPSec.
Unvalidated forwards can allow a malicious user to spoof your site. The
malicious user provides the victim with what looks like a link to your site
but actually redirects the victim to a malicious location. Many
authentication systems use redirection to return a requester to an
authorized URL after login, so the user may not notice that the site is
incorrect.
The two threats from the 2007 OWASP Top 10 list are malicious file
execution and information leakage and improper error handling.
Code vulnerable to remote file inclusion (RFI) allows attackers to include
hostile code and data, resulting in devastating attacks, such as total server
compromise. Malicious file execution attacks affect PHP, XML, and any
framework that accepts filenames or files from users.
Disclosing information in error messages is often done because it helps
normal users to fix errors and help developers fix various problems.
Applications should handle error messages with a lot of restrictions.
Improper error handling can provide information that can be used for
attacking a system. To prevent information leakage one must segregate
information based on some pre-defined criteria. You should determine in
advance about which information is safe for disclosure and which
information needs protection.
36 / 57
07/01/2015
Security Principles
Security Principles
Module Overview
This module will help you understand key security principles and
recognize the importance of incorporating these principles within
your software development lifecycle.
Module Objectives
Understand and incorporate key security principles.
Define Layered Security / Defense in Depth.
Define segmentation.
Define structural security.
This module will help you understand key security principles and the importance of
Narration: incorporating these principles within your software development lifecycle. The module will first
introduce you to incorporating security into your software development process. Then, it will
introduce defense in depth as a strategy to protect information technology resources and
data. This module will further describe different ways to segment data, the importance of
structural security in an organization, and various principles of information security. Finally, the
module will help you recognize the need to test for security vulnerabilities.
Structural Security
Structural security is security that has been baked into the very foundation of an applications
architecture.
Apply simple, structural security, whenever possible.
General examples include concrete building material.
Technical examples include a hardened server or an environment with unused features and
services removed.
Structural security is the very foundation of an applications architecture. For example, using
Narration: concrete as a building material gives a structural security benefit against the threat of fire.
Another example might be including only one entrance or exit in an airport parking lot to
monitor cars. Often, incorporating structural security makes an application simpler and easier
to maintain albeit sometimes at the expense of features.
One good example of employing structural security in software is turning off unused services
and removing unnecessary files from a host operating system. This minimizes the attack
surface and exposes less functionality that may be attacked.
37 / 57
07/01/2015
To help maintain security, all entities (people, processes, devices) should be assigned the
fewest privileges consistent with their assigned duties and functions.
Definition
Each user, program, and program component operates using the fewest privileges required for
proper functionality.
Rationale
Limits damage from an accident, an error, or an attack.
Reduces interactions among privileged programs.
Limits successful attackers to only assume the authority associated with the compromised
account.
Examples
Users get only the privileges they require to do their job.
Administrators only login with admin privileges when they absolutely need it.
Applications only open files with the specific permissions that are required.
A basic principle in information security says that entities, such as people, processes, and
Narration: devices, should be assigned the fewest privileges consistent with their assigned duties and
functions. For example, the restrictive "need-to-know" approach denies access to all resources
by default, then explicitly grants privileges as they are needed. Applying this principle to a
corporate network would result in all data being off-limits except to specific users or groups.
In contrast, a less-restrictive strategy opens all systems and closes access as required. For
example, allowing employees access to all systems except human resources and accounting,
which is limited to employees in those departments. This is not an ideal approach as it requires
the blacklist to be regularly updated any time new users are added, otherwise those users may
be implicitly granted access that they should not have.
Abiding by the principle of least privilege limits the damage from an accident, an error, or an
attack and reduces interactions among privileged programs. Successful attackers can only
assume the authority associated with the compromised account.
Some common examples of least privilege include giving users only the privileges they require
to do their job, implementing a policy that requires administrators to only log in with admin
privileges when they absolutely need it, and allowing applications to only open files that
contain the required permissions.
Test Everything
It is important to perform security testing to catch improper design and coding practices that may
have been missed earlier in your development process:
Never assume that security controls are effective until you can validate them with thorough
testing.
Most security vulnerabilities will not be discovered during normal application use.
Allocate time for dedicated security testing within your project timeline.
Always test applications and application components, both in isolation and in the environment
where the application is deployed.
Since many vulnerabilities are caused by mistaken assumptions by programmers or by mistakes
Narration: in the code, it is important to test all code for security vulnerabilities. An application or
application component should not be assumed to be secure until security controls have been
thoroughly tested.
Typical application use cases or traditional feature testing will not find most security
vulnerabilities. Security testing must be performed in order to find security vulnerabilities, so it
is important to allocate dedicated time for security testing during the testing phase of the
software development cycle.
It is important to test for security vulnerabilities both in isolation and in the environment the
application is designed to run in. It is common for a security vulnerability to be exploitable only
when the application is interacting with the operating system and other backend services.
Module Summary
38 / 57
07/01/2015
Module Summary
Understand
and
incorporate
key security
principles
Understand and incorporate key security principles

Security is a process of protecting information. So security principles
should be incorporated within the software development lifecycle from
the very beginning of the project. Incorporating these principles, early
within the development lifecycle, dramatically improves the security of
your application.
Key security principles are least privilege, default deny, and input or data
validation. The least privilege principle says that entities (people,
processes, devices) should be assigned the fewest privileges consistent
with their assigned duties and functions.
The default deny principle states that access to resources and all
application input should be denied unless specifically permitted.
Use input and data validation to help prevent attacks based upon
maliciously malformed data sent to your application over the Internet,
through its UI, through corrupted files, or any other input stream your
application can accept.
Define
Layered
Security /
Defense in
Depth
Define Layered Security / Defense in Depth

Layered Security, or Defense in Depth, is the strategy of using several
concurrent methods, such as point security solutions, filtering systems,
and monitoring strategies, to protect information technology resources
and data.
It addresses security vulnerabilities in personnel, technology, and
operations for the duration of the systems lifecycle. Layered security
makes it more difficult and time consuming for an attacker to mount an
attack and limits what the attacker can access with each successful
penetration.
Define
segmentation
Define segmentation
Segmentation is the practice of separating data from logic, segmenting
data by privilege, and segmenting applications from environment to
improve security. A common example of segmenting data from logic is
housing data in a database on a non-publicly accessible system and
configuring the Web root of your Web server on a partition separate from
the operating system installation.
The other way of segmenting data is by privilege. Segmenting data by
privilege separates data by the authorization level required to access it.
Database tables, Web folders, and configuration files are potential areas
where privilege based segmentation could be applied.
An application can also be segmented from its environment. This confines
the application to a safe space where its access to system resources is
tightly constrained.
Define
structural
security
Define structural security

Structural security is the very foundation of an applications architecture.
For example, using concrete as a building material gives a structural
39 / 57
07/01/2015
security benefit against the threat of building collapse. Another example

might be of including only one entrance or exit in an airport parking lot to
monitor cars. Often, incorporating structural security makes an application
simpler and easier to maintain albeit sometimes at the expense of
features.
One good example of employing structural security is turning off unused
services and removing unnecessary files from a host operating system.
This minimizes the attack surface and exposes less functionality that may
be attacked.
40 / 57
07/01/2015

Module Overview
Information assets and security go hand in hand. An organizations
information assets are subject to security threats. Therefore, every
organizations goal is to employ the best security system to protect
their information assets from such threats. To develop secure
systems, organizations need to define security goals and controls.
Module Objectives
Explain the importance of the CIA triad.
Explain the purpose of authentication and authorization.
Explain the importance of error and exception handling.
Explain the purpose of monitoring and logging.
Explain the purpose of cryptography and encryption.
Describe database authentication and controls.
Often, an organizations information assets are subject to security threats. Therefore, every
Narration: organizations goal is to employ the best secure systems to protect their assets from these
threats.
An important step in developing security systems is to define security goals and controls.
This module will help you recognize the main security goals and features that you might
require while developing a secure system. This module will first explain the importance of the
security goals of confidentiality, integrity, and availability. The module will go on to explain the
purpose of authentication, authorization, and access controls. Finally, the module will provide
information about the purpose of error and exception handling, monitoring and logging,
cryptography and encryption, and database security.
Authentication
Authentication
The authentication process verifies the identity of an entity. The entity could be a
computer or a computer user. Trust is established based on the quality of your
authentication implementation and the strength of the entity-provided credentials.
Common authentication mechanisms include:
Passwords
X.509 Certificates
Kerberos Tickets
Smart Cards
Tokens
Biometrics
Forming goals is not enough to ensure software security. You also need to have various
Narration: technical controls to manage security threats. That is why authentication,
authorization, and access control are present in many types of applications.
Authentication verifies the identity of a computer or a computer user. Commonly, the
authentication process involves entering and verifying a username and a password.
However, authentication can also include other methods of identity verification such as
smart cards, retina scans, voice recognition, or fingerprints.
There are different types of authentication such as basic authentication, digest
authentication, form-based authentication, smart card, biometrics, and digital
certificates. Trusting a particular authentication method is based on the quality of
implementation and the strength of credentials.
41 / 57
07/01/2015
Any authentication method could have weaknesses.
Authentication mechanisms are often the first target of an attack.
Implementing Authentication
Use two-factor authentication for added security.
Define and test all authentication information for valid format and length.
All authentication methods have weaknesses and can be breached because of poor
Narration: implementation. Security vulnerabilities can occur in implementations that include passwords,
certificates, or even biometrics.
The authentication process is often attacked first because even an unauthenticated user can
access the login page of your application.
To strengthen the authentication process, you can use two-factor authentication. Two-factor
authentication provides added security by simultaneously using two different factors to verify
users. In two-factor authentication, a user must know something unique and posses something
unique. For example, knowing a password and possessing a hard token to login to a system.
Authorization
42 / 57
07/01/2015
Authorization
The authorization process:

Determines and grants rights to an authenticated entity.
Often uses Access Control Lists (ACLs) for resource-based authorization.
May use LDAP servers to store information about user roles and privilege levels.
Common authorization techniques are:
Resource-based authorization, such as Access Control Lists (ACLs).
Role-based authorization, such as LDAP or Active Directory.
Authorization is the process of determining the rights that should be granted to an
Narration: authenticated entity.
After the identity of a user is authenticated, an application authorizes a user to perform
actions in the system based upon the permissions associated with the authenticated identity or
the permissions of the group or role that the identity belongs to.
Authorization can also be performed on specific resources, such as a database or a file on the
file system. Access Control Lists (ACLs) are a common mechanism by which resource-based
authorization is performed on the Windows operating system.
Authorization is similar to checking the guest list at an exclusive party or checking your opera
ticket. In these cases, the security personnel verify the guests name against the guest list. In
this analogy, authentication is checking the ID and authorization is checking that name against
the list of allowed guests.
Similarly, authorization is often achieved via Access Control Lists (ACLs). You can grant or deny
access based on a wide variety of criteria, such as the network address of the client or the time
of day.
Access control permits and restricts user entry. It behaves like a gate that closes after a
stipulated time or a gate that only allows employees to enter the premises of an organization.
43 / 57
07/01/2015
Use access controls to structurally harden your environment. Keep in mind that thoughtful
segmentation will facilitate authorization.
Use the principle of least privilege and grant each entity the minimum privileges required
for proper business functionality.
Scrutinize integration with other components. Define responsibility and examine
implementation carefully.
Ask yourself, What type of access does my application need?
Log files
Configuration files
Database tables
Access controls help you structurally strengthen your environment. By appropriately
Narration: setting access control permissions on your resources, you can reduce the amount of
damage an attacker can inflict when exploiting a vulnerability.
Use access controls to structurally harden your environment. Thoughtful segmentation
will facilitate authorization.
Use access controls to implement the principle of least privilege. The principle of least
privilege states that you should grant the minimum privileges to the users and roles in
your application so that they can accomplish appropriate tasks but are not allowed to
do any more. For instance, you may lock down the account that accesses your database
so that it only has permissions to read from specific tables rather than have the ability
to read, write, and delete any table in the database. If an attacker is able to exploit a
vulnerability, such as SQL injection, on your application, access controls on the database
will limit the amount of damage that is possible.
Scrutinize integration with other components. Define responsibilities and examine
implementation carefully.
Before designing access controls, analyze the type of access required by each of the
roles in your applications.
44 / 57
07/01/2015
Module Summary
Explain the
importance of
the CIA triad
Explain the importance of the CIA triad

Information security is the principal of software applications maintaining
security goals while handling information. Confidentiality, integrity, and
availability are the goals of information security.
Confidentiality refers to the privacy of an information asset. The key to
integrity is protecting data from modification or deletion by
unauthorized parties, and ensuring that when authorized people make
changes that shouldnt have been made the damage can be undone.
Availability of information means the systems responsible for
delivering, storing, and processing information are accessible when
needed.
Explain the
purpose of
authentication
and
authorization
Explain the purpose of authentication and authorization

Various technical controls allow you to manage your security threats. The
three techniques authentication, authorization, and access control are
generally present in all applications.
The authentication process verifies the identity of a computer or a
computer user. This process usually involves a username and a
password. Authorization and access controls are the processes of
determining the rights that should be granted to an authenticated entity.
Click each objective to learn more about it.
Explain the
importance of
error and
exception
handling
Explain the importance of error and exception handling

Error messages are the potential avenues by which too much
information is disclosed to a user or a malicious individual. Inadvertently
disclosing internal application details in error messages, provides an
opportunity to the attacker.
Explain the
purpose of
monitoring
and logging
Explain the purpose of monitoring and logging

Monitoring and logging is the process of capturing and retaining
events. While logging, you record data on application or system activity.
Explain the
purpose of
cryptography
and
encryption
Explain the purpose of cryptography and encryption

Cryptography disguises messages so that only certain people can identify
the actual message. Cryptography is a technological solution for
protecting transit data from sniffing and alteration. Cryptography is a
predefined procedure to convert plaintext into ciphertext that uses
encryption for disguising information.
Describe
database
authentication
and controls
Describe database authentication and controls

Database controls are used to limit what attackers can do. Database
45 / 57
and controls
07/01/2015
controls include logging, denying access to stored procedures, and

running the database as a low privileged user.
46 / 57
07/01/2015

Module Overview
This module will help you understand the root causes of software
vulnerabilities and recognize that the cost of fixing these
vulnerabilities increases dramatically in later stages of the
development lifecycle. You will then be presented with the
advantages of following a holistic approach that tackles security at
every stage of the software lifecycle. This module will present you
with a set of generic security activities that can be performed
within your development process to help you, as an organization,
reduce your software security risk and produce more secure
software.
Module Objectives
Identify the root causes of software vulnerabilities.
Recognize that the cost of fixing vulnerabilities increases over
time.
Comprehend activities that reduce software security risk.
In this module, you will be first introduced to the causes of software vulnerabilities and the
Narration: importance of integrating security in the software development lifecycle. Then, this module
will present you with a set of generic security activities and best practices that can be followed
to help your organization effectively reduce its software security risk.
47 / 57
07/01/2015

As it marks the beginning of the development effort, the
requirements phase is the most appropriate stage to kickoff
and setup your security development process.
During the requirements phase, you should:
Assign a security advisor, either internal to your
organization, if available, or from a third-party organization.
The security advisor needs to be a software security expert
and will be the one validating security activities and
deliverables.
Assign security leads to the different teams involved in
the process, such as the development and testing teams.
The responsibility of these security leads will be to drive
security efforts within their team.
Establish a security bug bar specifying clear-cut security
shipping requirements such as ALL vulnerabilities allowing
an attacker to access stored or transmitted credit card
numbers MUST be remediated before release.
Gather security requirements applicable to your software
project such as any security standards or regulations it might
be subject to including PCI DSS, HIPAA, SOX, GLBA, and Basel
II.
Identify, acquire, and configure any software security
tools needed later in the project, such as configuring your
bug tracking system to track security vulnerabilities.
Initiate risk assessment to determine quantitative or
qualitative value of the risks associated with your software
project. Perform an objective evaluation of risks in which
assumptions and uncertainties are clearly considered and
presented.
A software development lifecycle produces security deliverables at each phase. The
Narration: requirements phase is the most appropriate stage to begin your security development process.
During this phase, you should:
Assign a security advisor who can be someone from your organization or even from a thirdparty organization. The security advisor needs to be a software security expert and will be the
one validating security activities and deliverables.
Assign security leads to the different teams involved in the process. This includes the
development and testing teams who will drive security efforts within their team.
Establish a security bug bar clearly indicating the security shipping requirements. For example,
ALL vulnerabilities allowing an attacker to access stored or transmitted credit card numbers
MUST be remediated before release.
Gather security requirements applicable to your software project such as any security
standards or regulations it might be subject to including PCI DSS, HIPAA, SOX, GLBA, and Basel
II.
Identify, acquire, and configure any software security tools needed later in the project, for
example, configuring your bug tracking system to track security vulnerabilities.
Initiate risk assessment to determine quantitative or qualitative value of risk associated with
your software project. An objective evaluation of risk in which assumptions and uncertainties
are clearly considered and presented can be performed.
48 / 57
07/01/2015
Properly categorizing threats will enable you to identify effective countermeasures to be
integrated in your softwares design. A popular method for categorizing threats is the STRIDE
approach. STRIDE was developed by Microsoft to classify threats identified while threat
modeling. Each type of threat in STRIDE maps to a security property that each software should
have to defend against the threat.
The provided table defines these threat types and security properties to help you understand
how they relate to each other.
Threat
Security Property
Spoofing Identity
The action of assuming the
identity of another user,
component, or system.
Authentication
The ability of a system to verify the identity of a user,
component, or system.
Tampering with Data

The action of illegally
modifying data.
Integrity
The property of data that has not changed. Note: a
system can take two approaches to ensure integrity:
enforcing proper access control or tamper-detection.
Repudiation
The act of denying being the
author of a given action.
Non-repudiation
The ability of a system to ensure that all actions are
accounted for and can be traced back to their authors.
Information Disclosure
The action of viewing
confidential data without
proper authorization.
Confidentiality
The property of data that is not viewed by unauthorized
parties.
Denial of Service
The act of preventing a system
from functioning in accordance
with its intended purpose.
Availability
The property of data that is accessible to legitimate
parties whenever they need it to be.
Threats can be categorized based on the goals and purposes of the attacks. Properly
Narration: categorizing threats will enable you to identify effective countermeasures to be integrated in
your softwares design. STRIDE is the most common method used for categorizing threats. This
method was developed by Microsoft to classify threats identified while threat modeling. Each
type of threat in STRIDE is linked to a security property that software should have to defend
against the threat.
The provided table defines these threat types and security properties to help you understand
how they relate to each other.
49 / 57
07/01/2015

Because it is usually not possible to address all threats at once, it is important for your
organization to be able to prioritize them efficiently. The DREAD methodology, also developed at
Microsoft, provides the means for you to quantify the risk introduced by threats or vulnerabilities
your organization has identified. DREAD allows you to assign a risk rating to threats by considering
the D, R, E, A, and D risk components of a threat. By first rating these components individually and
then adding their ratings together, you will be able to rate each threats overall risk. The provided
table, taken from Microsofts Patterns and Practices Threat Modeling article, shows an example
on how to establish such a rating system. Note that there are other ways to prioritize threats that
might be more suitable for your organizations needs.
Rating
High (3)
Damage
Potential
How much
damage
would be
caused if the
threat was
realized?
The attacker can Leaking sensitive information.

subvert the
attacker is able to gain access
security system. The
to sensitive information that is
Get full trust
stored, processed or transmitted
authorization;
by the system. This could include
run as
personally identifiable information
administrator;
or protected information such as
upload
social security number or a
content.
password.
The attack can

be reproduced
every time.
Reproducibility For example,
How easy is it
the attack
to reproduce
does not
the attack?
require a
specific time
window to
succeed.
Medium (2)
Low (1)
Leaking trivial
information.
The attacker is
able to access
information
that they are
not authorized
for, but the
information is
not particularly
sensitive.
The attack can be reproduced

sometimes.
For example, the attack can be
reproduced only during a specific
time window and when a very
particular set of conditions is met.
The attack is very

difficult to
reproduce.
Even with
knowledge of
the security
hole.
Exploitability
How easy is it
to launch an
attack?
By a novice
programmer.
A novice
programmer
could craft an
attack in a
short time.
By a skilled programmer.
A skilled programmer could make
the attack, then repeat the steps.
By an expert.
The attack
requires an
extremely skilled
person and indepth
knowledge
every time to
exploit.
Affected users
How large is
the
population
of affected
users?
All users.
All users, in
the default
configuration,
key
customers.
Some users.
For example, only some users that
have a specific non-default
configuration are affected.
Very small
percentage of
users.
For example,
users that use
an obscure
feature of the
software.
Discoverability
How easy is it
for attackers
to find the
vulnerability?
Published
information
explains the
attack.
For example,
the
vulnerability is
found in the
most
commonly
used feature
and is very
noticeable.
bug is
The vulnerability is in a seldom-used The
obscure.
part of the product.
It is unlikely that
Only a few users should come
users will work
across it. It would take some
out damage
thinking to see malicious use.
potential.
After categorizing threats, you should prioritize them because it is not possible to address all
Narration: threats at once. The DREAD methodology helps you to quantify the risk introduced by threats
or vulnerabilities your organization has identified. DREAD allows you to assign a risk rating to
threats by considering the D, R, E, A, and D risk components of a threat. These components
are first rated individually and then their ratings are added together to rate each threats
overall risk.
The provided table shows an example on how to establish such a rating system.
50 / 57
07/01/2015

The development phase is a crucial step in the creation of secure software.
50 percent defects are due to coding errors (Software Security: Building Security In by Gary
McGraw (Addison-Wesley, 2006) ISBN: 0-321-35670-5).
Developers should be aware of the security peculiarities of each technology they are using to
avoid introducing vulnerabilities. Often, specific technologies involve specific secure coding best
practices.
Some best practices include:
Perform input and data validation
Do not use insecure APIs
Fail securely
Protect sensitive data
Manage accounts securely
Implement proper authorization
Follow secure auditing and logging procedures.
Perform manual and automated security code reviews to catch security bugs before software is
sent out for testing.
Note: For guidance on secure coding practices, visit Microsofts Patterns and Practices or the
Open Web Application Security Project (OWASP) Development Guide.
The development phase is the most crucial stage in the software development lifecycle
Narration: because most coding errors arise at this stage.
Developers should be aware of the security peculiarities of each technology they are using to
avoid introducing vulnerabilities. Often, specific technologies involve specific secure coding
best practices. For example, depending on whether you are developing Web applications,
writing native code, following the client-server model, or interacting with backend databases,
there are different secure coding best practices you should follow.
Generic secure coding best practices that developers should follow include performing input
and output validation, not using insecure APIs, failing securely, protecting sensitive data,
managing accounts securely, implementing proper authorization, and following secure
auditing and logging procedures.
To track if such best practices have been properly followed, organizations should perform
manual and automated security code reviews to catch security bugs before software is sent
out for testing.
Static analysis tools can be helpful in auditing source code and detect vulnerabilities during the
development phase. These tools scan the applications source code for several bugs.
Dynamic scanning is used while the application is running. It helps you to discover bugs and
vulnerabilities. On the other hand, manual scanning requires human efforts to discover bugs
and vulnerabilities.
51 / 57
07/01/2015

Despite your organizations best effort at designing and
developing software securely, vulnerabilities might still be
present. Security testing should be performed to uncover
these vulnerabilities and provide your organization a chance
to remove them before it releases the software to
customers or to the production environment.
Security testing is very different from traditional functional
testing, as it requires different sets of skills and tools.
Security testing consists mainly of analyzing the software for
the presence of known classes of vulnerabilities. Obviously,
to be successful at testing security, software security testers
should be aware of these classes of vulnerabilities, their
symptoms of failure, and the common methods through
which they are discovered.
Note: Security test cases should be derived from previously
created threat models to ensure that security testing
effectively verifies that all applicable threats have been
properly avoided or mitigated.
Every organization tries its best to design and develop software securely. Still some
Narration: vulnerabilities are left out. To defend against these vulnerabilities, security testing should be
performed. Security testing uncovers these vulnerabilities and provides your organization a
chance to remove them before it releases the software to customers or to the production
environment.
Security testing is different from traditional functional testing. Security testing consists mainly
of analyzing the software for the presence of known classes of vulnerabilities. To be successful
at testing security, software security testers should be aware of these classes of vulnerabilities,
their symptoms of failure, and the common methods through which they are discovered.
Testing for Specific Types of Vulnerabilities

Examples of classes of security defects, along with their definition, that software should be
verified against:
Buffer overflows. A programming error that may result in unauthorized memory access and
arbitrary code execution on the victim host. Only affects native code.
SQL injection. A type of vulnerability caused by improper inclusion of user-specified
parameters into an SQL query that can allow an attacker to change the behavior of the query
when it is executed by a backend database.
Cross-site scripting. A category of security vulnerabilities common in Web applications that
allow code to be injected by malicious Web users into Web pages viewed by other users.
Lack of server-side authorization. A vulnerability affecting client-server applications caused by
the fact that authorization is performed on the client. By exploiting this type of vulnerability,
attackers may illegally access the assets of the system.
Weak authentication. A type of flaw that allows attackers to bypass authentication and,
therefore, access resources of the system inappropriately.
Weak authorization. A class of vulnerability that allows authorization to be bypassed. By
exploiting this type of flaw, attackers can potentially elevate their level of privilege by accessing
resources that they otherwise would not have access to.
Improper use of cryptography. A type of vulnerability caused by the insecure use of
cryptographic mechanisms such as encryption and hashing functions.
Improper error handling. A category of vulnerabilities that can result in sensitive information
being revealed to attackers or the application being in an insecure state.
Security testers need to be familiar with the different categories of software vulnerabilities to
Narration: know how to test for them and to be able to spot their presence.
Various classes of security defects are as follows:
Buffer overflows is a programming error that may result in unauthorized memory access and
arbitrary code execution on the victim host. It only affects native code.
SQL injection is a type of vulnerability caused by improper inclusion of user-specified
parameters into an SQL query that can allow an attacker to change the behavior of the query
when it is executed by a backend database.
Cross-site scripting is a category of security vulnerabilities common in Web applications that
allows code to be injected by malicious Web users into Web pages viewed by other users.
Lack of server-side authorization is a vulnerability affecting client-server applications caused
by the fact that authorization is performed on the client.
Weak authentication is a type of flaw that allows attackers to bypass authentication and,
therefore, access resources of the system inappropriately.
Weak authorization is a class of vulnerability that allows authorization to be bypassed.
Improper use of cryptography is a type of vulnerability caused by the insecure use of
cryptographic mechanisms such as encryption and hashing functions.
Improper error handling is a category of vulnerabilities that can result in sensitive information
being revealed to attackers or the application being in an insecure state.
52 / 57
07/01/2015
Leveraging Security Testing Tools

Because security testing often involves monitoring,
intercepting, and modifying data in ways that are usually not
intended, it requires a specific set of tools. To be efficient at
security testing, testers should get help from appropriate
security testing tools. These include:
Monitoring tools
Network sniffers
Debuggers and decompilers
Web proxies
Web application scanners
Fuzzers
Binary Static Analysis tools
Software testing is an important step in the software development lifecycle that involves
Narration: monitoring, intercepting, and modifying data in ways that are usually different from
conventional methods. Therefore, it becomes necessary that testers have access to the
required security testing tools. These tools include monitoring tools, network sniffers,
debuggers and decompilers, Web proxies, Web application scanners, fuzzers, and binary static
analysis tools.
Stop and Think!

Prior to the release of a software, it is crucial to ensure that all
requirements stipulated earlier in the project are met. What does
this mean from a software security perspective?
Consider the following activities and reflect on their relevance
with respect to your organizations attempt to assess the risk
represented by software right before its release:
Review of all security deliverables produced so far including
security requirements, design documents, threat models, security
code review deliverables, and security test plans.
Review security bugs and their corresponding fixes.
Evaluate the software against the established security bug bar
or other security criteria specified at the organizational level.
Assess the compliance of software with any applicable standard
or regulation.
Now, imagine that the software still contains major security
vulnerabilities. What would be the possible alternatives for your
organization should such a scenario arise? Consider the following
possibilities:
Release the software as is.
Postpone the release.
Release the software while disabling components,
representing a high risk.
Module Summary
53 / 57
07/01/2015
Module Summary
Identify the
root causes of
software
vulnerabilities
Identify the root causes of software vulnerabilities

Software vulnerabilities find their roots in improper design and coding
practices. However, there are several other areas of the software
development lifecycle where an organization can fail to address security.
It is crucial to understand these failures in order to justify following
appropriate secure development practices throughout the software
development process.
Comprehend
activities that
reduce
software
security risk
Comprehend activities that reduce software security risk

Secure software development is best achieved through a holistic process
that prescribes security activities at each phase of the software
development lifecycle. These activities include, but are not limited to,
gathering security requirements, reducing software attack surface, threat
modeling, secure design, following secure coding best practices, security
code review, security testing, and security response preparation and
execution.
54 / 57
07/01/2015

Various books are available that define and explain the field of application security. These books show
testers and developers how they can develop secure code and prevent security vulnerabilities.
Click each tab to learn more about details of available books.
Hacking: The
Art of
Exploitation
Author: Jon Erickson
The Art of
Software
Security
Assessment:
Identifying
and
Preventing
Software
Vulnerabilities
Authors: Mark Dowd, John McDonald, and Justin Schuh
Security
Engineering:
A Guide to
Building
Dependable
Distributed
Systems
Author: Ross J. Anderson
Writing
Secure Code:
Practical
Strategies and
Proven
Techniques
for Building
Secure
Applications
in a
Networked
World
Authors: Michael Howard and David LeBlanc
Rather than merely showing how to run existing exploits, author Jon Erickson
explains how arcane hacking techniques actually work. To share the art and
science of hacking in a way that is accessible to everyone, this book introduces
the fundamentals of C programming from a hacker's perspective. The included
LiveCD provides a complete Linux programming and debugging environment
all without modifying your current operating system. Use it to follow along with
the book's examples as you fill gaps in your knowledge and explore hacking
techniques on your own. Get your hands dirty debugging code, overflowing
buffers, hijacking network communications, bypassing protections, exploiting
cryptographic weaknesses, and perhaps even inventing new exploits.
This book covers the full spectrum of software vulnerabilities in both

UNIX/Linux and Windows environments. It demonstrates how to audit security
in applications of all sizes and functions, including network and Web software.
Moreover, it teaches using extensive examples of real code drawn from past
flaws in many of the industry's highest-profile applications. This book is an
unprecedented resource for everyone who must deliver secure software or
assure the safety of existing software: consultants, security specialists,
developers, QA staff, testers, and administrators alike.
This book is comprehensive and carefully researched. It makes it clear just how
difficult it is to protect information systems from corruption, eavesdropping,
unauthorized use, and general malice. Better, Ross Anderson offers a lot of
thoughts on how information can be made more secure (though probably not
absolutely secure, at least not forever) with the help of both technologies and
management strategies. His work makes fascinating reading and will no doubt
inspire considerable doubt in anyone with information to gather, protect, or
make decisions about.
This book describes how to harden your applications throughout the entire
development process from designing secure applications to writing robust
code that can withstand repeated attacks to testing applications for security
flaws. Easily digested chapters reveal proven principles, strategies, and coding
techniques. The authors two battle-scarred veterans who have solved some of
the industrys toughest security problems provide sample code in several
languages.
Narration: Various books are available that define and explain the field of application security. These books show
testers and developers how they can develop secure code and prevent security vulnerabilities.
55 / 57
07/01/2015

Additional resources continued from the previous page.
19 Deadly
Sins of
Software
Security:
Programming
Flaws and
How to Fix
Them
Authors: Michael Howard, David LeBlanc, and John Viega
The Security
Development
Lifecycle
Authors: Michael Howard and Steve Lipner
This essential book for all software developers, regardless of platform, language,
or type of application, outlines the 19 deadly sins of software security and
shows how to fix each one. Best-selling authors Michael Howard and David
LeBlanc, who teach Microsoft employees how to write secure code, have
partnered with John Viega, the man who uncovered the 19 deadly programming
sins to write this much-needed book.
The software industry has been struggling with how to create and release
software that is more security-enhanced and reliable; the Security Development
Lifecycle (SDL) provides a methodology that works. Adapted from Microsofts
standard development process, SDL is a critical way to help reduce the number
of security defects in code at every stage of the development process, from
design to release. In addition to a brief history of the methodology, this book
details each stage of the SDL methodology and discusses its implementation
across a range of Microsoft software, including Microsoft Windows Server
2003, Microsoft SQL Server 2000 Service Pack 3, and Microsoft Exchange Server
2003 Service Pack 1, to help measurably improve security features.
Coauthored by Michael Howard and Steve Lipner, you get direct access to
insights from Microsofts security team and lessons that are repeatable and
applicable to software development processes worldwide, whether on a smallscale or large-scale. This book includes a CD featuring videos of developer
training classes.
How to Break
Software
Security
Authors: James A. Whittaker and Herbert H. Thompson
How to Break
Web
Software:
Functional
and Security
Testing of
Web
Applications
and Web
Services
Authors: Mike Andrews and James A. Whittaker
This book is for software testers and developers. It presents testing techniques
that expose security holes caused by software dependencies, data-dependent
weaknesses in software, application design flaws, and implementation-related
vulnerabilities. The book is an industry bestseller and required reading for
security testers in many large software development houses. Over 40
universities refer to this book for developing courses on software security and
testing.
Since its early days as an information exchange tool limited to academe,

researchers, and the military, the Web has grown into a commerce engine that is
now omnipresent in all facets of our lives. More Websites are created daily and
more applications are developed to allow users to learn, research, and purchase
online. As a result, Web development is often rushed, which increases the risk
of attacks from hackers. Furthermore, the need for secure applications has to be
balanced with the need for usability, performance, and reliability.
In this book, Whittaker and Andrews demonstrate how rigorous web testing can
help prevent and prepare for such attacks. They point out that methodical
testing must include identifying threats and attack vectors to establish and then
implement the appropriate testing techniques, manual or automated.
Narration: Additional resources continued from the previous page.

56 / 57
07/01/2015
TeamMentor OWASP Edition provides detailed information on OWASP Top 10 application security topics
in a web reference format designed to help you put what you've learned into daily practice. To view the
security guidance articles, please browse to owasp.teammentor.net. Security Innovation has donated
this to the OWASP community for free use by all.
TeamMentor Enterprise Edition provides a complete application security reference with more than ten
times the information of the TeamMentor OWASP Edition. To view the security guidance articles; please
browse to teammentor.net.
Narration: TeamMentor OWASP Edition provides detailed information on OWASP Top 10 application security
topics in a web reference format designed to help you put what you've learned into daily practice.
Security Innovation has donated this to the OWASP community for free use by all.
TeamMentor Enterprise Edition provides a complete application security reference with more than
ten times the information of the TeamMentor OWASP Edition.
57 / 57

Fundamentals of Application Security

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Fundamentals of Application Security

Caricato da

Copyright:

Formati disponibili

Fundamentals of Application Security