the-web-application-hackers-handbook

Chapter 21 n A Web Application Hacker’s Methodology 835
7.5.9 If you succeed in gaining write access to arbitrary files on the server,
examine whether any of the following attacks are feasible in order to
escalate your attack:
n Creating scripts in users’ startup folders
n Modifying files such as in.ftpd to execute arbitrary commands when
a user next connects
n Writing scripts to a web directory with execute permissions and calling
them from your browser
7.6 Test for Script Injection
7.6.1 For each fuzz test you have performed, review the results for the string
111111 on its own (that is, not preceded by the rest of the test string).
You can quickly identify these in Burp Intruder by Shift-clicking the
heading for the 111111 Grep string to group all the results containing
this string. Look for any that do not have a check in the Payload Grep
column. Any cases identified are likely to be vulnerable to injection of
scripting commands.
7.6.2 Review all the test cases that used script injection strings, and identify
any containing scripting error messages that may indicate that your input
is being executed but caused an error. These may need to be fine-tuned
to perform successful script injection.
7.6.3 If the application appears to be vulnerable, verify this by injecting further
commands specific to the scripting platform in use. For example,
you can use attack payloads similar to those used when fuzzing for OS
command injection:
system(‘ping%20127.0.0.1’)
7.7 Test for File Inclusion
7.7.1 If you received any incoming HTTP connections from the target application’s
infrastructure during your fuzzing, the application is almost
certainly vulnerable to remote file inclusion. Repeat the relevant tests
in a single-threaded and time-throttled way to determine exactly which
parameters are causing the application to issue the HTTP requests.
7.7.2 Review the results of the file inclusion test cases, and identify any that
caused an anomalous delay in the application’s response. In these cases,
it may be that the application itself is vulnerable but that the resulting
HTTP requests are timing out due to network-level filters.