A great way to stop malicious JavaScript is to ensure it cannot be inserted into a web application. Input filtering is probably the first line of defense used by most organizations, but it should not be used as the only line of defense. JavaScript is used on most web applications; however, there is often little need for an end user to insert real scripts into a web page. If HTML code is allowed in the application for legitimate purposes, allowing a user a blank canvas for JavaScript is probably a bad idea, as it opens the door for malicious attacks. Writing good web applications is the best way to prevent malicious JavaScript, but ensuring input filters cannot be bypassed with powerful functions, such as a XMLHTTPRequest, is also necessary. As developers known well, it is difficult to restrict inputs that are required to make the application work well; therefore, filtering out items that are known as bad or simply not required is one of many steps that can stop malicious JavaScript.
Nowadays, input filters are gospel for modern web applications. Every security professional emphasizes this over and over again during security presentations for web application security. While the need for input filtering is important, the need for good input filtering is even more important. Evading input filters is about as easy as evading IDS signatures in the 1990s—it’s amazingly simple. While many sites have joined the input filtering bandwagon years ago, good input filtering or even positive filtering has not been the norm.
For example, for a given test string for XSS, such as <script>alert(document .cookie)</script>, several variants could be used to evade input filtering measure.
The following examples show a few subversion methods, including Base64 encoding, HEX, and decimal:
• Base64 PHNjcmlwdD4=
• HEX <script>
• Decimal <script>
Is the web application performing input filtering on all these values? Probably;
however, what about the web browser? If an attacker posted a script onto a web page that is then converted to ASCII by the browser automatically, is that a security issue of the web application or a security issue of the browser? As we will discuss later on in the Samy worm discussion, a lot of browser leniencies make character conversation a tough thing to defend against.
A simple way to check for transformation between ASCII script characters to hex or binary is by using the iSEC SecurityQA Toolbar. The toolbar has a standard library for
XSS checks, but it can also can transform its library to hex or decimal encoding to verify whether the application is using strong input filtering/positive validation compared to the base filtering methods (such as ASCII of <script>). It should be noted that this option will make the transformation test 10 times longer, so this is probably a test to run overnight to give it adequate time to finish.
Complete the following exercise to test character transformation with the iSEC SecurityQA Toolbar:
1. Visit www.isecpartners.com/SecurityQAToolbar and request an evaluation copy of the product.
2. After installing the toolbar, visit the web application for which you want to test the input fi ltering.
3. Select Options | Confi guration.
4. Highlight the XSS (Cross-Site Scripting) under Module on the left hand side.
5. On the right hand side, check the Transformation Character Set and click Apply, as shown in Figure 4-7.
6. From the SecurityQA Toolbar, select Session Management | Cross-Site Scripting, as shown in Figure 4-8.
Figure 4-7 Select Transformation for XSS library
The SecurityQA Toolbar will automatically check for XSS attacks using hex and decimal transformation on the request. Hence, the request for <script> will actually be converted to <script
> for hex and <script> for decimal.
7. Once the security toolbar has been completed, view the report by selecting Reports | Current Test Results. The SecurityQA Toolbar will then display all security fl aws found from the results in the browser (see Figure 4-9). Notice that the iSEC Test Value line shows that a hex encoding was able to bypass the input fi lters on the web application.
Along with transformation using hex or decimal encodings, image tags, style tags, and newlines seem to bypass a lot of input filtering at the date of this publication. A XSS can be executed using image tags, style tags, or newlines, which are also checked by the iSEC SecurityQA Toolbar but are listed below for an easy attack check:
• XSS using script tags:
<script>alert(document.cookie)</script>
• XSS using image tags:
<IMG SRC=javascript:alert(document.cookie)>
Figure 4-8 SecurityQA Toolbar’s Cross-Site Scripting feature
• XSS using style tags:
<style>.getcookies(background-image:url ('javascript:alert(document.cookie);');}
</style> <p class="getcookies"></p>
• XSS using newline:
<script type="text/java\nscript">alert(document.cookie)</script>
While this is by no means an exhaustive list, it shows one example for each attempt.
For example, the SecurityQA Toolbar has 50 checks each for style and image tags Figure 4-9 XSS testing results from SecurityQA Toolbar
respectively, but an easy way to see how well a web application is perform input filtering is to try one of these lines. If either style or image tags work, it shows how positive filtering is a better approach to stop malicious JavaScript. For example, playing catch-up to a new injection technique (for example, style tags) may leave a web application vulnerable for a period of time; however, using positive filters, allowing only known and approved characters on a web application, ensures that the latest evasion techniques will probably be protected against, as the input is being compared to an approved list rather than a non-exhaustive unapproved list.