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 <!--#exec cmd="nslookup <BURP_COLLAB>" --> 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

  • CT.TE.
  • TE.CL.
  • TE.TE.

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:

​