This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Web Application Security Guidance"

From OWASP
Jump to: navigation, search
(Draft)
 
(Draft)
Line 1: Line 1:
  
 
Service Side Attacks
 
Service Side Attacks
 +
 
These are attacks that target the web application/service directly.
 
These are attacks that target the web application/service directly.
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! Header text !! Header text !! Header text !! Header text !! Header text !! Header text
+
! Issue Name !! Description !! How to test for the issue !! How identify the issue during code review !! Remediation
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example
+
|Command Injection
 +
| OS command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications. || Appending a semicolon to the end of a URL query parameter followed by an operating system command, will execute the command. %3B is url encoded and decodes to semicolon. This is because the ; is interpreted as a command seperator.
 +
Example: <nowiki>http://sensitive/something.php?dir=%3Bcat%20/etc/passwd</nowiki>
 +
 
 +
If the applucation responds with the output of the /etc/passwd file then you know the attack has been successful.
 +
 
 +
Many web application scanners can be used to test for this attack as they inject variations of command injections and test the response.
 +
 
 +
Equally Static Code Analysis tools check the data flow of untrusted user input into a web application and check if the data is then entered into a dangerous method which executes the user input as a command.
 +
| During code review, check if any command execute methods are called and in unvalidated user input are taken as data for that command. || When ever possible minimize the use of system command execution for example via Java's
 +
<code>Runtime.exec()</code>
 +
 
 +
