[Type here]

Wh

ite

Pa

pe

r

Application Security Development Guidelines Reducing the Top-Ten most critical web application security flaws

Source: Manoranjan Paul

Doc Revision: Version 1.1

Doc Revision Date: August 11, 2014

Page 2 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

Table of contents

Purpose of this document ....................................................................................................... 4

Introduction ........................................................................................................................... 4

What is Application Security Development? ........................................................................... 4

Security Architecture ..................................................................................................................................... 4

Security Principles ......................................................................................................................................... 4

1. Guidelines for Preventing Injection................................................................................... 6

1.1. What is Injection? ................................................................................................................................. 6

1.2. Defence Option 1: Prepared Statements (Parameterized Queries) ..................................................... 7

1.3. Defence Option 2: Stored Procedures .................................................................................................. 8

1.4. Defence Option 3: Escaping All User Supplied Input ............................................................................ 9

1.5. Additional Defences: .......................................................................................................................... 10

2. Guidelines for Preventing Broken Authentication and Session Management ................... 11

2.1. What is Broken Authentication and Session Management ................................................................ 11 2.2. Defences ............................................................................................................................................. 11

3. Guidelines for Preventing Cross Site Scripting (XSS) ........................................................ 12

3.1. What is XSS? ....................................................................................................................................... 12

3.2. Three known types of XSS flaws: ........................................................................................................ 13

3.3. Defences ............................................................................................................................................. 16

4. Guidelines for Preventing Insecure Direct Object References .......................................... 21

4.1. What are Insecure Direct Object References? ................................................................................... 21

4.2. Insecure Direct Object References Examples: .................................................................................... 22

4.3. Defences for Insecure Direct Object References................................................................................ 22

5. Guidelines for Preventing Application Security Misconfiguration .................................... 22

5.1. What is Application Security Misconfiguration? ................................................................................ 22

5.2. Is My Organisation Vulnerable to Application Security Misconfiguration? ....................................... 23

5.3. Application Security Misconfiguration Examples: .............................................................................. 23

5.4. Defences for Application Security Misconfiguration .......................................................................... 23

6. Guidelines for Preventing Sensitive Data Exposure ......................................................... 24

6.1. What is Sensitive Data Exposure? ...................................................................................................... 24

6.2. Is My Organisation vulnerable to Sensitive Data Exposure? .............................................................. 25

6.3. Examples of Sensitive Data Exposure ................................................................................................. 25

6.4. Defences for Preventing Sensitive Data Exposure ............................................................................. 25

7. Guidelines for Missing Function Level Access Control...................................................... 26

7.1. What is Missing Function Level Access Control? ................................................................................ 26

7.2. Is My Organisation Vulnerable to Missing Function Level Access Control? ....................................... 26

7.3. Examples of Missing Function Level Access Control .......................................................................... 27

7.4. Defences for Missing Function Level Access Control ......................................................................... 27

8. Guidelines for Preventing Cross-Site Request Forgery (CSRF) .......................................... 28

8.1. What is Cross-Site Request Forgery? .................................................................................................. 28

© Copyright Test and Verification Solutions Ltd. 2014 Page 3

Application Security Development Guidelines

8.2. Cross-Site Request Forgery Example: ................................................................................................. 29

8.3. Defences for Cross-Site Request Forgery ........................................................................................... 29

9. Guidelines for Components with Known Vulnerabilities ................................................. 32

9.1. What are Known Vulnerable Components? ....................................................................................... 32

9.2. Is My Organisation vulnerable to Using Components with Known Vulnerabilities? .......................... 32

9.3. Examples of Using Components with Known Vulnerabilities:............................................................ 32

9.4. Defences for Using Components with Known Vulnerabilities:........................................................... 33

10. Guidelines for Preventing Un-validated Redirects and Forwards ................................... 33

10.1. What are Un-validated Redirects and Forwards? .............................................................................. 33

10.2. Is My Organisation vulnerable to Un-validated Redirects and Forwards? ......................................... 33

10.3. Examples of Un-validated Redirects and Forwards ............................................................................ 34

10.4. Defences for Un-validated Redirects and Forwards ........................................................................... 34

11. About This Document ................................................................................................... 35

11.1. Referenced documents ...................................................................................................................... 35

Page 4 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

Purpose of this document

The purpose of this document is to set out the guidelines for application development to include good

practice for avoiding security vulnerabilities on any project. This document outlines the following:

An explanation of Application Security Development.

Guidelines for developers to prevent the top ten application security risks.

Introduction

The aim of this Development Guide is to allow developers, designers and solution architects to produce

secure web applications. If done from the earliest stages, secure applications cost about the same to

develop as insecure applications, but are far more cost effective in the long run.

To protect an organisation, web applications must be self-defending.

What is Application Security Development?

Security Architecture

The best system architecture designs and detailed design documents contain security discussion in each

and every feature, how the risks are going to be mitigated, and what was actually done during coding.

Security architecture starts on the day the business requirements are modeled, and never finishes until

the last copy of your application is decommissioned. Security is a life-long process, not a one shot

accident.

When starting a new application or re-factoring an existing application, you should consider each

functional feature:

Is the process surrounding this feature as safe as possible? In other words, is this a flawed process?

If I were evil, how would I abuse this feature?

Is the feature required to be on by default? If so, are there limits or options that could help reduce the

risk from this feature?

Security Principles

Minimize Attack Surface Area

Every feature that is added to an application adds a certain amount of risk to the overall application. The

aim for secure development is to reduce the overall risk by reducing the attack surface area.

For example, a web application implements online help with a search function. The search function may

be vulnerable to SQL injection attacks. If the help feature was limited to authorized users, the attack

likelihood is reduced. If the help feature’s search function was gated through centralized data validation

routines, the ability to perform SQL injection is dramatically reduced. However, if the help feature was

re-written to eliminate the search function (through better user interface, for example), this almost

eliminates the attack surface area, even if the help feature was available to the Internet at large.

Principle of Least Privilege

The principle of least privilege recommends that accounts have the least amount of privilege required to

perform their business processes. This encompasses user rights, resource permissions such as CPU limits,

© Copyright Test and Verification Solutions Ltd. 2014 Page 5

Application Security Development Guidelines

memory, network, and file system permissions.

For example, if a middleware server only requires access to the network, read access to a database table,

and the ability to write to a log, this describes all the permissions that should be granted. Under no

circumstances should the middleware be granted administrative privileges.

Principle of Defence in Depth

The principle of defense in depth suggests that where one control would be reasonable, more controls

that approach risks in different fashions are better. Controls, when used in depth, can make severe

vulnerabilities extraordinarily difficult to exploit and thus unlikely to occur.

With secure coding, this may take the form of tier-based validation, centralized auditing controls, and

requiring users to be logged on all pages.

For example, a flawed administrative interface is unlikely to be vulnerable to anonymous attack if it

correctly gates access to production management networks, checks for administrative user authorization,

and logs all access.

Fail Securely

Applications regularly fail to process transactions for many reasons. How they fail can determine if an

application is secure or not.

For example:

isAdmin = true;

try {

codeWhichMayFail();

isAdmin = isUserInRole( “Administrator” );

}

catch (Exception ex) {

log.write(ex.toString());

}

If either codeWhichMayFail() or isUserInRole fails or throws an exception, the user is an admin by default.

This is obviously a security risk.

Avoid security by obscurity

Security through obscurity is a weak security control, and nearly always fails when it is the only control.

This is not to say that keeping secrets is a bad idea, it simply means that the security of key systems should

not be reliant upon keeping details hidden.

For example, the security of an application should not rely upon knowledge of the source code being kept

secret. The security should rely upon many other factors, including reasonable password policies, defense

in depth, business transaction limits, solid network architecture, and fraud and audit controls.

Fix security issues correctly

Once a security issue has been identified, it is important to develop a test for it, and to understand the

root cause of the issue. When design patterns are used, it is likely that the security issue is widespread

amongst all code bases, so developing the right fix without introducing regressions is essential.

For example, a user has found that they can see another user’s data by adjusting their cookie. The fix seems

to be relatively straightforward, but as the cookie handling code is shared among all applications, a change

to just one application will trickle through to all other applications. The fix must therefore be tested on all

affected applications.

Page 6 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

1. Guidelines for Preventing Injection

1.1. What is Injection?

Source: OWASP

An SQL injection is often used to attack the security of a website by inputting SQL statements in a web

form to get a poorly designed website to perform operations on the database (often to dump the database

content to the attacker) other than the usual operations as intended by the designer. SQL injection is a

code injection technique that exploits security vulnerability in a website's software. The vulnerability

happens when user input is either incorrectly filtered for string literal escape characters embedded in

SQL statements or user input is not ‘strongly typed’ and unexpectedly executed. SQL commands are

thus injected from the web form into the database of an application (like queries) to change the database

content or dump the database information to the attacker.

SQL injection is mostly known as an attack vector for websites but can be used to attack any type of

SQL (including Oracle) database. An example: The application uses untrusted data in the construction

of the following vulnerable SQL call:

String query = "SELECT * FROM accounts WHERE custID='" +

request.getParameter("id") +"'";

The attacker modifies the 'id' parameter in their browser to send: ' or '1'='1. This changes the meaning

of the query to return all the records from the accounts database, instead of only the intended

