Finding Stored and Reﬂ ected HTML Injections

To find stored and reflected HTML injections, attempt to inject script into every form input (visible and hidden) and every parameter in a GET or POST request. Assume that every value in the parameter/value pair is potentially vulnerable. Even try to inject HTML in new parameters like this:

Or you can add parameters/value pairs found other parts of a the web application and inject the script in the value part. The number of potential HTML injection points may seem endless on most modern web applications, and usually one or two will work.

Don’t leave a single parameter value pair, URL, HTTP header, and so on, untouched. Try injecting script everywhere! It’s truly amazing where HTML injection works.

Sometimes simple HTML injection test strings like <script>alert(1)</script>

do not work because the test strings do not appear in the HTML body of the response.

For instance, imagine that a request to http://search.engine.com/search?p=

<form input="text" name="p" value="<script>alert(1)</script>">

Unfortunately, the script tags are treated as a string for the form input field and not executed. Instead, try http://search.engine.com/search?p=”><script>alert (1)</script>. This might respond with the HTML:

<form input="text" name="p" value=""><script>alert(1)</script>">

Note that the script tags are no longer locked within the value parameter and can now be executed.

To illustrate the many different places where user input can be injected and how you can inject HTML via user input, consider the following HTTP request and response pair that places user input into 10 different places within the response. Suppose a user made the following request:

http://somewhere.com/s?a1=USER_INPUT1&a2=USER_INPUT2&a3=USER_INPUT3&

a4=USER_INPUT4&a5=USER_INPUT5&a6=USER_INPUT6&a7=USER_INPUT7&

a8=USER_INPUT8&a9=USER_INPUT9&a10=USER_INPUT10

And suppose the server responded with this:

if (something.equals('USERINPUT5')) { alert('something');

}

</script>

<body>

<a href="http://somewhere.com/USERINPUT6">click me</a>

<a href='USERINPUT7'>click me 2</a>

<p onclick="window.open('USERINPUT9')">some paragraph</p>

</body>

</html>

Each user input can potentially be exploited in many ways. We now present a few ways to attempt to inject HTML with each user input.

USERINPUT1 is placed in the cookie HTTP header. If an attacker can inject semico-lons (;) into USERINPUT1, then the attacker can fiddle with the cookie’s security con-trols and possibly other parts of the cookie. If an attacker can inject new lines (\n, URL encoded value %0d) and/or new lines and carriage returns (\r\n, URL encoded value

%0a%0d), then the attacker can add HTTP headers and add HTML. This attack is known asHTTP response splitting. HTTP response splitting can be used for HTML injection by injecting strings like this:

%0a%0d%0a%0d<script>alert(1)</script>

The two new lines/carriage returns separate the HTTP header from the HTTP body, and the script will be in the HTTP body and executed.

USERINPUT2 is placed within a title tag. IE does not allow script tags within title tags, but if an attacker can inject <script>alert(1)</script>, then more likely than not, the attacker can inject this:

</title><script>alert(1)</script>

This breaks out of the title tag.

USERINPUT3 is placed within a styles tag. One could set USERINPUT3 like so in IE:

black; background:url('javascript:alert(1)');

Then he could use this in Firefox:

1:expression(alert(1))

Equivalently, user input sometimes appears in style parameters as part of other tags, like this:

JavaScript can be executed in IE if you could set USERINPUT3A to this:

javascript:alert(1)

Or for Visual Basic fans, this can be used:

vbscript:MsgBox(1)

Firefox does not accept background:url() with javascript: protocol handlers.

However, Firefox allows JavaScript to be executed in expression’s. In Firefox set USERINPUT3A to this:

); 1:expression(alert(1)

USERINPUT4 is trivial to exploit. Simply set USERPINUT4 to this:

";alert(1);

USERINPUT5 is more deeply embedded within the JavaScript. To insert the alert(1) function that is reliably executed, you must break the alert(1) out of all code blocks and ensure that the JavaScript before and after is valid, like this:

')){}alert(1);if(0)

The text before alert(1) completes the original if statement, thus ensuring that the alert(1) function is executed all the time. The text following alert(1) creates an if statement for the remaining code block so the whole code block between script tags is valid JavaScript. If this is not done, then the JavaScript will not be interpreted because of a syntax error.

You can inject JavaScript into USERINPUT6 using a plethora of tricks. For example, you can use this:

"><script>alert(1)</script>

Or, if angle brackets are disallowed, use a JavaScript event handler like onclick as follows:

" onclick="alert(1)

USERINPUT7 also has many options like this:

'><script>alert(1)</script>

Or this:

' style='x:expression(alert(1)) Or simply this:

javascript:alert(1)

The first two suggestions for USERINPUT7 ensure that the script will be executed upon loading the page, while the last suggestion requires that the user click the link. It’s good practice to try them all just in case some characters and strings are disallowed.

USERINPUT8 is also open to similar HTML injection strings. Here’s a favorite that uses an event handler:

notThere' onerror='alert(1)

Preventing XSS is typically accomplished by escaping or encoding potentially malicious characters. For instance, if a user inputs <script>alert(1)</script> into a text field, the server may respond with the following escaped string:

Depending on where the escaped string is located, the string would appear as though it were the original and will not be executed. Escaping is much more complex and is thoroughly discussed in the countermeasure, “Preventing Cross-Site Scripting,” later in this chapter. Most escaping routines either forget to escape potentially malicious charac-ters and strings, or they escape with the wrong encoding. For example, USERINPUT9 is interesting because on* event handlers interpret HTML entity encodings as ASCII, so one could mount the same attacks with the following two strings:

x');alert(1);

and

x');alert(1)

Finally, USERINPUT10 can be exploited with event handlers and breaking out of the input tag. Here’s an example:

x onclick=alert(1)

This example shows that user-supplied strings can be placed anywhere in HTTP responses. The list of possibilities is seemingly endless.

If you can perform HTML injection on any of the preceding instances, then the HTML injection can be used for XSS anywhere on that domain. You can inject JavaScript into web applications in many different ways. If your attempts ever result in corrupting the format of the page, such as truncating the page or displaying script other than what you injected, you have probably found an XSS that needs a little more polishing before it will work.

Dans le document Hacking Exposed (Page 65-69)