OWASP - User contributions [en]

Identify application entry points (OTG-INFO-006)

2015-09-21T18:37:57Z

Michael Monsivais: Removed residue left from a previous edit.

{{Template:OWASP Testing Guide v4}}

== Summary ==
Enumerating the application and its attack surface is a key precursor before any thorough testing can be undertaken, as it allows the tester to identify likely areas of weakness. This section aims to help identify and map out areas within the application that should be investigated once enumeration and mapping have been completed.

== Test Objectives ==

Understand how requests are formed and typical responses from the application

== How to Test ==

Before any testing begins, the tester should always get a good understanding of the application and how the user and browser communicates with it. As the tester walks through the application, they should pay special attention to all HTTP requests (GET and POST Methods, also known as Verbs), as well as every parameter and form field that is passed to the application. In addition, they should pay attention to when GET requests are used and when POST requests are used to pass parameters to the application. It is very common that GET requests are used, but when sensitive information is passed, it is often done within the body of a POST request.

Note that to see the parameters sent in a POST request, the tester will need to use a tool such as an intercepting proxy (for example, OWASP: [[OWASP_Zed_Attack_Proxy_Project| Zed Attack Proxy (ZAP)]]) or a browser plug-in. Within the POST request, the tester should also make special note of any hidden form fields that are being passed to the application, as these usually contain sensitive information, such as state information, quantity of items, the price of items, that the developer never intended for you to see or change.

In the author's experience, it has been very useful to use an intercepting proxy and a spreadsheet for this stage of the testing. The proxy will keep track of every request and response between the tester and the application as they walk through it. Additionally, at this point, testers usually trap every request and response so that they can see exactly every header, parameter, etc. that is being passed to the application and what is being returned. This can be quite tedious at times, especially on large interactive sites (think of a banking application). However, experience will show what to look for and this phase can be significantly reduced.

As the tester walks through the application, they should take note of any interesting parameters in the URL, custom headers, or body of the requests/responses, and save them in a spreadsheet. The spreadsheet should include the page requested (it might be good to also add the request number from the proxy, for future reference), the interesting parameters, the type of request (POST/GET), if access is authenticated/unauthenticated, if SSL is used, if it's part of a multi-step process, and any other relevant notes. Once they have every area of the application mapped out, then they can go through the application and test each of the areas that they have identified and make notes for what worked and what didn't work. The rest of this guide will identify how to test each of these areas of interest, but this section must be undertaken before any of the actual testing can commence.

Below are some points of interests for all requests and responses. Within the requests section, focus on the GET and POST methods, as these appear the majority of the requests. Note that other methods, such as PUT and DELETE, can be used. Often, these more rare requests, if allowed, can expose vulnerabilities. There is a special section in this guide dedicated for testing these HTTP methods.

'''Requests:'''
* Identify where GETs are used and where POSTs are used.
* Identify all parameters used in a POST request (these are in the body of the request).
* Within the POST request, pay special attention to any hidden parameters. When a POST is sent all the form fields (including hidden parameters) will be sent in the body of the HTTP message to the application. These typically aren't seen unless a proxy or view the HTML source code is used. In addition, the next page shown, its data, and the level of access can all be different depending on the value of the hidden parameter(s).
* Identify all parameters used in a GET request (i.e., URL), in particular the query string (usually after a ? mark).
* Identify all the parameters of the query string. These usually are in a pair format, such as foo=bar. Also note that many parameters can be in one query string such as separated by a &, ~, :, or any other special character or encoding.
* A special note when it comes to identifying multiple parameters in one string or within a POST request is that some or all of the parameters will be needed to execute the attacks. The tester needs to identify all of the parameters (even if encoded or encrypted) and identify which ones are processed by the application. Later sections of the guide will identify how to test these parameters. At this point, just make sure each one of them is identified.
* Also pay attention to any additional or custom type headers not typically seen (such as debug=False).