customer's.

http://example.com/app/accountView?id=' or '1'='1

In the worst case, the attacker uses this weakness to invoke special stored procedures in the database,

allowing a complete takeover of the database host.

To avoid SQL injection flaws is simple. Developers need to either: a) stop writing dynamic queries;

and/or b) prevent user supplied input which contains malicious SQL from affecting the logic of the

executed query.

These Development Guidelines provides a set of simple techniques for preventing SQL Injection

vulnerabilities by avoiding these two problems. These techniques can be used with practically any kind

of programming language with any type of database. There are other types of databases, like XML

databases, which can have similar problems (e.g., XPath and XQuery injection) and these techniques

can be used to protect them as well.

Primary Defenses:

Option #1: Use of Prepared Statements (Parameterized Queries)

Option #2: Use of Stored Procedures

Option #3: Escaping all User Supplied Input

Additional Defenses:

Also Enforce: Least Privilege

Also Perform: White List Input Validation

© Copyright Test and Verification Solutions Ltd. 2014 Page 7

Application Security Development Guidelines

1.2. Defence Option 1: Prepared Statements (Parameterized Queries)

The use of prepared statements (aka parameterized queries) is how all developers should first be taught

how to write database queries. They are simple to write, and easier to understand than dynamic queries.

Parameterized queries force the developer to first define all the SQL code, and then pass in each

parameter to the query later. This coding style allows the database to distinguish between code and

data, regardless of what user input is supplied.

Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL

commands are inserted by an attacker. In the safe example below, if an attacker were to enter the

userID of tom' or '1'='1, the parameterized query would not be vulnerable and would instead look for a

username which literally matched the entire string tom' or '1'='1.

Language specific recommendations:

Java EE – use PreparedStatement() with bind variables

.NET – use parameterized queries like SqlCommand() or OleDbCommand() with bind variables

PHP – use PDO with strongly typed parameterized queries (using bindParam())

Hibernate - use createQuery() with bind variables (called named parameters in Hibernate)

SQLite - use sqlite3_prepare() to create a statement object

In rare circumstances, prepared statements can harm performance. When confronted with this situation,

it is best to escape all user supplied input using an escaping routine specific to your database vendor as

is described below, rather than using a prepared statement. Another option which might solve your

performance issue is to use a stored procedure instead.

Safe Java Prepared Statement Example:

The following code example uses a PreparedStatement, Java's implementation of a parameterized

query, to execute the same database query.

String custname = request.getParameter("customerName"); // This should REALLY be

validated too

// perform input validation to detect attacks

String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";

PreparedStatement pstmt = connection.prepareStatement( query );

pstmt.setString( 1, custname);

ResultSet results = pstmt.executeQuery( );

Hibernate Query Language (HQL) Prepared Statement (Named Parameters) Examples:

First is an unsafe HQL Statement:-

Query unsafeHQLQuery = session.createQuery("from Inventory where

productID='"+userSuppliedParameter+"'");

Here is a safe version of the same query using named parameters:-

Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");

safeHQLQuery.setParameter("productid", userSuppliedParameter);

Developers tend to like the Prepared Statement approach because all the SQL code stays within the

application. This makes your application relatively database independent. However, other options allow

you to store all the SQL code in the database itself, which has both security and non-security advantages.

That approach, called Stored Procedures, is described next.

Page 8 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

1.3. Defence Option 2: Stored Procedures

Stored procedures have the same effect as the use of prepared statements when implemented safely*.

They require the developer to define the SQL code first, and then pass in the parameters after. The

difference between prepared statements and stored procedures is that the SQL code for a stored

procedure is defined and stored in the database itself, and then called from the application. Both of these

techniques have the same effectiveness in preventing SQL injection so developers should choose which

approach makes the most sense.

*Note: 'Implemented safely' means the stored procedure does not include any unsafe dynamic SQL

generation. Developers do not usually generate dynamic SQL inside stored procedures. However, it can be

done, but should be avoided. If it can't be avoided, the stored procedure must use input validation or

proper escaping as described in this document to make sure that all user supplied input to the stored

procedure can't be used to inject SQL code into the dynamically generated query. Auditors should always

look for uses of sp_execute, execute or exec within SQL Server stored procedures. Similar audit guidelines

are necessary for similar functions for other vendors.

There are also several cases where stored procedures can increase risk. For example, on MS SQL server,

you have 3 main default roles: db_datareader, db_datawriter and db_owner. Before stored procedures

came into use, DBA's would give db_datareader or db_datawriter rights to the webservice's user,

depending on the requirements. However, stored procedures require execute rights, a role that is not

available by default. Some setups where the user management has been centralized, but is limited to those

3 roles, cause all web apps to run under db_owner rights so stored procedures can work. Naturally, that

means that if a server is breached the attacker has full rights to the database, where previously they might

only have had read-access.

Unsafe Java Query Example

SQL injection flaws typically look like this:

The following (Java) example is UNSAFE, and would allow an attacker to inject code into the query that

would be executed by the database. The unvalidated “customerName” parameter that is simply appended

to the query allows an attacker to inject any SQL code they want. Unfortunately, this method for accessing

databases is all too common.

String query = "SELECT account_balance FROM user_data WHERE user_name = "

+ request.getParameter("customerName");

try {

Statement statement = connection.createStatement( … );

ResultSet results = statement.executeQuery( query );

}

Safe Java Stored Procedure Example

The following code example uses a CallableStatement, Java's implementation of the stored procedure

interface, to execute the same database query. The "sp_getAccountBalance" stored procedure would have

to be predefined in the database and implement the same functionality as the query defined above.

String custname = request.getParameter("customerName"); // This should REALLY be validated

try {

CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}");

cs.setString(1, custname);

ResultSet results = cs.executeQuery();

// … result set handling

} catch (SQLException se) {

// … logging and error handling

}

© Copyright Test and Verification Solutions Ltd. 2014 Page 9

Application Security Development Guidelines

1.4. Defence Option 3: Escaping All User Supplied Input

This third technique is to escape user input before putting it in a query. If you are concerned that rewriting

your dynamic queries as prepared statements or stored procedures might break your application or

adversely affect performance, then this might be the best approach for you. However, this methodology

is frail compared to using parameterized queries. This technique should only be used, with caution, to

retrofit legacy code in a cost effective way. Applications built from scratch, or applications requiring low

risk tolerance should be built or re-written using parameterized queries.

This technique works like this. Each DBMS supports one or more character escaping schemes specific to

certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for

the database you are using, the DBMS will not confuse that input with SQL code written by the developer,

thus avoiding any possible SQL injection vulnerabilities.

Database Specific Escaping Details

If you want to build your own escaping routines, here are the escaping details for each of the databases

that OWASP have developed ESAPI Encoders for:

Oracle Escaping

This information is based on the Oracle Escape character information found here:

http://www.orafaq.com/wiki/SQL_FAQ#How_does_one_escape_special_characters_when_writing_SQL

_queries.3F

Escaping Dynamic Queries To use an ESAPI database codec is pretty simple. An Oracle example looks something like:

ESAPI.encoder().encodeForSQL( new OracleCodec(), queryparam );

So, if you had an existing Dynamic query being generated in your code that was going to Oracle that looked

like this:

String query = "SELECT user_id FROM user_data WHERE user_name = '" +

req.getParameter("userID")

+ "' and user_password = '" + req.getParameter("pwd") +"'";

try {

Statement statement = connection.createStatement( … );

ResultSet results = statement.executeQuery( query );

}

You would rewrite the first line to look like this:

Codec ORACLE_CODEC = new OracleCodec();

String query = "SELECT user_id FROM user_data WHERE user_name = '" +

ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("userID")) + "'

and user_password = '"

+ ESAPI.encoder().encodeForSQL( ORACLE_CODEC, req.getParameter("pwd")) +"'";

And it would now be safe from SQL injection, regardless of the input supplied.

For maximum code readability, you could also construct your own OracleEncoder.

Encoder oe = new OracleEncoder();

String query = "SELECT user_id FROM user_data WHERE user_name = '"

+ oe.encode( req.getParameter("userID")) + "' and user_password = '"

+ oe.encode( req.getParameter("pwd")) +"'";

Page 10 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

With this type of solution, all developers would have to do is wrap each user supplied parameter being

passed in into an ESAPI.encoder().encodeForOracle( ) call or whatever it is called at your organisation .

Turn off character replacement

Use SET DEFINE OFF or SET SCAN OFF to ensure that automatic character replacement is turned off. If this character replacement is turned on, the & character will be treated like a SQLPlus variable prefix that could allow an attacker to retrieve private data.

See http://download.oracle.com/docs/cd/B19306_01/server.102/b14357/ch12040.htm#i2698854 and http://stackoverflow.com/questions/152837/how-to-insert-a-string-which-contains-an for more information.

Escaping Wildcard characters in Like Clauses

The LIKE keyword allows for text scanning searches. In Oracle, the underscore '_' character matches only

one character, while the ampersand '%' is used to match zero or more occurrences of any characters.

These characters must be escaped in LIKE clause criteria. For example:

SELECT name FROM emp

WHERE id LIKE '%/_%' ESCAPE '/';

SELECT name FROM emp

WHERE id LIKE '%\%%' ESCAPE '\';

Oracle 10g escaping

