19.09.2017 Views

the-web-application-hackers-handbook

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

468 Chapter 12 n Attacking Users: Cross-Site Scripting<br />

You can even nest <strong>the</strong>se calls and ping-pong between <strong>the</strong> languages as required:<br />

execScript(‘execScript<br />

“alert(1)”,”javascript”’,”vbscript”);<br />

As mentioned, VBScript is case-insensitive, allowing you to execute code in<br />

contexts where your input is converted to uppercase. If you really want to call<br />

JavaScript functions in <strong>the</strong>se situations, you can use string manipulation functions<br />

within VBScript to construct a command with <strong>the</strong> required case and <strong>the</strong>n<br />

execute this using JavaScript:<br />

EXECSCRIPT(LCASE(“ALERT(1)”)) <br />

<br />

Using Encoded Scripts<br />

On Internet Explorer, you can use Microsoft’s custom script-encoding algorithm<br />

to hide <strong>the</strong> contents of scripts and potentially bypass some input filters:<br />

<br />

<br />

This encoding was originally designed to prevent users from inspecting<br />

client-side scripts easily by viewing <strong>the</strong> source code for <strong>the</strong> HTML page. It has<br />

since been reverse-engineered, and numerous tools and <strong>web</strong>sites will let you<br />

decode encoded scripts. You can encode your own scripts for use in attacks via<br />

Microsoft’s command-line utility srcenc in older versions of Windows.<br />

Beating Sanitization<br />

Of all <strong>the</strong> obstacles that you may encounter when attempting to exploit potential<br />

XSS conditions, sanitizing filters are probably <strong>the</strong> most common. Here, <strong>the</strong><br />

<strong>application</strong> performs some kind of sanitization or encoding on your attack string<br />

that renders it harmless, preventing it from causing <strong>the</strong> execution of JavaScript.<br />

The most prevalent manifestation of data sanitization occurs when <strong>the</strong> <strong>application</strong><br />

HTML-encodes certain key characters that are necessary to deliver an<br />

attack (so < becomes &lt; and > becomes &gt;). In o<strong>the</strong>r cases, <strong>the</strong> <strong>application</strong><br />

may remove certain characters or expressions in an attempt to cleanse your<br />

input of malicious content.<br />

When you encounter this defense, your first step is to determine precisely<br />

which characters and expressions are being sanitized, and whe<strong>the</strong>r it is still<br />

possible to carry out an attack without directly employing <strong>the</strong>se characters<br />

and expressions. For example, if your data is being inserted directly into an<br />

existing script, you may not need to employ any HTML tag characters. Or, if<br />

<strong>the</strong> <strong>application</strong> is removing tags from your input, you may be able

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!