4.7 Input Validation Testing

Input Validation Testing

4.7.1 Testing for Reflected Cross Site Scripting

Identify variables/parameters that are reflected in responses.

(?:\?|&)(\w+)=

Assess the input they accept and the encoding that gets applied on return (if any).

"><img src=1 onerror=alert(1)>
<script>alert(2)</script>"<

Evidence:

4.7.2 Testing for Stored Cross Site Scripting

Identify stored input that is reflected on the client-side.
Assess the input they accept and the encoding that gets applied on return (if any).
Check if the input is only sanitized on client or server side.

You can use the previous payloads.

Evidence:

4.7.3 Testing for HTTP Verb Tampering

This section has been merged into: Test HTTP Methods

Evidence:

4.7.4 Testing for HTTP Parameter Pollution

Identify any form or action that allows user-supplied input.
Test for HPP vulnerabilities simply append the same parameter to the GET and POST data but with a different value assigned.
Send a request with the same parameter repeated twice but with a different value, like page?par1=val1&par1=HPP_TEST1.

The results should be that the application takes the both parameters instead of only one of them.

Evidence:

4.7.5 Testing for SQL Injection

Identify any form or action that allows user-supplied input.
Introduce SQL statements to trigger errors. If there are errors, try to exploit the vulnerability.
Introduce SQL statements based on time and check if there are differences in the response time.
Perform the same actions but with NoSQL statements.

SQL wordlist & NoSQL Payloads.

Evidence:

4.7.6 Testing for LDAP Injection

Identify any form or action that allows user-supplied input.
Introduce LDAP statements to see how the application behaves.

LDAP Wordlist.

Evidence:

4.7.7 Testing for XML Injection

Identify XML injection points.
Try to upload XML files.
Try to exploit XXE vulnerabilities.

Evidence:

4.7.8 Testing for SSI Injection

Check that the application contains .shtml files.
Inject the payload  in different inputs to see if it is executed. Also, try to inject it on headers like User-Agent or Referer.
Try to upload files with SSI payloads.

Evidence:

4.7.9 Testing for XPath Injection

Check if the application uses XML queries.
Perform XPath attacks

Evidence:

4.7.10 Testing for IMAP SMTP Injection

Look for endpoints that triggers sending emails
Understand the data flow and deployment structure of the system.
Discover hidden parameters
Try to inject IMAP text or HTML tags.
Using webmail, check if the mails receive contains internal network information.

Evidence:

4.7.11 Testing for Code Injection

Identify injection points where you can inject files or paths into the application. Here you have some examples:
File Access parameters

[?&](file|filepath|filename|dir|folder|download|upload|doc|image|path|include|view|resource|asset|content|icon|logfile)=

Website/URL Access Parameters

[?&](url|link|redirect|target|site|page|navigate|ref|callback|host|return|next)=

Asses the injection points.

UNIX FI & Windows FI

Evidence:

4.7.12 Testing for Command Injection

Identify injection points where you can inject code into the application. Here you have some examples:

[?&](cmd|exec|action|run|query|operation|execute|task|process|shell|module|method|command|do)=

Windows RCE & UNIX RCE

Evidence:

4.7.13 Testing for Format String Injection

This vulnerability is mainly oriented to a white box approach. However, you can tested by inserting the value %s on the input parameters of the application.

alice
%s%s%s%n
%p%p%p%p%p
{event.__init__.__globals__[CONFIG][SECRET_KEY]}

Evidence:

4.7.14 Testing for Incubated Vulnerability

Identify injections that are stored and require a recall step to the stored injection.
Understand how a recall step could occur.
Set listeners or activate the recall step if possible.

Evidence:

4.7.15 Testing for HTTP Splitting Smuggling

Identify if there are are functions where user input gets reflected into HTTP response headers.
- Inject %0d%0a, which represents the CRLF.
- Try to inject headers like Location or Set-Cookie.
Perform HTTP Smuggling attack based on the following PoCs

Evidence:

4.7.16 Testing for HTTP Incoming Requests

Monitor all incoming and outgoing HTTP requests to the Web Server to inspect any suspicious requests.

Evidence:

4.7.17 Testing for Host Header Injection

Modify the value of the Host header in different endpoints on the application.
Try to inject %0d%0a, which represents the CRLF, in order to perform HTTP Splitting.
Try to use custom host headers to check if it changes the contents on the application.

X-Forwarded-For: 127.0.0.1
X-Forwarded-Host: 127.0.0.1
X-Forwarded-IP: 127.0.0.1
X-Forwarded-Server: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Host: 127.0.0.1
X-HTTP-Host-Override: 127.0.0.1
X-Client: 127.0.0.1
X-Host: 127.0.0.1

Evidence:

4.7.18 Testing for Server-side Template Injection

Identify user input that gets reflected
Insert SSTI polyglots ${{<%[%'"}}%\ or payloads.

a{{7*7}}b
a{{7*7}}
{7*7} 
${7*7} 
{{7*7}} 
<% 7*7 %> 
[% 7*7 %]

Identify the templating engine.
Build the exploit.

Evidence:

4.7.19 Testing for Server-Side Request Forgery

Identify function in the application that performs requests to external or internal sources or third parties.
Identify parameters with values that points to internal or external sources.
Test if the injection points are exploitable as in the "4.7.11 Testing for Code Injection".
Asses the severity of the vulnerability.

Evidence:

Last updated 1 year ago