An alternative for Oracle 10g and later is to place { and } around the string to escape the entire string.

However, you have to be careful that there isn't a } character already in the string. You must search for

these and if there is one, then you must replace it with }} otherwise that character will end the escaping

early, and may introduce a vulnerability.

1.5. Additional Defences:

Least Privilege

To minimize the potential damage of a successful SQL injection attack, you should minimize the privileges

assigned to every database account in your environment. Do not assign DBA or admin type access rights

to your application accounts. We understand that this is easy, and everything just ‘works’ when you do it

this way, but it is very dangerous. Start from the ground up to determine what access rights your

application accounts require, rather than trying to figure out what access rights you need to take away.

Make sure that accounts that only need read access are only granted read access to the tables they need

access to. If an account only needs access to portions of a table, consider creating a view that limits access

to that portion of the data and assigning the account access to the view instead, rather than the underlying

table. Rarely, if ever, grant create or delete access to database accounts.

If you adopt a policy where you use stored procedures everywhere, and don’t allow application accounts

to directly execute their own queries, then restrict those accounts to only be able to execute the stored

procedures they need. Don’t grant them any rights directly to the tables in the database.

SQL injection is not the only threat to your database data. Attackers can simply change the parameter

values from one of the legal values they are presented with, to a value that is unauthorized for them, but

the application itself might be authorized to access. As such, minimizing the privileges granted to your

application will reduce the likelihood of such unauthorized access attempts, even when an attacker is not

trying to use SQL injection as part of their exploit.

© Copyright Test and Verification Solutions Ltd. 2014 Page 11

Application Security Development Guidelines

While you are at it, you should minimize the privileges of the operating system account that the DBMS

runs under. Don't run your DBMS as root or system! Most DBMSs run out of the box with a very powerful

system account. For example, MySQL runs as system on Windows by default! Change the DBMS's OS

account to something more appropriate, with restricted privileges.

White List

Input Validation can be used to detect unauthorized input before it is passed to the SQL query. Positive or

"whitelist" input validation with appropriate canonicalization also helps protect against injection, but is

not a complete defence as many applications require special characters in their input.

2. Guidelines for Preventing Broken Authentication and Session Management

2.1. What is Broken Authentication and Session Management

Source: OWASP

Anonymous external attackers, as well as users with their own accounts, may attempt to steal accounts

from others or to disguise their actions. The attacker uses leaks or flaws in the authentication or session

management functions (e.g., exposed accounts, passwords, session IDs) to impersonate users. Developers

frequently build custom authentication and session management schemes, but building these correctly is

hard. As a result, these custom schemes frequently have flaws in areas such as logout, password

management, time-outs, remember me, secret question, account update, etc.

2.2. Defences

Authentication is the act of establishing or confirming something (or someone) as authentic, and that

claims made by or about the thing are true. Authenticating an object may mean confirming its

provenance, whereas authenticating a person often consists of verifying his or her identity.

Authentication depends upon one or more authentication factors. In computer security, authentication

is the process of attempting to verify the digital identity of the sender of a communication. A common

example of such a process is the logon process.

Password Storage - All passwords must be stored in either hashed or encrypted form to protect them from

exposure, regardless of where they are stored. Hashed form is preferred since it is not reversible.

Encryption should be used when the plaintext password is needed, such as when using the password to

login to another system. Passwords should never be hardcoded in any source code. Decryption keys must

be strongly protected to ensure that they cannot be grabbed and used to decrypt the password file.

Protecting Credentials in Transit - The only effective technique is to encrypt the entire login transaction

using something like SSL. Simple transformations of the password such as hashing it on the client prior to

transmission provide little protection as the hashed version can simply be intercepted and retransmitted

even though the actual plaintext password might not be known.

Session ID Protection – Ideally, a user’s entire session should be protected via SSL. If this is done, then the

session ID (e.g., session cookie) cannot be grabbed off the network, which is the biggest risk of exposure

for a session ID. If SSL is not viable for performance or other reasons then session IDs themselves must be

protected in other ways. First, they should never be included in the URL as they can be cached by the

Page 12 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

browser, sent in the referrer header, or accidentally forwarded to a ‘friend’. Session IDs should be long,

complicated, random numbers that cannot be easily guessed. Session IDs can also be changed frequently

during a session to reduce how long a session ID is valid. Session IDs must be changed when switching to

SSL, authenticating, or other major transitions. Session IDs chosen by a user should never be accepted.

Account Lists - Systems should be designed to avoid allowing users to gain access to a list of the account

names on the site. If lists of users must be presented, it is recommended that some form of pseudonym

(screen name) that maps to the actual account be listed instead. That way, the pseudonym can’t be used

during a login attempt or some other hack that goes after a user’s account.

Browser Caching – Authentication and session data should never be submitted as part of a GET, POST

should always be used instead. Authentication pages should be marked with all varieties of the no cache

tag to prevent someone from using the back button in a user’s browser to backup to the login page and

resubmit the previously typed in credentials. Many browsers now support the AUTOCOMPLETE=OFF flag

to prevent storing of credentials in autocomplete caches.

Trust Relationships – Your site architecture should avoid implicit trust between components whenever

possible. Each component should authenticate itself to any other component it is interacting with unless

there is a strong reason not to (such as performance or lack of a usable mechanism). If trust relationships

are required, strong procedural and architecture mechanisms should be in place to ensure that such trust

cannot be abused as the site architecture evolves over time.

3. Guidelines for Preventing Cross Site Scripting (XSS)

3.1. What is XSS?

Source: OWASP

Cross-Site Scripting (XSS) attacks are a type of injection problem, in which malicious scripts are injected

into the otherwise benign and trusted web sites. Cross-site scripting attacks occur when an attacker uses

a web application to send malicious code, generally in the form of a browser side script, to a different

end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web

application uses input from a user in the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has

no way to know that the script should not be trusted, and will execute the script. Because it thinks the

script came from a trusted source, the malicious script can access any cookies, session tokens, or other

sensitive information retained by the user’s browser and associated with that site. These scripts can even

rewrite the content of the HTML page.

Cross-Site Scripting (XSS) attacks occur when:

1. Data enters a Web application through an untrusted source, most frequently a web request.

2. The data is included in dynamic content that is sent to a web user without being validated for

malicious code.

The malicious content sent to the web browser often takes the form of a segment of JavaScript, but may

also include HTML, Flash or any other type of code that the browser may execute. The variety of attacks

based on XSS is almost limitless, but they commonly include transmitting private data like cookies or

other session information to the attacker, redirecting the victim to web content controlled by the

© Copyright Test and Verification Solutions Ltd. 2014 Page 13

Application Security Development Guidelines

attacker, or performing other malicious operations on the user's machine under the guise of the

vulnerable site.

Anyone who can send untrusted data to an organisation systems, including external users, internal users,

and administrators is a threat agent. Almost any source of data can be an attack vector, including internal

sources such as data from the database. XSS is the most prevalent web application security flaw. XSS flaws

occur when an application includes user supplied data in a page sent to the browser without properly

validating or escaping that content.

3.2. Three known types of XSS flaws:

1) Stored - Stored attacks are those where the injected code is permanently stored on the target servers,

such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the

malicious script from the server when it requests the stored information.

1. The attacker uses one of the website's forms to insert a malicious string into the website's

database.

2. The victim requests a page from the website.

3. The website includes the malicious string from the database in the response and sends it to the

victim.

4. The victim's browser executes the malicious script inside the response, sending the victim's

cookies to the attacker's server.

Source: Excess XSS by Jakob Kallin and Irene Lobo Valbuena

2) Reflected - Reflected attacks are those where the injected code is reflected off the web server, such as

in an error message, search result, or any response that includes some or all of the input sent to the server

as part of the request.

Page 14 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some

other web server. When a user is tricked into clicking on a malicious link or submitting a specially crafted

form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s

browser. The browser then executes the code because it came from a "trusted" server.

1. The attacker crafts a URL containing a malicious string and sends it to the victim.

2. The victim is tricked by the attacker into requesting the URL from the website.

3. The website includes the malicious string from the URL in the response.

4. The victim's browser executes the malicious script inside the response, sending the victim's

cookies to the attacker's server.

Source: Excess XSS by Jakob Kallin and Irene Lobo Valbuena