However if it is required then the input must be sanitized for any special characters. For example only whitelist alphanumeric characters.
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example
+
| SQL Injection || An SQL injection attack consists of insertion or "injection" of either a partial or complete SQL query via the data input or transmitted from the client (browser) to the web application. A successful SQL injection attack can read sensitive data from the database, modify database data (insert/update/delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file existing on the DBMS file system or write files into the file system, and, in some cases, issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.
 +
SQL Injection attacks can be divided into the following three classes:
 +
 
 +
* '''Inband:''' data is extracted using the same channel that is used to inject the SQL code. This is the most straightforward kind of attack, in which the retrieved data is presented directly in the application web page.
 +
* '''Out-of-band:''' data is retrieved using a different channel (e.g., an email with the results of the query is generated and sent to the tester).
 +
* '''Inferential or Blind:''' there is no actual transfer of data, but the tester is able to reconstruct the information by sending particular requests and observing the resulting behavior of the DB Server.
 +
| '''Automated Exploitation'''
 +
Most of the situation and techniques below here can be performed in a automated way using some tools. In this article the tester can find information how to perform an automated auditing using SQLMap:
 +
 
 +
[[Automated Audit using SQLMap|https://www.owasp.org/index.php/Automated_Audit_using_SQLMap]]
 +
 
 +
Equally Static Code Analysis Data flow rules can detect of unsanitized user controlled input can change the SQL query.
 +
 
 +
'''Stored Procedure Injection'''
 +
 
 +
When using dynamic SQL within a stored procedure, the application must properly sanitize the user input to eliminate the risk of code injection. If not sanitized, the user could enter malicious SQL that will be executed within the stored procedure.
 +
 
 +
'''Time delay Exploitation technique'''
 +
 
 +
The time delay exploitation technique is very useful when the tester find a Blind SQL Injection situation, in which nothing is known on the outcome of an operation. This technique consists in sending an injected query and in case the conditional is true, the tester can monitor the time taken to for the server to respond. If there is a delay, the tester can assume the result of the conditional query is true. This exploitation technique can be different from DBMS to DBMS (check DBMS specific section).
 +
 
 +
<nowiki>http://www.example.com/product.php?id=10</nowiki> AND IF(version() like ‘5%’, sleep(10), ‘false’))--
 +
 
 +
In this example the tester if checking whether the MySql version is 5.x or not, making the server to delay the answer by 10 seconds. The tester can increase the delay time and monitor the responses. The tester also doesn’t need to wait for the response. Sometimes he can set a very high value (e.g. 100) and cancel the request after some seconds.
 +
 
 +
'''Out of band Exploitation technique'''
 +
 
 +
This technique is very useful when the tester find a Blind SQL Injection situation, in which nothing is known on the outcome of an operation. The technique consists of the use of DBMS functions to perform an out of band connection and deliver the results of the injected query as part of the request to the tester’s server. Like the error based techniques, each DBMS has its own functions. Check for specific DBMS section.
 +
| During code review please check for any queries to the database are not done via prepared statements.
 +
 
 +
If dynamic statements are being made please check if the data is sanitized before used as par of the statement.
 +
| Ensure queries to the database are done via prepared statements.
 +
 
 +
If dynamic statements are being made please ensure the data is sanitized before used as par of the statement.
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example
+
| XML External Entity Injection (XXE) || '''External Entity:''' The set of valid entities can be extended by defining new entities.
 +
If the definition of an entity is a URI, the entity is called an external entity. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, e.g., a file on the local machine or on a remote systems.
 +
 
 +
This behavior exposes the application to XML eXternal Entity (XXE) attacks, which can be used to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems.
 +
| To test for XXE vulnerabilities, one can use the following input:
 +
<code><?xml version="1.0" encoding="ISO-8859-1"?></code>
 +
 
 +
<code><!DOCTYPE foo [</code>
 +
 
 +
<code><!ELEMENT foo ANY ></code>
 +
 
 +
<code><!ENTITY xxe SYSTEM "[[:file:///dev/random]]" >]><foo>&xxe;</foo></code>
 +
 
 +
This test could crash the web server (on a UNIX system), if the XML parser attempts to substitute the entity with the contents of the /dev/random file.
 +
 
 +
Static code analysis tools can pick up XXE attacks in code by checking if External Entities are accepted by the application or not.
 +
| Check the new feature if it takes in XML documents and if the xml parsering engine is configured to accept inline DTD. || XML processor should be configured to use onlu a locally defined Document Type Definition (DTD), and disallow any inline DTD that is specified within user supplied XML documents.
 +
 
 +
Each XML parsing engine has their own way of disabling inline DTD to prevent XXE, therefore please check the parsers documentation in order to learn how to disable inline DTD.
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example
+
| Predictable random value || Session Cookies need to be long so the key space is long enough that burte-force attacks, the automated attack of trying every combination till its success full is not feasible.
 +
 
 +
The second requirement is that the session tokens are not predictable, therefore if the attacker can derive a sequence from the session generation, the attacker is able to predict valid sessions and hijack user accounts.
 +
| To test this make multiple requests to the web application requesting new session cookies every-time. If the session cookies are not randomly generated with sufficient entropy the it will be apparent through statistical analysis of the results.
 +
Tools such as burp suites can run such checks.
 +
 
 +
Static Code Analysis can detect instances where predictable random values are generated.
 +
| If the feature requires a random number for a session token or other sensitive requests, please check if it uses entropy and a pesudo random number generator. || Please use a cryptographically strong random number generator. 
 +
In Java it is:
 +
 
 +
<code>java.security.SecureRandom</code>
 +
 
 +
In .Net it is:
 +
 
 +
<code>System.Security.Cryptography.RandomNumberGenerator</code>
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example
+
| Insecure Data De-Serialisation || The process of converting application data to another format (usually binary) suitable for transportation is called serialization. The process of reading data back in after it has been serialized is called unserialization. The vulnerability arises when developers write code that accepts serialized data from users and attempt to unserialize it in securely for use in the program resulting in remote code execution. 
 +
See: http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
 +
| The first thing you need to do is find a part of the application that takes a serialized object as input. It would help if you knew what a serialized object looked like. Luckily they’re pretty easy to spot. Let’s take a look at the hexdump of some Jenkins traffic:
 +
There are two separate Java objects in the above screenshot. One is base64 encoded and can be seen in the rightmost column beginning with “rO0AB”.
 +
 
 +
The other is raw binary going over the wire, so we’ll have to look at the hex column in the middle. It begins with the bytes “ac ed 00 05 73 72”.
 +
 
 +
This is what serialized Java objects look like, they can be identified by this header. They always begin with “ac ed 00 05…” and when that is base64 encoded it comes out as “rO0…”. Keep an eye open for those two strings.
 +
 
 +
Once you have identified a serialized object generate a payload for testing. Go download the “ysoserial” tool from GitHub. Run it with something like this:
 +
{| class="wikitable"
 +
|1
 +
|java  -jar /path/to/ysoserial-0.0.2-SNAPSHOT-all.jar  CommonsCollections1 'touch /tmp/pwned' > payload.out
 +
|}
 +
 
 +
Now when you’re testing, if you see a file created at /tmp/pwned, you know it ran, and the test is successful.
 +
| During code review, check if the feature accepts serialized untrusted user data. Equally if user data is un-serialized using an unsafe class such as org/apache/commons/collections/functors/InvokerTransformer.class then it is exposed to this issue. || IBM have releases guidance on how to un-serialized untrusted user data securely here: <nowiki>http://www.ibm.com/developerworks/library/se-lookahead/</nowiki>
 +
An implementation of the guidance can be found here <nowiki>https://github.com/kantega/notsoserial</nowiki>
 +
 
 +
Note: <nowiki>https://github.com/kantega/notsoserialNotSoSerial</nowiki> requires java app invocation changes to work and will work with any application without modification.  It does configuration-driven white or black listing via lookahead.
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example
+
| Example || Example || Example || Example || Example  
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example
+
| Example || Example || Example || Example || Example  
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example
+
| Example || Example || Example || Example || Example  
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example
+
| Example || Example || Example || Example || Example  
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example
+
| Example || Example || Example || Example || Example  
 
|}
 
|}
  
 
Client Side Attacks
 
Client Side Attacks
 +
 
These are attacks that target the user's browser as they require use action to be successful.
 
These are attacks that target the user's browser as they require use action to be successful.
 
{| class="wikitable"
 
{| class="wikitable"
 +
!Issue Name
 +
!Description
 +
!How to test for the issue
 +
!How identify the issue during code review
 +
!Remediation
 
|-
 
|-
−
! Header text !! Header text !! Header text !! Header text !! Header text !! Header text !! Header text !! Header text !! Header text
+
!
−
|-
+
!
−
| Example || Example || Example || Example || Example || Example || Example || Example || Example
+
!
−
|-
+
!
−
| Example || Example || Example || Example || Example || Example || Example || Example || Example
+
!
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example || Example || Example || Example
+
!
 +
!
 +
!
 +
!
 +
!
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example || Example || Example || Example
+
|
 +
|
 +
|
 +
|
 +
|
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example || Example || Example || Example
+
|
 +
|
 +
|
 +
|
 +
|
 
|-
 
|-
−
| Example || Example || Example || Example || Example || Example || Example || Example || Example
+
|
 +
|
 +
|
 +
|
 +
|
 
|}
 
|}
 +
I

Revision as of 21:57, 13 November 2017

Service Side Attacks

These are attacks that target the web application/service directly.

Issue Name Description How to test for the issue How identify the issue during code review Remediation
Command Injection OS command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications. Appending a semicolon to the end of a URL query parameter followed by an operating system command, will execute the command. %3B is url encoded and decodes to semicolon. This is because the ; is interpreted as a command seperator.

Example: http://sensitive/something.php?dir=%3Bcat%20/etc/passwd

If the applucation responds with the output of the /etc/passwd file then you know the attack has been successful.

Many web application scanners can be used to test for this attack as they inject variations of command injections and test the response.

Equally Static Code Analysis tools check the data flow of untrusted user input into a web application and check if the data is then entered into a dangerous method which executes the user input as a command.

During code review, check if any command execute methods are called and in unvalidated user input are taken as data for that command. When ever possible minimize the use of system command execution for example via Java's

Runtime.exec()

However if it is required then the input must be sanitized for any special characters. For example only whitelist alphanumeric characters.

SQL Injection An SQL injection attack consists of insertion or "injection" of either a partial or complete SQL query via the data input or transmitted from the client (browser) to the web application. A successful SQL injection attack can read sensitive data from the database, modify database data (insert/update/delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file existing on the DBMS file system or write files into the file system, and, in some cases, issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.

SQL Injection attacks can be divided into the following three classes:

  • Inband: data is extracted using the same channel that is used to inject the SQL code. This is the most straightforward kind of attack, in which the retrieved data is presented directly in the application web page.
  • Out-of-band: data is retrieved using a different channel (e.g., an email with the results of the query is generated and sent to the tester).
  • Inferential or Blind: there is no actual transfer of data, but the tester is able to reconstruct the information by sending particular requests and observing the resulting behavior of the DB Server.
 Automated Exploitation

Most of the situation and techniques below here can be performed in a automated way using some tools. In this article the tester can find information how to perform an automated auditing using SQLMap:

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

Equally Static Code Analysis Data flow rules can detect of unsanitized user controlled input can change the SQL query.

Stored Procedure Injection

When using dynamic SQL within a stored procedure, the application must properly sanitize the user input to eliminate the risk of code injection. If not sanitized, the user could enter malicious SQL that will be executed within the stored procedure.

Time delay Exploitation technique

The time delay exploitation technique is very useful when the tester find a Blind SQL Injection situation, in which nothing is known on the outcome of an operation. This technique consists in sending an injected query and in case the conditional is true, the tester can monitor the time taken to for the server to respond. If there is a delay, the tester can assume the result of the conditional query is true. This exploitation technique can be different from DBMS to DBMS (check DBMS specific section).

http://www.example.com/product.php?id=10 AND IF(version() like ‘5%’, sleep(10), ‘false’))--

In this example the tester if checking whether the MySql version is 5.x or not, making the server to delay the answer by 10 seconds. The tester can increase the delay time and monitor the responses. The tester also doesn’t need to wait for the response. Sometimes he can set a very high value (e.g. 100) and cancel the request after some seconds.

Out of band Exploitation technique

This technique is very useful when the tester find a Blind SQL Injection situation, in which nothing is known on the outcome of an operation. The technique consists of the use of DBMS functions to perform an out of band connection and deliver the results of the injected query as part of the request to the tester’s server. Like the error based techniques, each DBMS has its own functions. Check for specific DBMS section.

During code review please check for any queries to the database are not done via prepared statements.

If dynamic statements are being made please check if the data is sanitized before used as par of the statement.

Ensure queries to the database are done via prepared statements.

If dynamic statements are being made please ensure the data is sanitized before used as par of the statement.

XML External Entity Injection (XXE) External Entity: The set of valid entities can be extended by defining new entities.

If the definition of an entity is a URI, the entity is called an external entity. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, e.g., a file on the local machine or on a remote systems.

This behavior exposes the application to XML eXternal Entity (XXE) attacks, which can be used to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems.

To test for XXE vulnerabilities, one can use the following input:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

This test could crash the web server (on a UNIX system), if the XML parser attempts to substitute the entity with the contents of the /dev/random file.

Static code analysis tools can pick up XXE attacks in code by checking if External Entities are accepted by the application or not.

Check the new feature if it takes in XML documents and if the xml parsering engine is configured to accept inline DTD. XML processor should be configured to use onlu a locally defined Document Type Definition (DTD), and disallow any inline DTD that is specified within user supplied XML documents.

Each XML parsing engine has their own way of disabling inline DTD to prevent XXE, therefore please check the parsers documentation in order to learn how to disable inline DTD.

Predictable random value Session Cookies need to be long so the key space is long enough that burte-force attacks, the automated attack of trying every combination till its success full is not feasible.

The second requirement is that the session tokens are not predictable, therefore if the attacker can derive a sequence from the session generation, the attacker is able to predict valid sessions and hijack user accounts.

To test this make multiple requests to the web application requesting new session cookies every-time. If the session cookies are not randomly generated with sufficient entropy the it will be apparent through statistical analysis of the results.

Tools such as burp suites can run such checks.

Static Code Analysis can detect instances where predictable random values are generated.

If the feature requires a random number for a session token or other sensitive requests, please check if it uses entropy and a pesudo random number generator. Please use a cryptographically strong random number generator.

In Java it is:

java.security.SecureRandom

In .Net it is:

System.Security.Cryptography.RandomNumberGenerator

Insecure Data De-Serialisation The process of converting application data to another format (usually binary) suitable for transportation is called serialization. The process of reading data back in after it has been serialized is called unserialization. The vulnerability arises when developers write code that accepts serialized data from users and attempt to unserialize it in securely for use in the program resulting in remote code execution.

See: http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

The first thing you need to do is find a part of the application that takes a serialized object as input. It would help if you knew what a serialized object looked like. Luckily they’re pretty easy to spot. Let’s take a look at the hexdump of some Jenkins traffic:

There are two separate Java objects in the above screenshot. One is base64 encoded and can be seen in the rightmost column beginning with “rO0AB”.

The other is raw binary going over the wire, so we’ll have to look at the hex column in the middle. It begins with the bytes “ac ed 00 05 73 72”.

This is what serialized Java objects look like, they can be identified by this header. They always begin with “ac ed 00 05…” and when that is base64 encoded it comes out as “rO0…”. Keep an eye open for those two strings.

Once you have identified a serialized object generate a payload for testing. Go download the “ysoserial” tool from GitHub. Run it with something like this:

1 java -jar /path/to/ysoserial-0.0.2-SNAPSHOT-all.jar CommonsCollections1 'touch /tmp/pwned' > payload.out

Now when you’re testing, if you see a file created at /tmp/pwned, you know it ran, and the test is successful.

During code review, check if the feature accepts serialized untrusted user data. Equally if user data is un-serialized using an unsafe class such as org/apache/commons/collections/functors/InvokerTransformer.class then it is exposed to this issue. IBM have releases guidance on how to un-serialized untrusted user data securely here: http://www.ibm.com/developerworks/library/se-lookahead/

An implementation of the guidance can be found here https://github.com/kantega/notsoserial

Note: https://github.com/kantega/notsoserialNotSoSerial requires java app invocation changes to work and will work with any application without modification.  It does configuration-driven white or black listing via lookahead.

Example Example Example Example Example
Example Example Example Example Example
Example Example Example Example Example
Example Example Example Example Example
Example Example Example Example Example

Client Side Attacks

These are attacks that target the user's browser as they require use action to be successful.

Issue Name Description How to test for the issue How identify the issue during code review Remediation

I

Retrieved from "https://wiki.owasp.org/index.php?title=Web_Application_Security_Guidance&oldid=235389"