'''Responses:'''
*Identify where new cookies are set (Set-Cookie header), modified, or added to.
*Identify where there are any redirects (3xx HTTP status code), 400 status codes, in particular 403 Forbidden, and 500 internal server errors during normal responses (i.e., unmodified requests).
*Also note where any interesting headers are used. For example, "Server: BIG-IP" indicates that the site is load balanced. Thus, if a site is load balanced and one server is incorrectly configured, then the tester might have to make multiple requests to access the vulnerable server, depending on the type of load balancing used.

=== Black Box Testing ===
'''Testing for application entry points:''' 
The following are two examples on how to check for application entry points. 

====EXAMPLE 1====
This example shows a GET request that would purchase an item from an online shopping application.

GET https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x
Host: x.x.x.x
Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy

'''Result Expected:'''

Here the tester would note all the parameters of the request such as CUSTOMERID, ITEM, PRICE, IP, and the Cookie (which could just be encoded parameters or used for session state).

====EXAMPLE 2====
This example shows a POST request that would log you into an application.

POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?service=login
Host: x.x.x.x
Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA==
CustomCookie=00my00trusted00ip00is00x.x.x.x00

Body of the POST message:

user=admin&pass=pass123&debug=true&fromtrustIP=true

'''Result Expected:'''

In this example the tester would note all the parameters as they have before but notice that the parameters are passed in the body of the message and not in the URL. Additionally, note that there is a custom cookie that is being used.

=== Gray Box Testing ===

