What is Web Application Security Testing?
A security test is a method of evaluating the security of a computer system or network by methodically validating and verifying the effectiveness of application security controls. A web application security test focuses only on evaluating the security of a web application. The process involves an active analysis of the application for any weaknesses, technical flaws, or vulnerabilities. Any security issues that are found will be presented to the system owner, together with an assessment of the impact, a proposal for mitigation or a technical solution.
What is a Vulnerability?
A vulnerability is a flaw or weakness in a system’s design, implementation, operation or management that could be exploited to compromise the system’s security objectives.
What is a Threat?
A threat is anything (a malicious external attacker, an internal user, a system instability, etc) that may harm the assets owned by an application (resources of value, such as the data in a database or in the file system) by exploiting a vulnerability.
What is a Test?
A test is an action to demonstrate that an application meets the security requirements of its stakeholders.
The Approach in Writing this Guide
The OWASP approach is open and collaborative:
- Open: every security expert can participate with his or her experience in the project. Everything is free.
- Collaborative: brainstorming is performed before the articles are written so the team can share ideas and develop a collective vision of the project. That means rough consensus, a wider audience and increased participation.
This approach tends to create a defined Testing Methodology that will be:
- Under quality control
The problems to be addressed are fully documented and tested. It is important to use a method to test all known vulnerabilities and document all the security test activities.
What is the OWASP testing methodology?
Security testing will never be an exact science where a complete list of all possible issues that should be tested can be defined. Indeed, security testing is only an appropriate technique for testing the security of web applications under certain circumstances. The goal of this project is to collect all the possible testing techniques, explain these techniques, and keep the guide updated. The OWASP Web Application Security Testing method is based on the black box approach. The tester knows nothing or has very little information about the application to be tested.
The testing model consists of:
- Tester: Who performs the testing activities
- Tools and methodology: The core of this Testing Guide project
- Application: The black box to test
The test is divided into 2 phases:
- Phase 1 Passive mode:
In the passive mode the tester tries to understand the application’s logic and plays with the application. Tools can be used for information gathering. For example, an HTTP proxy can be used to observe all the HTTP requests and responses. At the end of this phase, the tester should understand all the access points (gates) of the application (e.g., HTTP headers, parameters, and cookies). The Information Gathering section explains how to perform a passive mode test.
For example the tester could find the following:
This may indicate an authentication form where the application requests a username and a password.
The following parameters represent two access points (gates) to the application:
In this case, the application shows two gates (parameters a and b). All the gates found in this phase represent a point of testing. A spreadsheet with the directory tree of the application and all the access points would be useful for the second phase.
- Phase 2 Active mode:
In this phase the tester begins to test using the methodology described in the follow sections.
The set of active tests have been split into 11 sub-categories for a total of 91 controls:
- Information Gathering
- Configuration and Deployment Management Testing
- Identity Management Testing
- Authentication Testing
- Authorization Testing
- Session Management Testing
- Input Validation Testing
- Error Handling
- Business Logic Testing
- Client Side Testing
4.2 Testing for Information Gathering
Testing for Information Gathering includes the following articles:
4.3 Testing for Configuration and Deployment management
Understanding the deployed configuration of the server hosting the web application is almost as important as the application security testing itself. After all, an application chain is only as strong as its weakest link. Application platforms are wide and varied, but some key platform configuration errors can compromise the application in the same way an unsecured application can compromise the server.
In order to evaluate the readiness of the application platform, testing for configuration management includes the following sections:
4.4 Testing for Identity Management
Testing for Identity Management includes the following sections:
4.5 Authentication Testing
Authentication (Greek: αυθεντικός = real or genuine, from ‘authentes’ = author ) is the act of establishing or confirming something (or someone) as authentic, that is, 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 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 log on process. Testing the authentication schema means understanding how the authentication process works and using that information to circumvent the authentication mechanism.
4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)
4.6 Authorization Testing
Authorization is the concept of allowing access to resources only to those permitted to use them. Testing for Authorization means understanding how the authorization process works, and using that information to circumvent the authorization mechanism.
Authorization is a process that comes after a successful authentication, so the tester will verify this point after he holds valid credentials, associated with a well-defined set of roles and privileges. During this kind of assessment, it should be verified if it is possible to bypass the authorization schema, find a path traversal vulnerability, or find ways to escalate the privileges assigned to the tester.
4.6.1 Testing Directory traversal/file include (OTG-AUTHZ-001)
4.7 Session Management Testing
One of the core components of any web-based application is the mechanism by which it controls and maintains the state for a user interacting with it. This is referred to this as Session Management and is defined as the set of all controls governing state-full interaction between a user and the web-based application. This broadly covers anything from how user authentication is performed, to what happens upon them logging out.
HTTP is a stateless protocol, meaning that web servers respond to client requests without linking them to each other. Even simple application logic requires a user’s multiple requests to be associated with each other across a “session”. This necessitates third party solutions – through either Off-The-Shelf (OTS) middleware and web server solutions, or bespoke developer implementations. Most popular web application environments, such as ASP and PHP, provide developers with built-in session handling routines. Some kind of identification token will typically be issued, which will be referred to as a “Session ID” or Cookie.
There are a number of ways in which a web application may interact with a user. Each is dependent upon the nature of the site, the security, and availability requirements of the application. Whilst there are accepted best practices for application development, such as those outlined in the OWASP Guide to Building Secure Web Applications, it is important that application security is considered within the context of the provider’s requirements and expectations.
This chapter covers the following topics:
4.8 Input Validation Testing
The most common web application security weakness is the failure to properly validate input coming from the client or from the environment before using it. This weakness leads to almost all of the major vulnerabilities in web applications, such as cross site scripting, SQL injection, interpreter injection, locale/Unicode attacks, file system attacks, and buffer overflows.
Data from an external entity or client should never be trusted, since it can be arbitrarily tampered with by an attacker. “All Input is Evil”, says Michael Howard in his famous book “Writing Secure Code”. That is rule number one. Unfortunately, complex applications often have a large number of entry points, which makes it difficult for a developer to enforce this rule. This chapter describes Data Validation testing. This is the task of testing all the possible forms of input to understand if the application sufficiently validates input data before using it.
Input validation testing is split into the following categories:
Testing for Cross site scripting
Cross Site Scripting (XSS) testing checks if it is possible to manipulate the input parameters of the application so that it generates malicious output. Testers find an XSS vulnerability when the application does not validate their input and creates an output that is under their control. This vulnerability leads to various attacks, for example, stealing confidential information (such as session cookies) or taking control of the victim’s browser. An XSS attack breaks the following pattern: Input -> Output == cross-site scripting.
In this guide, the following types of XSS testing are discussed in details:
4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)
4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002)
Client side XSS testing, such as DOM XSS and Cross site Flashing is discussed in the Client Side testing section.
Testing for HTTP Verb Tampering and Parameter Pollution HTTP Verb Tampering tests the web application’s response to different HTTP methods accessing system objects. For every system object discovered during spidering, the tester should attempt accessing all of those objects with every HTTP method. HTTP Parameter Pollution tests the applications response to receiving multiple HTTP parameters with the same name. For example, if the parameter username is included in the GET or POST parameters twice, which one is honoured, if any.
HTTP Verb Tampering is described in
and HTTP Parameter testing techniques are presented in
4.8.5 SQL Injection (OTG-INPVAL-005)
SQL injection testing checks if it is possible to inject data into the application so that it executes a user-controlled SQL query in the back-end database. Testers find an SQL injection vulnerability if the application uses user input to create SQL queries without proper input validation. A successful exploitation of this class of vulnerability allows an unauthorized user to access or manipulate data in the database. Note that application data often represents the core asset of a company. An SQL Injection attack breaks the following pattern: Input -> Query SQL == SQL injection
SQL Injection testing is further broken down by product or vendor:
220.127.116.11 Oracle Testing
18.104.22.168 MySQL Testing
22.214.171.124 SQL Server Testing
126.96.36.199 Testing PostgreSQL
188.8.131.52 MS Access Testing
184.108.40.206 Testing for NoSQL injection
4.8.6 LDAP Injection (OTG-INPVAL-006)
LDAP injection testing is similar to SQL Injection testing. The differences are that testers use the LDAP protocol instead of SQL and the target is an LDAP Server instead of a SQL Server. An LDAP Injection attack breaks the following pattern:
Input -> Query LDAP == LDAP injection
4.8.7 ORM Injection (OTG-INPVAL-007)
ORM injection testing is similar to SQL Injection Testing. In this case, testers use a SQL Injection against an ORM-generated data access object model. From the tester’s point of view, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in the code generated by an ORM tool.
4.8.8 XML Injection (OTG-INPVAL-008)
XML injection testing checks if it possible to inject a particular XML document into the application. Testers find an XML injection vulnerability if the XML parser fails to make appropriate data validation.
An XML Injection attack breaks the following pattern:
Input -> XML doc == XML injection
4.8.9 SSI Injection (OTG-INPVAL-009)
Web servers usually give developers the ability to add small pieces of dynamic code inside static HTML pages, without having to deal with full-fledged server-side or client-side languages. This feature is incarnated by Server-Side Includes (SSI) Injection. In SSI injection testing, testers check if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution.
4.8.10 XPath Injection (OTG-INPVAL-010)
XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, testers check if it is possible to inject data into an application so that it executes user-controlled XPath queries. When successfully exploited, this vulnerability may allow an attacker to bypass authentication mechanisms or access information without proper authorization.
4.8.11 IMAP/SMTP Injection (OTG-INPVAL-011)
This threat affects all the applications that communicate with mail servers (IMAP/SMTP), generally web mail applications. In IMAP/SMTP injection testing, testers check if it possible to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized.
An IMAP/SMTP Injection attack breaks the following pattern:
Input -> IMAP/SMTP command == IMAP/SMTP Injection
4.8.12 Code Injection (OTG-INPVAL-012)
Code injection testing checks if it is possible to inject into an application data that will be later executed by the web server.
A Code Injection attack breaks the following pattern:
Input -> malicious Code == Code Injection
4.8.13 OS Commanding (OTG-INPVAL-013)
In command injection testing testers will try to inject an OS command through an HTTP request into the application.
An OS Command Injection attack breaks the following pattern:
Input -> OS Command == OS Command Injection
4.8.14 Buffer overflow (OTG-INPVAL-014)
In these tests, testers check for different types of buffer overflow vulnerabilities. Here are the testing methods for the common types of buffer overflow vulnerabilities:
220.127.116.11 Heap overflow
18.104.22.168 Stack overflow
22.214.171.124 Format string
In general Buffer overflow breaks the following pattern:
Input -> Fixed buffer or format string == overflow
4.8.15 Incubated vulnerability (OTG-INPVAL-015)
Incubated testing is a complex testing that needs more than one data validation vulnerability to work.
4.8.16 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-016)
Describes how to test for an HTTP Exploit, as HTTP Verb, HTTP Splitting, HTTP Smuggling.
In every pattern shown, the data should be validated by the application before it’s trusted and processed. The goal of testing is to verify if the application actually performs validation and does not trust its input.
Error, Exception handling & Logging.
Contact author: Eoin Keary
An important aspect of secure application development is to prevent information leakage. Error messages give an attacker great insight into the inner workings of an application.
The purpose of reviewing the Error Handling code is to assure the application fails safely under all possible error conditions, expected and unexpected. No sensitive information is presented to the user when an error occurs.
For example SQL injection is much tougher to successfully pull off without some healthy error messages. It lessens the attack footprint and our attacker would have to resort to use “blind SQL injection” which is more difficult and time consuming.
A well-planned error/exception handling strategy is important for three reasons:
- Good error handling does not give an attacker any information which is a means to an end, attacking the application
- A proper centralised error strategy is easier to maintain and reduces the chance of any uncaught errors “Bubbling up” to the front end of an application.
- Information leakage can lead to social engineering exploits.
Some development languages provide checked exceptions which mean that the compiler shall complain if an exception for a particular API call is not caught Java and C# are good examples of this. Languages like C++ and C do not provide this safety net. Languages with checked exception handling still are prone to information leakage as not all types of error are checked for.
When an exception or error is thrown we also need to log this occurrence. Sometimes this is due to bad development, but it can be the result of an attack or some other service your application relies on failing.
All code paths that can cause an exception to be thrown should check for success in order for the exception not to be thrown.
To avoid a NullPointerException we should check is the object being accessed is not null.
Generic error messages
We should use a localized description string in every exception, a friendly error reason such as “System Error – Please try again later”. When the user sees an error message, it will be derived from this description string of the exception that was thrown, and never from the exception class which may contain a stack trace, line number where the error occurred, class name or method name.
Do not expose sensitive information in exception messages. Information such as paths on the local file system is considered privileged information; any system internal information should be hidden from the user. As mentioned before an attacker could use this information to gather private user information from the application or components that make up the app.
Don’t put people’s names or any internal contact information in error messages. Don’t put any “human” information, which would lead to a level of familiarity and a social engineering exploit.
How to locate the potentially vulnerable code
In java we have the concept of an error object, the Exception object. This lives in the java package java.lang and is derived from the Throwable object Exceptions are thrown when an abnormal occurrence has occurred. Another object derived from Throwable is the Error object, which is thrown when something more serious occurs.
Information leakage can occur when developers use some exception methods, which ‘bubble’ to the user UI due to a poor error handling strategy. The methods are as follows: printStackTrace() getStackTrace()
Also another object to look at is the java.lang.system package:
setErr() and the System.err field.
In .NET a System.Exception object exists. Commonly used child objects such as ApplicationException and SystemException are used. It is not recommended that you throw or catch a SystemException this is thrown by runtime.
When an error occurs, either the system or the currently executing application reports it by throwing an exception containing information about the error, similar to java. Once thrown, an exception is handled by the application or by the default exception handler. This Exception object contains similar methods to the java implementation such as:
StackTrace Source Message HelpLink
In .NET we need to look at the error handling strategy from the point of view of global error handling and the handling of unexpected errors. This can be done in many ways and this article is not an exhaustive list. Firstly an Error Event is thrown when an unhandled exception is thrown. This is part of the TemplateControl class.
Error handling can be done in three ways in .NET
- In the web.config file’s customErrors section.
- In the global.asax file’s Application_Error sub.
- On the aspx or associated codebehind page in the Page_Error sub
The order of error handling events in .NET is as follows:
- On the Page in the Page_Error sub.
- The global.asax Application_Error sub
- The web.config file
It is recommended to look in these areas to understand the error strategy of the application.
Vulnerable Patterns for Error Handling
Page_Error is page level handling which is run on the server side. Below is an example but the error information is a little too informative and hence bad practice.
FIXME: code formatting
<script language=”C#” runat=”server”> Sub Page_Error(Source As Object, E As EventArgs) Dim message As String = “<font face=verdana color=red><h1>” & Request.Url.ToString()& “</h1>” & “<pre><font color=’red’>” & Server.GetLastError().ToString()& “</pre></font>” Response.Write(message) // display message End Sub </script>
The red text in the example above has a number of issues: Firstly it redisplays the HTTP request to the user in the form of Request.Url.ToString() Assuming there has been no data validation prior to this point we are vulnerable to cross site scripting attacks!! Secondly the error message and stack trace is displayed to the user using Server.GetLastError().ToString() which divulges internal information regarding the application.
After the Page_Error is called, the Application_Error sub is called:
Testing for business logic
Testing for business logic flaws in a multi-functional dynamic web application requires thinking in unconventional methods. If an application’s authentication mechanism is developed with the intention of performing steps 1, 2, 3 in that specific order to authenticate a user. What happens if the user goes from step 1 straight to step 3? In this simplistic example, does the application provide access by failing open; deny access, or just error out with a 500 message?
There are many examples that can be made, but the one constant lesson is “think outside of conventional wisdom”. This type of vulnerability cannot be detected by a vulnerability scanner and relies upon the skills and creativity of the penetration tester. In addition, this type of vulnerability is usually one of the hardest to detect, and usually application specific but, at the same time, usually one of the most detrimental to the application, if exploited.
Business Limits and Restrictions
Consider the rules for the business function being provided by the application. Are there any limits or restrictions on people’s behavior? Then consider whether the application enforces those rules. It’s generally pretty easy to identify the test and analysis cases to verify the application if you’re familiar with the business. If you are a third-party tester, then you’re going to have to use your common sense and ask the business if different operations should be allowed by the application.
Description of the Issue
Automated tools find it hard to understand context, hence it’s up to a person to perform these kinds of tests. The following two examples will illustrate how understanding the functionality of the application, the developer’s intentions, and some creative “out-of-the-box” thinking can break the application’s logic. The first example starts with a simplistic parameter manipulation, whereas the second is a real world example of a multi-step process leading to completely subvert the application.
Suppose an e-commerce site allows users to select items to purchase, view a summary page and then tender the sale. What if an attacker was able to go back to the summary page, maintaining their same valid session and inject a lower cost for an item and complete the transaction, and then check out?
Holding/locking resources and keeping others from purchases these items online may result in attackers purchasing items at a lower price. The countermeasure to this problem is to implement timeouts and mechanisms to ensure that only the correct price can be charged.
What if a user was able to start a transaction linked to their club/loyalty account and then after points have been added to their account cancel out of the transaction? Will the points/credits still be applied to their account?
Business Logic Test Cases
Every application has a different business process, application specific logic and can be manipulated in an infinite number of combinations. This section provides some common examples of business logic issues but in no way a complete list of all issues.
Business Logic exploits can be broken into the following categories:
In business logic data validation testing, we verify that the application does not allow users to insert “unvalidated” data into the system/application. This is important because without this safeguard attackers may be able to insert “unvalidated” data/information into the application/system at “handoff points” where the application/system believes that the data/information is “good” and has been valid since the “entry points” performed data validation as part of the business logic workflow.
4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)
In forged and predictive parameter request testing, we verify that the application does not allow users to submit or alter data to any component of the system that they should not have access to, are accessing at that particular time or in that particular manner. This is important because without this safeguard attackers may be able to “fool/trick” the application into letting them into sections of thwe application of system that they should not be allowed in at that particular time, thus circumventing the applications business logic workflow.
4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)
In integrity check and tamper evidence testing, we verify that the application does not allow users to destroy the integrity of any part of the system or its data. This is important because without these safe guards attackers may break the business logic workflow and change of compromise the application/system data or cover up actions by altering information including log files.
4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)
In process timing testing, we verify that the application does not allow users to manipulate a system or guess its behavior based on input or output timing. This is important because without this safeguard in place attackers may be able to monitor processing time and determine outputs based on timing, or circumvent the application’s business logic by not completing transactions or actions in a timely manner.
4.12.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)
In function limit testing, we verify that the application does not allow users to exercise portions of the application or its functions more times than required by the business logic workflow. This is important because without this safeguard in place attackers may be able to use a function or portion of the application more times than permissible per the business logic to gain additional benefits.
4.12.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)
In circumventing workflow and bypassing correct sequence testing, we verify that the application does not allow users to perform actions outside of the “approved/required” business process flow. This is important because without this safeguard in place attackers may be able to bypass or circumvent workflows and “checks” allowing them to prematurely enter or skip “required” sections of the application potentially allowing the action/transaction to be completed without successfully completing the entire business process, leaving the system with incomplete backend tracking information.
4.12.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)
In application mis-use testing, we verify that the application does not allow users to manipulate the application in an unintended manner.
4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)
In unexpected file upload testing, we verify that the application does not allow users to upload file types that the system is not expecting or wanted per the business logic requirements. This is important because without these safeguards in place attackers may be able to submit unexpected files such as .exe or .php that could be saved to the system and then executed against the application or system.
4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)
In malicious file upload testing, we verify that the application does not allow users to upload files to the system that are malicious or potentially malicious to the system security. This is important because without these safeguards in place attackers may be able to upload files to the system that may spread viruses, malware or even exploits such as shellcode when executed.
While there are tools for testing and verifying that business processes are functioning correctly in valid situations these tools are incapable of detecting logical vulnerabilities. For example, tools have no means of detecting if a user is able to circumvent the business process flow through editing parameters, predicting resource names or escalating privileges to access restricted resources nor do they have any mechanism to help the human testers to suspect this state of affairs.
The following are some common tool types that can be useful in identifying business logic issues.
HP Business Process Testing Software
Intercepting Proxy – To observe the request and response blocks of HTTP traffic.
- Burp Proxy – http://portswigger.net/burp/proxy.html
- Paros Proxy – http://www.parosproxy.org/
Web Browser Plug-ins – To view and modify HTTP/HTTPS headers, post parameters and observe the DOM of the Browser
- Tamper Data (for Internet Explorer) – https://addons.mozilla.org/en-us/firefox/addon/tamper-data/
- TamperIE (for Internet Explorer) – http://www.bayden.com/tamperie/
- Firebug (for Internet Explorer) – https://addons.mozilla.org/en-us/firefox/addon/firebug/ and http://getfirebug.com/
Miscellaneous Test Tools
- Web Developer toolbar – https://chrome.google.com/webstore/detail/bfbameneiokkgbdmiekhjnmfkcnldhhm
The Web Developer extension adds a toolbar button to the browser with various web developer tools. This is the official port of the Web Developer extension for Firefox.
- HTTP Request Maker – https://chrome.google.com/webstore/detail/kajfghlhfkcocafkcjlajldicbikpgnp?hl=en-US
Request Maker is a tool for penetration testing. With it you can easily capture requests made by web pages, tamper with the URL, headers and POST data and, of course, make new requests
Edit This Cookie is a cookie manager. You can add, delete, edit, search, protect and block cookies
With Session Manager you can quickly save your current browser state and reload it whenever necessary. You can manage multiple sessions, rename or remove them from the session library. Each session remembers the state of the browser at its creation time, i.e. the opened tabs and windows. Once a session is opened, the browser is restored to its state.
Swap My Cookies is a session manager, it manages your cookies, letting you login on any website with several different accounts. You can finally login into Gmail, yahoo, hotmail, and just any website you use, with all your accounts; if you want to use another account just swap profile!
- HTTP Response Browser – https://chrome.google.com/webstore/detail/mgekankhbggjkjpcbhacjgflbacnpljm?hl=en-US
Make HTTP requests from your browser and browse the response (HTTP headers and source). Send HTTP method, headers and body using XMLHttpRequest from your browser then view the HTTP status, headers and source. Click links in the headers or body to issue new requests. This plug-in formats XML responses and uses Syntax Highlighter < http://alexgorbatchev.com/ >.
- Firebug lite for Chrome – https://chrome.google.com/webstore/detail/bmagokdooijbeehmkpknfglimnifench
Firebug Lite is not a substitute for Firebug, or Chrome Developer Tools. It is a tool to be used in conjunction with these tools. Firebug Lite provides the rich visual representation we are used to see in Firebug when it comes to HTML elements, DOM elements, and Box Model shading. It provides also some cool features like inspecting HTML elements with your mouse, and live editing CSS properties.
Client Side Testing
4.12 Client-Side Testing
Client-Side testing is concerned with the execution of code on the client, typically natively within a web browser or browser plugin. The execution of code on the client-side is distinct from executing on the server and returning the subsequent content.
The following articles describe how to conduct a Client-Side test of a web application:
4.12.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)