3) DOM (Document Object Model) based XSS - DOM Based XSS (or as it is called in some texts, “type-0

XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM

“environment” in the victim’s browser used by the original client side script, so that the client side code

runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but

the client side code contained in the page executes differently due to the malicious modifications that

have occurred in the DOM environment. This is in contrast to other XSS attacks (stored or reflected),

wherein the attack payload is placed in the response page (due to a server side flaw).

© Copyright Test and Verification Solutions Ltd. 2014 Page 15

Application Security Development Guidelines

Source: Excess XSS by Jakob Kallin and Irene Lobo Valbuena

1. The attacker crafts a URL containing a malicious string and sends it to the victim.

2. The victim is tricked by the attacker into requesting the URL from the website.

3. The website receives the request, but does not include the malicious string in the response.

4. The victim's browser executes the legitimate script inside the response, causing the malicious

script to be inserted into the page.

5. The victim's browser executes the malicious script inserted into the page, sending the victim's

cookies to the attacker's server.

In traditional XSS, the malicious JavaScript is executed when the page is loaded, as part of the HTML

sent by the server.

In DOM-based XSS, the malicious JavaScript is executed at some point after the page has loaded, as a

result of the page's legitimate JavaScript treating user input in an unsafe way.

Injection is an attack that involves breaking out of a data context and switching into a code context through

the use of special characters that are significant in the interpreter being used. A data context is like

<div>data context</div>. If the attacker's data gets placed into the data context, they might break out like

this <div>data < script>alert("attack")</script> context</div>.

XSS is a form of injection where the interpreter is the browser and attacks are buried in an HTML

document. HTML is particularly difficult because it is not only hierarchical, but also contains many different

parsers (XML, HTML, JavaScript, VBScript, CSS, URL, etc...).

Page 16 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

There are two ways to inject code:

Injecting UP

The most common way is to close the current context and start a new code context. For example, this is

what you do when you close an HTML attribute with a "> and start a new <script> tag. This attack closes

the original context (going up in the hierarchy) and then starts a new tag that will allow script code to

execute. Remember that you may be able to skip many layers up in the hierarchy when trying to break out

of your current context. For example, a </script> tag may be able to terminate a script block even if it is

injected inside a quoted string inside a method call inside the script. This happens because the HTML parser

runs before the JavaScript parser.

Injecting DOWN

The less common way to perform XSS injection is to introduce a code subcontext without closing the

current context. For example, if the attacker is able to change <img src="...UNTRUSTED DATA HERE..." />

into < img src="javascript:alert(document.cookie)" /> they do not have to break out of the HTML attribute

context. Instead, they introduce a subcontext that allows scripting within the src attribute (in this case a

javascript url). Another example is the expression() functionality in CSS properties. Even though you may

not be able to escape a quoted CSS property to inject up, you may be able to introduce something like

xss:expression(document.write(document.cookie)) without ever leaving the current context.

General Notes

There's also the possibility of injecting directly in the current context. For example, if you take untrusted

input and put it directly into a JavaScript context. Generally it is impossible to secure untrusted code with

escaping (or anything else). If you do this, your application is just a conduit for attacker code to get running

in your users' browsers.

The rules in this document have been designed to prevent both UP and DOWN varieties of XSS injection.

To prevent injecting up, you must escape the characters that would allow you to close the current context

and start a new one. To prevent attacks that jump up several levels in the DOM hierarchy, you must also

escape all the characters that are significant in all enclosing contexts. To prevent injecting down, you must

escape any characters that can be used to introduce a new sub-context within the current context.

3.3. Defences

To defend against XSS, ensure that all user supplied input sent back to the browser is verified to be safe

(via input validation), and that user input is properly escaped before it is included in the output page.

Proper output encoding ensures that such input is always treated as text in the browser, rather than active

content that might get executed.

Rule 0 – Never Insert Untrusted Data Except in Allowed Locations

Preventing XSS requires keeping untrusted data separate from active browser content.

<script>...NEVER PUT UNTRUSTED DATA HERE...</script> directly in a script

<!--...NEVER PUT UNTRUSTED DATA HERE...--> inside an HTML comment

<div ...NEVER PUT UNTRUSTED DATA HERE...=test /> in an attribute name

<NEVER PUT UNTRUSTED DATA HERE... href="/test" /> in a tag name

<style>...NEVER PUT UNTRUSTED DATA HERE...</style> directly in CSS

© Copyright Test and Verification Solutions Ltd. 2014 Page 17

Application Security Development Guidelines

Rule 1 – HTML Escape Before Inserting Untrusted Data into HTML Element Content

Rule 1 is for when you want to put untrusted data directly into the HTML body somewhere. This includes

inside normal tags like div, p, b, td, etc. Most web frameworks have a method for HTML escaping for the

characters detailed below. However, this is absolutely not sufficient for other HTML contexts. You need

to implement the other rules detailed here as well.

<body>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</body>

<div>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</div>

any other normal HTML elements

Escape the following characters with HTML entity encoding to prevent switching into any execution

context, such as script, style, or event handlers. Using hex entities is recommended in the spec. In addition

to the 5 characters significant in XML (&, <, >, ", '), the forward slash is included as it helps to end an HTML

entity.

& --> &amp;

< --> &lt;

> --> &gt;

" --> &quot;

' --> &#x27; &apos; is not recommended

/ --> &#x2F; forward slash is included as it helps end an HTML entity

Rule 2 – Attribute Escape Before Inserting Untrusted Data into HTML

Common Attributes

Rule 2 is for putting untrusted data into typical attribute values like width, name, value, etc. This should

not be used for complex attributes like href, src, style, or any of the event handlers like onmouseover. It is

extremely important that event handler attributes should follow Rule #3 for HTML JavaScript Data Values.

<div attr=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...>content</div>

inside UNquoted attribute

<div attr='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'>content</div>

inside single quoted attribute

<div attr="...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">content</div>

inside double quoted attribute

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the &#xHH;

format (or a named entity if available) to prevent switching out of the attribute. The reason this rule is so

broad is that developers frequently leave attributes unquoted. Properly quoted attributes can only be

escaped with the corresponding quote. Unquoted attributes can be broken out of with many characters,

including [space] % * + , - / ; < = > ^ and |.

Rule 3 – JavaScript Escape Before Inserting Untrusted Data into JavaScript

Data Values

Rule 3 concerns dynamically generated JavaScript code - both script blocks and event-handler attributes.

The only safe place to put untrusted data into this code is inside a quoted "data value." Including untrusted

data inside any other JavaScript context is quite dangerous, as it is extremely easy to switch into an

Page 18 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

execution context with characters including (but not limited to) semi-colon, equals, space, plus, and many

more, so use with caution.

<script>alert('...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...')</script>

inside a quoted string

<script>x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'</script> one

side of a quoted expression

<div onmouseover="x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'"</div>

inside quoted event handler

Please note there are some JavaScript functions that can never safely use untrusted data as input - EVEN

IF JAVASCRIPT ESCAPED!

For example:

<script>

window.setInterval('...EVEN IF YOU ESCAPE UNTRUSTED DATA YOU ARE XSSED

HERE...');

</script>

Except for alphanumeric characters, escape all characters less than 256 with the \xHH format to prevent

switching out of the data value into the script context or into another attribute. DO NOT use any escaping

shortcuts like \" because the quote character may be matched by the HTML attribute parser which runs

first. These escaping shortcuts are also susceptible to "escape-the-escape" attacks where the attacker

sends \" and the vulnerable code turns that into \\" which enables the quote.

If an event handler is properly quoted, breaking out requires the corresponding quote. Unquoted

attributes can be broken out of with many characters including [space] % * + , - / ; < = > ^ and |. Also, a

</script> closing tag will close a script block even though it is inside a quoted string because the HTML

parser runs before the JavaScript parser.

Rule 3.1 – HTML escape JSON values in an HTML context and read the data with JSON.parse

The need for having data dynamically generated by an application in a javascript context is common. One

strategy is to make an AJAX call to get the values, but this isn't always performant. Often, an initial block

of JSON is loaded into the page to act as a single place to store multiple values. This data is tricky, though

not impossible, to escape correctly without breaking the format and content of the values.

Ensure returned Content-Type header is application/json and not text/html. This shall instruct the browser

not misunderstand the context and execute injected script.

JSON entity encoding

The rules for JSON encoding can be found in the Output Encoding Rules Summary. Note, this will not allow

you to use XSS protection provided by CSP 1.0.

HTML entity encoding

This technique has the advantage that html entity escaping is widely supported and helps separate data

from server side code without crossing any context boundaries. Consider placing the JSON block on the

page as a normal element and then parsing the innerHTML to get the contents. The javascript that reads

the span can live in an external file, thus making the implementation of CSP enforcement easier.

© Copyright Test and Verification Solutions Ltd. 2014 Page 19

Application Security Development Guidelines

Rule 4 – CSS Escape And Strictly Validate Before Inserting Untrusted Data

into HTML Style Property Values

Rule 4 is for when you want to put untrusted data into a stylesheet or a style tag. CSS is surprisingly

powerful, and can be used for numerous attacks. Therefore, it's important that you only use untrusted

data in a property value and not into other places in style data. You should stay away from putting

untrusted data into complex properties like url, behavior, and custom (-moz-binding). You should also not

put untrusted data into IE’s expression property value which allows JavaScript.

<style>selector { property : ...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...;

} </style> property value

<style>selector { property : "...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...";

} </style> property value

<span style="property : ...ESCAPE UNTRUSTED DATA BEFORE PUTTING

HERE...">text</style> property value

Please note there are some CSS contexts that can never safely use untrusted data as input - EVEN IF

PROPERLY CSS ESCAPED! You will have to ensure that URLs only start with "http" not "javascript" and that

properties never start with "expression".

For example:

{ background-url : "javascript:alert(1)"; } // and all other URLs

{ text-size: "expression(alert('XSS'))"; } // only in IE

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the \HH

escaping format. DO NOT use any escaping shortcuts like \" because the quote character may be matched

by the HTML attribute parser which runs first. These escaping shortcuts are also susceptible to "escape-

the-escape" attacks where the attacker sends \" and the vulnerable code turns that into \\" which enables

the quote.

If attribute is quoted, breaking out requires the corresponding quote. All attributes should be quoted but

your encoding should be strong enough to prevent XSS when untrusted data is placed in unquoted

contexts. Unquoted attributes can be broken out of with many characters including [space] % * + , - / ; < =

> ^ and |. Also, the </style> tag will close the style block even though it is inside a quoted string because

the HTML parser runs before the JavaScript parser.

Rule 5 – URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values

Rule 5 is for when you want to put untrusted data into HTTP GET parameter value.

<a href="http://www.somesite.com?test=...ESCAPE UNTRUSTED DATA BEFORE PUTTING

HERE...">link</a >

Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the %HH

escaping format. Including untrusted data in data: URLs should not be allowed as there is no good way to

disable attacks with escaping to prevent switching out of the URL. All attributes should be quoted.

Unquoted attributes can be broken out of with many characters including [space] % * + , - / ; < = > ^ and

|. Note that entity encoding is useless in this context.

WARNING: Do not encode complete or relative URL's with URL encoding! If untrusted input is meant to be

placed into href, src or other URL-based attributes, it should be validated to make sure it does not point

to an unexpected protocol, especially Javascript links. URL's should then be encoded based on the context

Page 20 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

of display like any other piece of data. For example, user driven URL's in HREF links should be attribute

encoded. For example:

String userURL = request.getParameter( "userURL" )

boolean isValidURL = ESAPI.validator().isValidInput("URLContext", userURL,

"URL", 255, false);

if (isValidURL) {

<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>

}

Rule 6 – Sanitize HTML Markup with a Library Designed for the Job

If your application handles markup (untrusted input that is supposed to contain HTML) it can be very

difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in

the input. Therefore, you need a library that can parse and clean HTML formatted text. There are several

available at OWASP that are simple to use:

OWASP AntiSamy: https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project

import org.owasp.validator.html.*;

Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);

AntiSamy as = new AntiSamy();

CleanResults cr = as.scan(dirtyInput, policy);

MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function

OWASP Java HTML Sanitizer: https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project

import org.owasp.html.Sanitizers;

import org.owasp.html.PolicyFactory;

PolicyFactory sanitizer = Sanitizers.FORMATTING.and(Sanitizers.BLOCKS);

String cleanResults = sanitizer.sanitize("<p>Hello, <b>World!</b>");

Rule 7 – Prevent DOM-based XSS

Reflected and Stored XSS are server side execution issues while DOM based XSS is a client (browser) side

execution issue. All of this code originates on the server, which means it is the application owner's

responsibility to make it safe from XSS, regardless of the type of XSS flaw it is. This is a large topic best

tackled by following the links below for combating DOM-based XSS.

1. The Open Web Application Security Project – XSS Prevention Cheat Sheet:

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

1.1 RULE #1 - HTML Escape then JavaScript Escape Before Inserting Untrusted Data into HTML

Subcontext within the Execution Context

1.1.1 Example Dangerous HTML Methods

1.1.1.1 Attributes

1.1.1.2 Methods

1.1.2 Guideline

© Copyright Test and Verification Solutions Ltd. 2014 Page 21

Application Security Development Guidelines

1.2 RULE #2 - JavaScript Escape Before Inserting Untrusted Data into HTML Attribute Subcontext

within the Execution Context

1.2.1 SAFE but BROKEN example

1.2.2 SAFE and FUNCTIONALLY CORRECT example

1.3 RULE #3 - Be Careful when Inserting Untrusted Data into the Event Handler and JavaScript code

Subcontexts within an Execution Context

1.3.1 HTML Encoding’s Disarming Nature

1.4 RULE #4 - JavaScript Escape Before Inserting Untrusted Data into the CSS Attribute Subcontext

within the Execution Context

1.5 RULE #5 - URL Escape then JavaScript Escape Before Inserting Untrusted Data into URL

Attribute Subcontext within the Execution Context

2. The DOMinator Tool - A FireFox based plugin that helps testers identify and verify DOM based XSS

flaws. See: http://code.google.com/p/dominator/

3. The DOM XSS Wiki - The start of a Knowledgebase for defining sources of attacker controlled inputs

and sinks which could potentially introduce DOM Based XSS issues. See:

http://code.google.com/p/domxsswiki/

Bonus Rule 1: Use HTTPOnly cookie flag

Preventing all XSS flaws in an application is hard. To help mitigate the impact of an XSS flaw on your

site, set the HTTPOnly flag on your session cookie and any custom cookies you have that are not accessed

by any Javascript you wrote. This cookie flag is typically on by default in .NET apps, but in other

languages you have to set it manually. For more details on the HTTPOnly cookie flag, including what it

does, and how to use it, see the OWASP article on HTTPOnly.

Bonus Rule 2: Implement Content Security Policy

There is another good complex solution to mitigate the impact of an XSS flaw called Content Security

Policy. It's a browser side mechanism which allows you to create source whitelists for client side

resources of your web application, e.g. JavaScript, CSS, images, etc. CSP via special HTTP header

instructs the browser to only execute or render resources from those sources. For more details on

Content Security Policy, including what it does, and how to use it, see the OWASP article on

Content_Security_Policy

4. Guidelines for Preventing Insecure Direct Object References

4.1. What are Insecure Direct Object References?

Source: OWASP

Applications frequently use the actual name or key of an object when generating web pages. Applications

don’t always verify the user is authorized for the target object. This results in an insecure direct object

reference flaw. An attacker, who is an authorized system user, simply changes a parameter value that

Page 22 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

directly refers to a system object to another object the user isn’t authorized for. If access is granted, such

flaws can compromise all the data that can be referenced by the parameter.

The best way to find out if an application is vulnerable to insecure direct object references is to verify that

all object references have appropriate defences. To achieve this, consider:

For direct references to restricted resources, the application needs to verify the user is authorized to

access the exact resource they have requested.

If the reference is an indirect reference, the mapping to the direct reference must be limited to values

authorized for the current user.

4.2. Insecure Direct Object References Examples:

The application uses unverified data in a SQL call that is accessing account information:

String query = "SELECT * FROM accts WHERE account = ?";

PreparedStatement pstmt = connection.prepareStatement(query , ... );

pstmt.setString( 1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery();

The attacker simply modifies the ‘acct’ parameter in their browser to send whatever account number they

want. If not verified, the attacker can access any user’s account, instead of only the intended customer’s

account.

http://example.com/app/accountInfo?acct=notmyacct

4.3. Defences for Insecure Direct Object References

Preventing insecure direct object references requires selecting an approach for protecting each user

accessible object (e.g., object number, filename):

Use per user or session indirect object references. This prevents attackers from directly targeting

unauthorized resources. For example, instead of using the resource’s database key, a drop down list

of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value

the user selected. The application has to map the per-user indirect reference back to the actual

database key on the server.

Check access. Each use of a direct object reference from an untrusted source must include an access

control check to ensure the user is authorized for the requested object.

5. Guidelines for Preventing Application Security Misconfiguration

5.1. What is Application Security Misconfiguration?

Source: OWASP

© Copyright Test and Verification Solutions Ltd. 2014 Page 23

Application Security Development Guidelines

Security misconfiguration can happen at any level of an application stack, including the platform, web

server, application server, framework, and custom code. Such flaws frequently give attackers unauthorized

access to some system data or functionality. Occasionally, such flaws result in a complete system

compromise.

The attacker accesses default accounts, unused pages, unpatched flaws, unprotected files and directories,

etc. to gain unauthorized access to or knowledge of the system. The system could be completely

compromised without the owner knowing it. All data could be stolen or modified slowly over time.

Perpetrators could be anonymous external attackers, users with their own accounts that may attempt to

compromise the system, or insiders wanting to disguise their actions.

5.2. Is My Organisation Vulnerable to Application Security Misconfiguration?

We should check that the organisation has performed the proper security hardening across the entire

application stack.

Does my organisation have a process for keeping all software up to date? This includes the OS,

Web/App Server, DBMS, applications, and all code libraries.

Is everything unnecessary disabled, removed, or not installed (e.g. ports, services, pages, accounts,

privileges)?

Are default account passwords changed or disabled?

Is my organisation system error handling set up to prevent stack traces and other overly informative

error messages from leaking?

Are the security settings in the my organisation development frameworks and libraries understood

and configured properly?

A concerted, repeatable process is required to develop and maintain a proper application security

configuration.

5.3. Application Security Misconfiguration Examples:

Scenario #1: The application relies on a powerful framework like Struts or Spring. XSS flaws are found in

these framework components. An update is released to fix these flaws but the libraries are not updated.

Until the libraries are updated, attackers can easily find and exploit these flaws in the application.

Scenario #2: The application server admin console is automatically installed and not removed. Default

accounts aren’t changed. Attacker discovers the standard admin pages are on your server, logs in with

default passwords, and takes over.

Scenario #3: Directory listing is not disabled on a server. Attackers discover they can simply list directories

to find any file. The attackers find and download all the compiled Java classes, which they reverse engineer

to get all the custom code. The attackers then find a serious access control flaw in an application.

Scenario #4: App server configuration allows stack traces to be returned to users, potentially exposing

underlying flaws. Attackers love the extra information error messages provide.

5.4. Defences for Application Security Misconfiguration

Developers and network administrators need to work together to ensure that the entire stack is configured

properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default

accounts, unnecessary services, etc.

The primary recommendations are to establish all of the following:

Page 24 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

1. A repeatable hardening process that makes it fast and easy to deploy another environment that is

properly locked down. Development, QA, and production environments should all be configured

identically. This process should be automated to minimize the effort required to setup a new

secure environment.

2. A process for keeping abreast of and deploying all new software updates and patches in a timely

manner to each deployed environment. This needs to include all code libraries.

3. A strong application architecture that provides good separation and security between

components.

4. Consider running scans and doing audits periodically to help detect future misconfigurations or

missing patches.

Often analysis of the infrastructure and topology architecture can reveal a great deal about a web

application. Information such as source code, HTTP methods permitted, administrative functionality,

authentication methods, and infrastructural configurations can be obtained. Minimize this exposure!

The file extensions present in a web server or a web application make it possible to identify the

technologies which compose the target application, e.g. jsp and asp extensions. File extensions can also

expose additional systems connected to the application. Avoid this!

Redundant, readable and downloadable files on a web server, such as old, backup and renamed files, are

a big source of information leakage. It is necessary to verify the presence of these files because they may

contain parts of source code, installation paths as well as passwords for applications and/or databases.

Minimize this!

Many applications use a common path for administrative interfaces which can be used to guess or brute

force administrative passwords. Avoid this!

6. Guidelines for Preventing Sensitive Data Exposure

6.1. What is Sensitive Data Exposure?

Source: OWASP

Protecting sensitive data with cryptography has become a key part of most web applications. Simply failing

to encrypt sensitive data is very widespread. Applications that do encrypt frequently contain poorly

designed cryptography, either using inappropriate ciphers or making serious mistakes using strong ciphers.

These flaws can lead to disclosure of sensitive data and compliance violations.

The most common flaw is simply not encrypting data that deserves encryption. When encryption is

employed, unsafe key generation and storage, not rotating keys and weak algorithm usage is common.

Use of weak or unsalted hashes to protect passwords is also common. External attackers have difficulty

detecting such flaws due to limited access. They usually must exploit something else first to gain the

needed access.

Applications frequently do not protect network traffic. They may use SSL/TLS during authentication, but

not elsewhere, exposing data and session IDs to interception. Expired or improperly configured certificates

may also be used.

© Copyright Test and Verification Solutions Ltd. 2014 Page 25

Application Security Development Guidelines

6.2. Is My Organisation vulnerable to Sensitive Data Exposure?

All web application frameworks are vulnerable to insecure cryptographic storage. Would anyone (including

internal administrators) like to gain access to protected data they aren’t authorized for? Preventing

cryptographic flaws takes careful planning. The most common problems are:

Not encrypting sensitive data everywhere it is stored, including backups;

Using home grown algorithms;

Insecure use of strong algorithms;

Continued use of proven weak algorithms;

Hard coding keys, and storing keys in unprotected stores.

Not using SSL to protect all authentication related traffic.

Not ensuring SSL is used for all resources on all private pages and services. This would protect all data

and session tokens that are exchanged. Mixed SSL on a page should be avoided since it causes user

warnings in the browser, and may expose the user’s session ID.

Not ensuring all session cookies have their ‘secure’ flag set so the browser never transmits them in the

clear.

Not verifying the server certificate is legitimate and properly configured for that server. This includes

being issued by an authorized issuer, not expired, has not been revoked, and it matches all domains

the site uses.

6.3. Examples of Sensitive Data Exposure

Example scenario #1: A site simply doesn’t use SSL for all pages that require authentication. Attacker simply

monitors network traffic (like an open wireless or their neighbourhood cable modem network), and

observes an authenticated victim’s session cookie. Attacker then replays this cookie and takes over the

user’s session.

Example scenario #2: A site has improperly configured SSL certificate which causes browser warnings for

its users. Users have to accept such warnings and continue, in order to use the site. This causes users to

get accustomed to such warnings. Phishing attack against the site’s customers lures them to a lookalike

site which doesn’t have a valid certificate, which generates similar browser warnings. Since victims are

accustomed to such warnings, they proceed on and use the phishing site, giving away passwords or other

private data.

Example scenario #3: A site simply uses standard ODBC/JDBC for the database connection, not realizing all

traffic is in the clear.

6.4. Defences for Preventing Sensitive Data Exposure

The most important aspect is to ensure that everything that should be encrypted is actually encrypted.

Then you must ensure that the cryptography is implemented properly.

Do not create cryptographic algorithms. Only use approved public algorithms such as AES, RSA public

key cryptography, and SHA-256 or better for hashing.

Do not use weak algorithms, such as MD5 / SHA1. Favor safer alternatives, such as SHA-256 or better.

Generate keys offline and store private keys with extreme care. Never transmit private keys over

insecure channels

Page 26 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

Ensure that infrastructure credentials such as database credentials or MQ queue access details are

properly secured (via tight file system permissions and controls), or securely encrypted and not easily

decrypted by local or remote users

Ensure that encrypted data stored on disk is not easy to decrypt. For example, database encryption is

worthless if the database connection pool provides unencrypted access.

Providing proper transport layer protection can affect the site design. It’s easiest to require SSL for the

entire site. For performance reasons, some sites use SSL only on private pages. Others use SSL only on

‘critical’ pages, but this can expose session IDs and other sensitive data. At a minimum, do all of the

following:

Require SSL for all sensitive pages. Non-SSL requests to these pages should be redirected to the SSL

page.

Set the ‘secure’ flag on all sensitive cookies.

Configure your SSL provider to only support strong (e.g., FIPS 140-2 compliant) algorithms.

Ensure your certificate is valid, not expired, not revoked, and matches all domains used by the site.

Backend and other connections should also use SSL or other encryption technologies.

Further protection may be provided by applying the following defences:

https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet

7. Guidelines for Missing Function Level Access Control

7.1. What is Missing Function Level Access Control?

Source: OWASP

Frequently, the only protection for a URL is that links to that page are not presented to unauthorized users.

However, a motivated, skilled, or just plain lucky attacker may be able to find and access these pages,

invoke functions, and view data. Security by obscurity is not sufficient to protect sensitive functions and

data in an application. Access control checks must be performed before a request to a sensitive function

is granted, to ensure the user is authorized to access that function.

The primary attack method for this vulnerability is called "forced browsing", which encompasses guessing

links and brute force techniques to find unprotected pages. Applications frequently allow access control

code to evolve and spread throughout a code-base, resulting in a complex model that is difficult to

understand for developers and security specialists alike. This complexity makes it likely that errors will

occur and pages will be missed, leaving them exposed.

7.2. Is My Organisation Vulnerable to Missing Function Level Access Control?

The best way to find out if an application has failed to properly restrict function level access is to verify

every application function:

1. Does the UI show navigation to unauthorized functions?

© Copyright Test and Verification Solutions Ltd. 2014 Page 27

Application Security Development Guidelines

2. Are server side authentication or authorization checks missing?

3. Are server side checks done that solely rely on information provided by the attacker?

Using a proxy, browse your application with a privileged role. Then revisit restricted pages using a less

privileged role. If the server responses are alike, the application is probably vulnerable. Some testing

proxies directly support this type of analysis.

You can also check the access control implementation in the code. Try following a single privileged request

through the code and verifying the authorization pattern. Then search the codebase to find where that

pattern is not being followed.

Automated tools are unlikely to find these problems.

7.3. Examples of Missing Function Level Access Control

Scenario 1: The attacker simply force-browses to target URLs. The following URLs require

authentication. Admin rights are also required for access to the admin_getappInfo page.

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

If an unauthenticated user can access either page, that’s a flaw. If an authenticated, non-admin, user

is allowed to access the admin_getappInfo page, this is also a flaw, and may lead the attacker to more

improperly protected admin pages.

Scenario 2: A page provides an 'action' parameter to specify the function being invoked, and different

actions require different roles. If these roles aren’t enforced, that’s a flaw.

7.4. Defences for Missing Function Level Access Control

The goal is to verify that access control is enforced consistently in the presentation layer and the business

logic for all URLs in the application.

Taking the time to plan authorization by creating a matrix to map the roles and functions of the application

is a key step in achieving protection against unrestricted URL access. Web applications must enforce access

control on every URL and business function. It is not sufficient to put access control into the presentation

layer and leave the business logic unprotected. It is also not sufficient to check once during the process to

ensure the user is authorized, and then not check again on subsequent steps. Otherwise, an attacker can

simply skip the step where authorization is checked, and forge the parameter values necessary to continue

on at the next step.

Enabling URL access control takes some careful planning. Among the most important considerations:

Ensure the access control matrix is part of the business, architecture, and design of the application

Ensure that all URLs and business functions are protected by an effective access control mechanism

that verifies the user’s role and entitlements prior to any processing taking place. Make sure this is

done during every step of the way, not just once towards the beginning of any multi-step process

Pay close attention to include/library files, especially if they have an executable extension such as .php.

Where feasible, they should be kept outside of the web root. They should verify that they are not being

directly accessed, e.g. by checking for a constant that can only be created by the library’s caller

Do not assume that users will be unaware of special or hidden URLs or APIs. Always ensure that

administrative and high privilege actions are protected

Block access to all file types that your application should never serve. Ideally, this filter would follow

the "accept known good" approach and only allow file types that you intend to serve, e.g., .html, .pdf,

Page 28 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

.php. This would then block any attempts to access log files, xml files, etc. that you never intend to

serve directly.

Keep up to date with virus protection and patches to components such as XML processors, word

processors, image processors, etc., which handle user supplied data.

8. Guidelines for Preventing Cross-Site Request Forgery (CSRF)

8.1. What is Cross-Site Request Forgery?

Source: OWASP

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a

malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to

perform an undesired function on the victim's behalf, like change the victim's e-mail address, home

address, or password, or purchase something. CSRF attacks generally target functions that cause a state

change on the server but can also be used to access sensitive data.

For most sites, browsers will automatically include with such requests any credentials associated with the

site, such as the user's session cookie, basic authentication credentials, IP address, Windows domain

credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to

distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout,

purchase item, change account information, retrieve account information, or any other function provided

by the vulnerable website.

Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are

called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that

accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the

site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is

more likely to view the page containing the attack than some random page on the Internet. The likelihood

is also increased because the victim is sure to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session

Riding, Cross-Site Reference Forgery, and Hostile Linking. Microsoft refers to this type of attack as a One-

Click attack in their threat modeling process and many places in their online documentation.

Since browsers send credentials like session cookies automatically, attackers can create malicious web

pages which generate forged requests that are indistinguishable from legitimate ones. Attackers can cause

victims to change any data the victim is allowed to change or perform any function the victim is authorized

to use.

The easiest way to check whether an application is vulnerable is to see if each link and form contains an

unpredictable token for each user. Without such an unpredictable token, attackers can forge malicious

requests. Investigation should focus on the links and forms that invoke state-changing functions, since

those are the most important CSRF targets. Check multi-step transactions as they are not inherently

immune. Attackers can easily forge a series of requests by using multiple tags or possibly JavaScript. Note

that session cookies, source IP addresses, and other information that is automatically sent by the browser

are also included in forged requests.

© Copyright Test and Verification Solutions Ltd. 2014 Page 29

Application Security Development Guidelines

8.2. Cross-Site Request Forgery Example:

The application allows a user to submit a state changing request that does not include anything secret.

Like so:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

So, the attacker constructs a request that will transfer money from the victim’s account to their account,

and then embeds this attack in an image request or iframe stored on various sites under the attacker’s

control.

<imgsrc="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#"

width="0" height="0" />

If the victim visits any of these sites while already authenticated to example.com, any forged requests will

include the user’s session info, inadvertently authorizing the request. In this example the browser will try

to display the specified zero-width (i.e., invisible) image as well. This action results in a request being

automatically sent to the web application hosted on the site. It is not important that the image URL does

not refer to a proper image, its presence will trigger the request specified in the imgsrc field anyway; this

happens provided that image download is not disabled in the browsers, which is a typical configuration.

8.3. Defences for Cross-Site Request Forgery

Checking the referrer in the client's HTTP request will prevent CSRF attacks. By ensuring the HTTP

requests have come from the original site means that the attacks from other sites will not function.

Audit the application to ascertain if its session management is vulnerable. If session management relies

only on client side values (information available to the browser); then the application is vulnerable.

“Client side values” are cookies and HTTP authentication credentials (Basic Authentication and other

forms of HTTP authentication; NOT form-based authentication, which is an application-level

authentication). For an application to not be vulnerable, it must include session-related information in

the URL, in a form of unidentifiable or unpredictable by the user.

Resources accessible via HTTP GET requests are easily vulnerable, though POST requests can be

automated via Javascript and are vulnerable as well; therefore, the use of POST alone is not enough to

correct the occurrence of CSRF vulnerabilities.

Synchronizer Token Pattern

In order to facilitate a "transparent but visible" CSRF solution, developers are encouraged to adopt the

Synchronizer Token Pattern http://www.corej2eepatterns.com/Design/PresoDesign.htm. The

synchronizer token pattern requires the generating of random "challenge" tokens that are associated

with the user's current session. These challenge tokens are then inserted within the HTML forms and

links associated with sensitive server-side operations. When the user wishes to invoke these sensitive

operations, the HTTP request should include this challenge token. It is then the responsibility of the

server application to verify the existence and correctness of this token. By including a challenge token

with each request, the developer has a strong control to verify that the user actually intended to submit

the desired requests. Inclusion of a required security token in HTTP requests associated with sensitive

business functions helps mitigate CSRF attacks as successful exploitation assumes the attacker knows

the randomly generated token for the target victim's session. This is analogous to the attacker being

able to guess the target victim's session identifier. The following synopsis describes a general approach

to incorporate challenge tokens within the request.

When a Web application formulates a request (by generating a link or form that causes a request when

submitted or clicked by the user), the application should include a hidden input parameter with a common

name such as "CSRFToken". The value of this token must be randomly generated such that it cannot be

Page 30 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

guessed by an attacker. Consider leveraging the java.security.SecureRandom class for Java applications

to generate a sufficiently long random token. Alternative generation algorithms include the use of 256-

bit BASE64 encoded hashes. Developers that choose this generation algorithm must make sure that

there is randomness and uniqueness utilized in the data that is hashed to generate the random token.

<form action="/transfer.do" method="post">

<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTViMGYwMGEwOA==">

…

</form>

In general, developers need only generate this token once for the current session. After initial generation

of this token, the value is stored in the session and is utilized for each subsequent request until the

session expires. When a request is issued by the end-user, the server-side component must verify the

existence and validity of the token in the request as compared to the token found in the session. If the

token was not found within the request or the value provided does not match the value within the

session, then the request should be aborted, token should be reset and the event logged as a potential

CSRF attack in progress.

To further enhance the security of this proposed design, consider randomizing the CSRF token parameter

name and or value for each request. Implementing this approach results in the generation of per-request

tokens as opposed to per-session tokens. Note, however, that this may result in usability concerns. For

example, the "Back" button browser capability is often hindered as the previous page may contain a

token that is no longer valid. Interaction with this previous page will result in a CSRF false positive

security event at the server. Regardless of the approach taken, developers are encouraged to protect

the CSRF token the same way they protect authenticated session identifiers, such as the use of

SSLv3/TLS.

Disclosure of Token in URL

Many implementations of this control include the challenge token in GET (URL) requests as well as POST

requests. This may be implemented as a result of sensitive server-side operations being invoked because

of embedded links in the page or other general design patterns. These patterns could be implemented

without knowledge of CSRF and an understanding of CSRF prevention design strategies. While this

control does help mitigate the risk of CSRF attacks, the unique per-session token is being exposed for

GET requests. CSRF tokens in GET requests are potentially leaked at several locations: browser history,

HTTP log files, network appliances that make a point to log the first line of an HTTP request, and Referrer

headers if the protected site links to an external site. The ideal solution is to only include the CSRF token

in POST requests and modify server-side actions that have state changing affect to only respond to POST

requests. If sensitive server-side actions are guaranteed to only ever respond to POST requests, then

there is no need to include the token in GET requests. In JavaEE web applications, however, HTTP method

scoping is seldom utilized when retrieving HTTP parameters from a request. Calls to

"HttpServletRequest.getParameter" will return a parameter value regardless if it was a GET or POST.

This is not to concede that HTTP method scoping cannot be enforced. It can be achieved if a developer

explicitly overrides doPost() in the HttpServlet class, or leverages framework specific capabilities such

as the AbstractFormController class in Spring. While this is the ideal approach, attempting to retrofit this

pattern in existing applications requires significant development time and cost.

In order for an attacker to successfully carry out a valid CSRF attack against an application that has

similar characteristics as described above (i.e. CSRF tokens on GET and POST requests, no explicitly

enforcing HTTP method scoping), several actions are typically required:

1. The victim must be interacting with the application such that a valid CSRF token is generated.

© Copyright Test and Verification Solutions Ltd. 2014 Page 31

Application Security Development Guidelines

2. The CSRF token must be transmitted in a GET request by interacting with the web page

3. A component with insight into (at least) the first line of the HTTP GET request must process the

request at some point between (and including) the browser and the server

4. This same component must capture the token in a repository that is accessible to an attacker (ex:

server log files, browser history, etc.)

5. The attacker must parse this repository and retrieve the token.

6. The attacker needs to somehow know what user owns this exposed CSRF token

7. The attacker needs to trick the target victim (i.e. the one owning the CSRF token) into interacting

with an HTML document.

8. The victim's session that holds the exposed token must still be valid (i.e. not invalidated, expired,

idle/absolute timed-out, etc.).

While placing CSRF tokens in GET requests does present a potential risk as described above, it is very

minimal. The likelihood of successfully discovering and exploiting this vulnerability is significantly low.

Coupled with strong session management practices (i.e. timeouts), frequent use of SSLv3/TLS, and

network based services that do not log this mechanism, there is little risk to the CSRF token being

exposed to an attacker. Even if the CSRF token is exposed and the attacker is somehow able to figure

how the associated user, the token is only valid for the lifetime of the session. Ultimately, the acceptance

of this risk as opposed to the cost of significant architecture design is up to the business.

Double Submit Cookies

Double submitting cookies is defined as sending the session ID cookie in two different ways for every

form request. The first is sent as a traditional header value, and again as a hidden form value. When a

user visits a site, the site should generate a (cryptographically strong) pseudorandom value and set it

as a cookie on the user's machine. This is typically referred to as the session ID. The site should require

every form submission to include this pseudorandom value as a hidden form value and also as a cookie

value. When a POST request is sent to the site, the request should only be considered valid if the form

value and the cookie value are the same. When an attacker submits a form on behalf of a user, he can

only modify the values of the form. An attacker cannot read any data sent from the server or modify

cookie values, per the same-origin policy. This means that while an attacker can send any value he wants

with the form, the attacker will be unable to modify or read the value stored in the cookie. Since the

cookie value and the form value must be the same, the attacker will be unable to successfully submit a

form unless he is able to guess the session ID value.

While this approach is effective in mitigating the risk of cross-site request forgery, including

authenticated session identifiers in HTTP parameters may increase the overall risk of session hijacking.

Architects and developers must ensure that no network appliances or custom application code or modules

explicitly log or otherwise disclose HTTP POST parameters. An attacker that is able to obtain access to

repositories or channels that leak HTTP POST parameters will be able to replay the tokens and perform

session hijacking attacks. Note, however, that transparently logging all HTTP POST parameters is a rare

occurrence across network systems and web applications as doing so will expose significant sensitive

data aside from session identifiers including passwords. Inclusion of the session identifier within HTML

can also be leveraged by cross-site scripting attacks to bypass HTTPOnly protections. Most modern

browsers prevent client-side script from accessing HTTPOnly cookies. However, this protection is lost if

HTTPOnly session identifiers are placed within HTML as client-side script can easily traverse and extract

the identifier from the DOM. Developers are still encouraged to implement the synchronizer token pattern

as described in this article: Direct Web Remoting (DWR)

Page 32 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

Java library version 2.0 has CSRF protection built in as it implements the double cookie submission

transparently.

9. Guidelines for Components with Known Vulnerabilities

9.1. What are Known Vulnerable Components?

Source: OWASP

Some vulnerable components (e.g., framework libraries) can be identified and exploited with automated

tools, expanding the threat agent pool beyond targeted attackers to include chaotic actors. The attacker

identifies a weak component through scanning or manual analysis. He/she customizes the exploit as

needed and executes the attack. It gets more difficult if the used component is deep in the application.

The full range of weaknesses is possible, including injection, broken access control, XSS, etc. The impact

could range from minimal to complete host takeover and data compromise.

9.2. Is My Organisation vulnerable to Using Components with Known

Vulnerabilities?

According to OWASP, virtually every application has these issues because most development teams don’t

focus on ensuring their components/libraries are up to date. In many cases, the developers don’t even

know all the components they are using, never mind their versions. Component dependencies make things

even worse.

In theory, it ought to be easy to discover if an organisation is currently using any vulnerable components

or libraries. Unfortunately, vulnerability reports do not always specify exactly which versions of a

component are vulnerable in a standard, searchable way. Further, not all libraries use an understandable

version numbering system. Finally, not all vulnerabilities are reported to a central clearinghouse that is

easy to search, although sites like CVE and NVD are becoming easier to search.

Determining if an organisation is vulnerable requires searching these databases, as well as keeping abreast

of project mailing lists and announcements for anything that might be a vulnerability. If one of the

components does contain a vulnerability, you should carefully evaluate whether your implementation is

actually vulnerable by checking to see if your code uses the part of the component with the vulnerability,

and whether the flaw could result in an impact an organisation would care about.

9.3. Examples of Using Components with Known Vulnerabilities:

Component vulnerabilities can cause almost any type of risk imaginable, ranging from the trivial to

sophisticated malware designed to target a specific organization. Components almost always run with the

full privilege of the application, so flaws in any component can be serious, The following two vulnerable

components were downloaded 22m times in 2011.

Apache CXF Authentication Bypass – By failing to provide an identity token, attackers could invoke any

web service with full permission. (Apache CXF is a services framework, not to be confused with the

Apache Application Server.)

© Copyright Test and Verification Solutions Ltd. 2014 Page 33

Application Security Development Guidelines

Spring Remote Code Execution – Abuse of the Expression Language implementation in Spring allowed

attackers to execute arbitrary code, effectively taking over the server.

Every application using either of these vulnerable libraries is vulnerable to attack as both of these

components are directly accessible by application users. Other vulnerable libraries, used deeper in an

application, may be harder to exploit.

9.4. Defences for Using Components with Known Vulnerabilities:

Upgrading to new component versions that fix known vulnerabilities is critical. Software projects should

have a process in place to:

1. Identify all components and the versions being used, including all dependencies. (e.g., the versions

plugin).

2. Monitor the security of these components in public databases, project mailing lists, and security

mailing lists, and keep them up to date.

3. Establish security policies governing component use, such as requiring certain software

development practices, passing security tests, and acceptable licenses.

4. Where appropriate, consider adding security wrappers around components to disable unused

functionality and/ or secure weak or vulnerable aspects of the component.

Verifying the processes described above are in place is a recommended Quality Control activity.

More information is available here:

https://docs.eudra.org/webtop/drl/objectId/090142b28240b262

10. Guidelines for Preventing Un-validated Redirects and Forwards

10.1. What are Un-validated Redirects and Forwards?

Source: OWASP

Applications frequently redirect users to other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an un-validated parameter, allowing attackers to choose the destination page. An attacker links to an un-validated redirect and tricks victims into clicking it. Victims are more likely to click on it, since the link is to a valid site. The attacker targets unsafe forward to bypass security checks. Such redirects may attempt to install malware or trick victims into disclosing passwords or other sensitive information. Unsafe forwards may allow access control bypass.

10.2. Is My Organisation vulnerable to Un-validated Redirects and Forwards?

The best way to find out if an application has any un-validated redirects or forwards is to:

1. Review the code for all uses of redirect or forward (called a transfer in .NET). For each use, identify

if the target URL is included in any parameter values. If so, verify the parameter(s) are validated to

contain only an allowed destination, or element of a destination.

Page 34 © Copyright Test and Verification Solutions Ltd. 2014

Application Security Development Guidelines

2. Also, spider the site to see if it generates any redirects (HTTP response codes 300-307, typically

302). Look at the parameters supplied prior to the redirect to see if they appear to be a target URL

or a piece of such a URL. If so, change the URL target and observe whether the site redirects to the

new target.

3. If code is unavailable, check all parameters to see if they look like part of a redirect or forward URL

destination and test those that do.

10.3. Examples of Un-validated Redirects and Forwards

Scenario 1: An application has a page called “redirect.jsp” which takes a single parameter named “url”.

The attacker crafts a malicious URL redirecting users to a malicious site that performs phishing and installs

malware.

http://www.example.com/redirect.jsp?url=evil.com

Scenario 2: An application uses forward to route requests between different parts of a site. To facilitate

this action, some pages use a parameter to indicate where the user should be sent if a transaction is

successful. In this case, the attacker crafts a URL that will pass the application’s access control check and

forward the attacker to an administrative function that they would not normally be able to access.

http://www.example.com/boring.jsp?fwd=admin.jsp

10.4. Defences for Un-validated Redirects and Forwards

Safe use of redirects and forwards can be done in a number of ways:

1. Simply avoid using redirects and forwards.

2. If used, don’t involve user parameters in calculating the destination. This can usually be done.

3. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized

for the user. It is recommended that any such destination parameters be a mapping value, rather

than the actual URL or portion of the URL, and that server side code translate this mapping to the

target URL. Applications can use ESAPI to override the sendRedirect() method to make sure all

redirect destinations are safe.

Avoiding such flaws is extremely important as they are a favourite target of phishers trying to gain the

user’s trust.

© Copyright Test and Verification Solutions Ltd. 2014 Page 35

Application Security Development Guidelines

11. About This Document

11.1. Referenced documents

Title Locator

Open Web Application

Security Project

https://www.owasp.org/index.php/Main_Page

Oracle Frequently Asked

Questions

http://www.orafaq.com/wiki/SQL_FAQ#How_does_one_e

scape_special_characters_when_writing_SQL_queries.3F

Writing Secure Code by

Howard & LeBlanc

Information security

management

http://www3.open.ac.uk/study/postgraduate/course/m88

6.htm

Black Box Penetration Test http://www.comsecglobal.com/Services.aspx

Broken Authentication and

Session Management

https://www.owasp.org/index.php/Broken_Authentication

_and_Session_Management

Data validation http://en.wikipedia.org/wiki/Data_validation

Watch for Authentication

Bypass Vulnerabilities

http://www.enterprisenetworkingplanet.com/netsecur/arti

cle.php/3916331/Watch-for-Authentication-Bypass-

Vulnerabilities.htm

Strong typing http://en.wikipedia.org/wiki/Strongly-

typed_programming_language

Black Box Security Testing

Tools

https://buildsecurityin.us-

cert.gov/bsi/articles/tools/black-box/261-BSI.html

What is iRisk? http://community.securestate.com/index.php?title=What

_is_iRisk%3F&goback=%2Egde_36874_member_179490

322

Stopping SQL Injection and

Crossing Over Cross-site

Scripting by Manoranjan Paul

http://securitymasala.files.wordpress.com/2007/11/mano

_paul_sqlinjandxss_catalyst_eu.pdf

Excess XSS by Jakob Kallin

and Irene Lobo Valbuena

http://excess-xss.com/