Testing for application entry points via a Gray Box methodology would consist of everything already identified above with one addition. In cases where there are external sources from which the application receives data and processes it (such as SNMP traps, syslog messages, SMTP, or SOAP messages from other servers) a meeting with the application developers could identify any functions that would accept or expect user input and how they are formatted. For example, the developer could help in understanding how to formulate a correct SOAP request that the application would accept and where the web service resides (if the web service or any other function hasn't already been identified during the black box testing).

== Tools ==

'''Intercepting Proxy:''' 

*OWASP: [[OWASP_Zed_Attack_Proxy_Project| Zed Attack Proxy (ZAP)]]
*OWASP: [[OWASP_WebScarab_Project| WebScarab]]
* [http://www.portswigger.net/burp/ Burp Suite]
* [http://www.contextis.com/research/tools/cat/ CAT]

'''Browser Plug-in:''' 

*[http://www.bayden.com/TamperIE/ TamperIE for Internet Explorer]
*[https://addons.mozilla.org/en-US/firefox/addon/966 Tamper Data for Firefox]

== References ==

'''Whitepapers''' 

*RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 -
http://tools.ietf.org/html/rfc2616

User:Michael Monsivais

2014-08-29T00:51:14Z

Michael Monsivais: Adding parenthetical commas.

Michael Monsivais currently works as a Computer Penetration Tester for a, largely PCI-focused, penetration testing firm.

Previously, Michael has worked as a Web Application Developer and as a Systems Administrator.

He enjoys FreeBSD, OpenBSD, Linux, Python, the Bourne shell, vim, participating in CTF competitions, and reading books by firelight.

Clickjacking

2014-08-28T00:18:12Z

Michael Monsivais: Grammar Fix.

Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.

Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.

=Examples=

For example, imagine an attacker who builds a web site that has a button on it that says "click here for a free iPod". However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the "delete all messages" button directly on top of the "free iPod" button. The victim tries to click on the "free iPod" button but instead actually clicked on the invisible "delete all messages" button. In essence, the attacker has "hijacked" the user's click, hence the name "Clickjacking".

One of the most notorious examples of Clickjacking was an attack against the [http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager06.html Adobe Flash plugin settings page]. By loading this page into an invisible iframe, an attacker could trick a user into altering the security settings of Flash, giving permission for any Flash animation to utilize the computer's microphone and camera.

Clickjacking also made the news in the form of a [http://shiflett.org/blog/2009/feb/twitter-dont-click-exploit Twitter worm]. This clickjacking attack convinced users to click on a button which caused them to re-tweet the location of the malicious page, and propagated massively.

There have also been clickjacking attacks abusing Facebook's "Like" functionality. [http://threatpost.com/en_us/blogs/facebook-jacking-scams-expand-060310 Attackers can trick logged-in Facebook users to arbitrarily like fan pages, links, groups, etc]

= Defending against Clickjacking =
There are two main ways to prevent clickjacking:
# Sending the proper X-Frame-Options HTTP response headers that instruct the browser to not allow framing from other domains
# Employing defensive code in the UI to ensure that the current frame is the most top level window

For more information on Clickjacking defense, please see the the [[Clickjacking Defense Cheat Sheet]].

= References =
* https://developer.mozilla.org/en-US/docs/The_X-FRAME-OPTIONS_response_header
: Mozilla developer resource on The X-Frame-Options response header.

* [http://w2spconf.com/2010/papers/p27.pdf Busting Frame Busting: A study of clickjacking vulnerabilites on top sites]
: A study by the Stanford Web Security Group outlining problems with deployed frame busting code.

* [http://www.sectheory.com/clickjacking.htm Clickjacking, Sec Theory]
: A paper by Robert Hansen defining the term, its implications against Flash at the time of writing, and a disclosure timeline.

* [https://www.codemagi.com/blog/post/194 https://www.codemagi.com/blog/post/194]
: Framebreaking defense for legacy browsers that do not support X-Frame-Option headers.

* [[ClickjackFilter_for_Java_EE|Anti-clickjacking J2EE filter]]
: A simple J2EE servlet filter that sends anti-framing headers to the browser.

Command Injection

2014-08-26T22:43:37Z

Michael Monsivais: Correcting grammar.

{{Template:Attack}}
 
[[Category:OWASP ASDR Project]]

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==
Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation.

This attack differs from [[Code Injection]], in that code injection allows the attacker to add his own code that is then executed by the application. In [[Code Injection]], the attacker extends the default functionality of the application without the necessity of executing system commands.


==Examples ==

===Example 1===

The following code is a wrapper around the UNIX command ''cat'' which prints the contents of a file to standard output. It is also injectable:

<pre>

#include <stdio.h>
#include <unistd.h>

int main(int argc, char **argv) {
char cat[] = "cat ";
char *command;
size_t commandLength;

commandLength = strlen(cat) + strlen(argv[1]) + 1;
command = (char *) malloc(commandLength);
strncpy(command, cat, commandLength);
strncat(command, argv[1], (commandLength - strlen(cat)) );

system(command);
return (0);
}

</pre>

Used normally, the output is simply the contents of the file requested:

<pre>

$ ./catWrapper Story.txt
When last we left our heroes...

</pre>
However, if we add a semicolon and another command to the end of this line, the command is executed by catWrapper with no complaint:

<pre>
$ ./catWrapper "Story.txt; ls"
When last we left our heroes...
Story.txt doubFree.c nullpointer.c
unstosig.c www* a.out*
format.c strlen.c useFree*
catWrapper* misnull.c strlength.c useFree.c
commandinjection.c nodefault.c trunc.c writeWhatWhere.c
</pre>

If catWrapper had been set to have a higher privilege level than the standard user, arbitrary commands could be executed with that higher privilege.

===Example 2===

The following simple program accepts a filename as a command line argument, and displays the contents of the file back to the user. The program is installed setuid root because it is intended for use as a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system.

<pre>
int main(char* argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}

</pre>

Because the program runs with root privileges, the call to system() also executes with root privileges. If a user specifies a standard filename, the call works as expected. However, if an attacker passes a string of the form ";rm -rf /", then the call to system() fails to execute cat due to a lack of arguments and then plows on to recursively delete the contents of the root partition.

===Example 3===

The following code from a privileged program uses the environment variable $APPHOME to determine the application's installation directory, and then executes an initialization script in that directory.

<pre>
...
char* home=getenv("APPHOME");
char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
if (cmd) {
strcpy(cmd,home);
strcat(cmd,INITCMD);
execl(cmd, NULL);
}
...

</pre>

As in Example 2, the code in this example allows an attacker to execute arbitrary commands with the elevated privilege of the application. In this example, the attacker can modify the environment variable $APPHOME to specify a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, by controlling the environment variable, the attacker can fool the application into running malicious code.

The attacker is using the environment variable to control the command that the program invokes, so the effect of the environment is explicit in this example. We will now turn our attention to what can happen when the attacker changes the way the command is interpreted.

===Example 4===

The code below is from a web-based CGI utility that allows users to change their passwords. The password update process under NIS includes running ''make'' in the /var/yp directory. Note that since the program updates password records, it has been installed setuid root.

The program invokes make as follows:
<pre>
system("cd /var/yp && make &> /dev/null");
</pre>

Unlike the previous examples, the command in this example is hardcoded, so an attacker cannot control the argument passed to system(). However, since the program does not specify an absolute path for make, and does not scrub any environment variables prior to invoking the command, the attacker can modify their $PATH variable to point to a malicious binary named make and execute the CGI script from a shell prompt. And since the program has been installed setuid root, the attacker's version of make now runs with root privileges.

The environment plays a powerful role in the execution of system commands within programs. Functions like system() and exec() use the environment of the program that calls them, and therefore attackers have a potential opportunity to influence the behavior of these calls.

There are many sites that will tell you that Java's Runtime.exec is exactly the same as C's system function. This is not true. Both allow you to invoke a new program/process. However, C's system function passes its arguments to the shell (/bin/sh) to be parsed, whereas Runtime.exec tries to split the string into an array of words, then executes the first word in the array with the rest of the words as parameters. Runtime.exec does NOT try to invoke the shell at any point. The key difference is that much of the functionality provided by the shell that could be used for mischief (chaining commands using "&", "&&", "|", "||", etc, redirecting input and output) would simply end up as a parameter being passed to the first command, and likely causing a syntax error, or being thrown out as an invalid parameter.

===Example 5===
The following trivial code snippets are vulnerable to OS command injection on the Unix/Linux platform:

:* C:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char **argv)
{
char command[256];

if(argc != 2) {
printf("Error: Please enter a program to time!\n");
return -1;
}

memset(&command, 0, sizeof(command));

strcat(command, "time ./");
strcat(command, argv[1]);

system(command);
return 0;
}

:* If this were a suid binary, consider the case when an attacker enters the following: 'ls; cat /etc/shadow'. In the Unix environment, shell commands are separated by a semi-colon. We now can execute system commands at will!

:* Java:

'''There are many sites that will tell you that Java's Runtime.exec is exactly the same as C's system function. This is not true. Both allow you to invoke a new program/process. However, C's system function passes its arguments to the shell (/bin/sh) to be parsed, whereas Runtime.exec tries to split the string into an array of words, then executes the first word in the array with the rest of the words as parameters. Runtime.exec does NOT try to invoke the shell at any point. The key difference is that much of the functionality provided by the shell that could be used for mischief (chaining commands using "&", "&&", "|", "||", etc, redirecting input and output) would simply end up as a parameter being passed to the first command, and likely causing a syntax error, or being thrown out as an invalid parameter.'''

===Example 6===
The following PHP code snippet is vulnerable to a command injection attack:

<pre>
<?php
print("Please specify the name of the file to delete");
print("");
$file=$_GET['filename'];
system("rm $file");
?>
</pre>

The following request and response is an example of a successful attack:

Request
<pre>
http://127.0.0.1/delete.php?filename=bob.txt;id
</pre>

Response
<pre>
Please specify the name of the file to delete

uid=33(www-data) gid=33(www-data) groups=33(www-data)
</pre>


==Related [[Attacks]]==
* [[Code Injection]]
* [[Blind SQL Injection]]
* [[Blind XPath Injection]]
* [[LDAP injection]]
* [[Relative Path Traversal]]
* [[Absolute Path Traversal]]


==Related [[Controls]]==
* [[:Category:Input Validation]]

Ideally, a developer should use existing API for their language. For example (Java): Rather than use Runtime.exec() to issue a 'mail' command, use the available Java API located at javax.mail.*

If no such available API exists, the developer should scrub all input for malicious characters. Implementing a positive security model would be most efficient. Typically, it is much easier to define the legal characters than the illegal characters.

==References==
* [http://cwe.mitre.org/data/definitions/77.html CWE-77: Command Injection]
* [http://cwe.mitre.org/data/definitions/78.html CWE-78: OS Command Injection]
* http://blog.php-security.org/archives/76-Holes-in-most-preg_match-filters.html

[[Category:Injection Attack]]
[[Category:Injection]]
[[Category:Attack]]
[[Category:Externally Linked Page]]

Clickjacking

2014-08-26T22:40:12Z

Michael Monsivais: Removing previous editing artifact.

Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page. Thus, the attacker is "hijacking" clicks meant for their page and routing them to another page, most likely owned by another application, domain, or both.

Using a similar technique, keystrokes can also be hijacked. With a carefully crafted combination of stylesheets, iframes, and text boxes, a user can be led to believe they are typing in the password to their email or bank account, but are instead typing into an invisible frame controlled by the attacker.

=Examples=

For example, imagine an attacker who builds a web site that has a button on it that says "click here for a free iPod". However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the "delete all messages" button directly on top of the "free iPod" button. The victim tries to click on the "free iPod" button but instead actually clicked on the invisible "delete all messages" button. In essence, the attacker has "hijacked" the user's click, hence the name "Clickjacking".

One of the most notorious examples of Clickjacking was an attack against the [http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager06.html Adobe Flash plugin settings page]. By loading this page into an invisible iframe, an attacker could trick a user into altering the security settings of Flash, giving permission for any Flash animation to utilize the computer's microphone and camera.

Clickjacking also made the news in the form of a [http://shiflett.org/blog/2009/feb/twitter-dont-click-exploit Twitter worm]. This clickjacking attack convinced users to click on a button which caused them to re-tweet the location of the malicious page, and propagated massively.

There has also been clickjacking attacks abusing Facebook's "Like" functionality. [http://threatpost.com/en_us/blogs/facebook-jacking-scams-expand-060310 Attackers can trick logged-in Facebook users to arbitrarily like fan pages, links, groups, etc]

= Defending against Clickjacking =
There are two main ways to prevent clickjacking:
# Sending the proper X-Frame-Options HTTP response headers that instruct the browser to not allow framing from other domains
# Employing defensive code in the UI to ensure that the current frame is the most top level window

For more information on Clickjacking defense, please see the the [[Clickjacking Defense Cheat Sheet]].

= References =
* https://developer.mozilla.org/en-US/docs/The_X-FRAME-OPTIONS_response_header
: Mozilla developer resource on The X-Frame-Options response header.

* [http://w2spconf.com/2010/papers/p27.pdf Busting Frame Busting: A study of clickjacking vulnerabilites on top sites]
: A study by the Stanford Web Security Group outlining problems with deployed frame busting code.

* [http://www.sectheory.com/clickjacking.htm Clickjacking, Sec Theory]
: A paper by Robert Hansen defining the term, its implications against Flash at the time of writing, and a disclosure timeline.

* [https://www.codemagi.com/blog/post/194 https://www.codemagi.com/blog/post/194]
: Framebreaking defense for legacy browsers that do not support X-Frame-Option headers.

* [[ClickjackFilter_for_Java_EE|Anti-clickjacking J2EE filter]]
: A simple J2EE servlet filter that sends anti-framing headers to the browser.