the-web-application-hackers-handbook

Chapter 12 n Attacking Users: Cross-Site Scripting 483
When you have identified every instance in which user-controllable data is
stored by the application and later displayed back to the browser, you should
follow the same process described previously for investigating potential reflected
XSS vulnerabilities. That is, determine what input needs to be submitted to
embed valid JavaScript within the surrounding HTML, and then attempt to
circumvent any filters that interfere with the processing of your attack payload.
TIP When probing for reflected XSS, it is easy to identify which request
parameters are potentially vulnerable. You can test one parameter at a time
and review each response for any appearance of your input. With stored XSS,
however, this may be less straightforward. If you submit the same test string
as every parameter to every page, you may find this string reappearing at
multiple locations within the application. It may not be clear from the context
precisely which parameter is responsible for the appearance. To avoid this
problem, you can submit a different test string as every parameter when probing
for stored XSS flaws. For example, you can concatenate your unique string
with the name of the field it is being submitted to.
Some specific techniques are applicable when testing for stored XSS vulnerabilities
in particular types of functionality. The following sections examine
some of these in more detail.
Testing for XSS in Web Mail Applications
As we have discussed, web mail applications are inherently at risk of containing
stored XSS vulnerabilities, because they include HTML content received
directly from third parties within application pages that are displayed to users.
To test this functionality, ideally you should obtain your own e-mail account
on the application, send various XSS exploits in e-mail messages to yourself,
and view each message within the application to determine whether any of the
exploits are successful.
To perform this task in a thorough manner, you need to send all kinds of
unusual HTML content within e-mails, as we described to test for bypasses in
input filters. If you restrict yourself to using a standard e-mail client, you will
likely find that you have insufficient control over the raw message content, or
the client may itself sanitize or “clean up” your deliberately malformed syntax.
In this situation, it is generally preferable to use an alternative means of generating
e-mails that gives you direct control over the contents of messages. One
method of doing this is using the UNIX sendmail command. You need to have
configured your computer with the details of the mail server it should use to
send outgoing mail. Then you can create your raw e-mail in a text editor and
send it using this command:
sendmail -t test@example.org < email.txt