Web Apps for XSS vulnerability testing

Transferred from: http://www.uml.org.cn/Test/201407161.asp

XSS vulnerability testing of Web applications cannot be limited to entering XSS attack fields on Web pages and submitting them. Bypassing JavaScript detection, entering an XSS script, usually ignored by the tester. The attack path that bypasses JavaScript detection for XSS malicious input.

Common XSS Input

XSS input typically contains JavaScript scripts, such as pop-up malicious warning boxes: <script>alert ("XSS");</script>

XSS input can also be an HTML snippet, such as:

The webpage constantly refreshes <meta http-equiv= "refresh" content= "0;" >

Embed links to other websites <iframe src=http://xxxx width=250 height=250></iframe>

The XSS (cross Site Scripting) Cheat Sheet maintains a common list of XSS attack scripts that can be used as a test case input to detect the presence of a WEB app for XSS vulnerabilities. Developers of the first exposure to XSS attacks may not understand some of the XSS input provided by the list, and the second part of this article will explain the XSS input for different code contexts further.

Test tools

Many tools can intercept a browser before sending a get/post request, allowing an attacker to modify the data in the request to bypass JavaScript's validation and inject malicious data into the server. The following is a list of some common tools for intercepting HTTP requests.

Paros Proxy (http://www.parosproxy.org) Fiddler (Http://www.fiddlertool.com/fiddler) Burp Proxy (http://www.portswigger.net/proxy/) Tamperie (Http://www.bayden.com/dl/TamperIESetup.exe)

I have used Tamperie to test the security of WEB applications. Tamperie is small and easy to use, can intercept the Get/post requests sent by IE, and can even bypass SSL encryption. But Tamperie + IE7 work is not stable. IE7 provides support for IPV6, and if you do not plan to test your Web app's support for IPV6, it is recommended to use a combination of Tamperie + IE6.

2: Tamperie bypasses the checksum of the client browser JavaScript, intercepts it when the POST request is submitted, and allows the user to arbitrarily modify the value of the form entry name and message, such as modifying the value of message to "<SCRIPT&A Mp;gt;alert ("XSS hole!!"); </script>, then click on the "Send altered Data" button to send the modified malware to the WEB server.

Figure 2. Use Tamperie to intercept a Post request

Encode dynamic content at the end of the output

For a WEB application, its dynamic content may originate from user input, background database, hardware status change, or network information. Dynamic content, especially from user input, is likely to contain malicious data, which can affect the normal display of Web pages or execute malicious scripts. The safe display of dynamic content in the browser side is related to the contextual context in which dynamic content is located, such as dynamic content in the HTML body, attributes of form elements, or JavaScript code snippets. For a PHP language-based WEB application, when performing "echo", "print", "printf", "&lt"? = "statement when dynamic content is being processed. This section will first describe the use of the library function Htmlspecialchars () provided by PHP, which converts 5 HTML special characters into HTML entity encodings that can be displayed on a Web page, and then introduces the XSS attack input in some common contexts and how to escape dynamic content on the output side. , encoding to avoid XSS attacks.

Use PHP's Htmlspecialchars () to display HTML special characters

As you can see from the XSS malicious input listed above, these inputs contain some special HTML words such as "<", ">". When transmitted to the client browser display, the browser interprets the execution of these HTML or JavaScript code instead of displaying the strings directly. < > & "Such characters have special meanings in the HTML language, how to display them directly in Web pages instead of being interpreted as special characters by the browser, for special characters entered by the user?"

HTML character entities by & Symbol, entity name or # Plus entity number, semicolon three parts. The following is the encoding of some special characters in HTML. Some character entities have only entity numbers and no corresponding entity names, such as single quotes.

PHP provides the Htmlspecialchars () function to convert HTML special characters into character entity encodings that appear on a Web page. This way, even if the user enters a variety of HTML tags, the HTML tags are displayed directly when they are read back to the browser, instead of interpreting the execution. The Htmlspecialchars () function converts the following five kinds of HTML special characters into character entity encodings:

& Turn into & "Turn into " < Turn into < > Turn into > ' Turn into & #39;

When Htmlspecialchars ($STR) is called directly, & "< > Be escaped.

When the ent_quotes tag is set, the single quotation mark is also escaped when Htmlspecialchars ($str, ent_quotes) is called.

When you set the ent_noquotes tag, both single and double quotation marks are not escaped. That is, when you call Htmlspecialchars ($str, ent_noquotes), only & < > Be escaped.

XSS attacks and solutions for dynamic content in different contexts

The XSS attack input is related to the background of the code where the dynamic content is located, such as the value of the property of the form element in the dynamic content, the HTML body, or the Javascript code snippet, and so on.

The properties of the HTML tag are dynamic content

In Web apps, the properties of HTML tags such as input, style, color, and so on, can be dynamic content, where the "value" attribute of the "input" tag is usually dynamic.

Example 1

<form...><input type=text name= "msg" id= "msg" size=10 maxlength=8 value= "<? = $msg?> " ></form>

Attacking XSS input

Hello "><script>evil_script () </script>

Replace dynamic content

Replace the $msg with a malicious XSS input:

<form...><input type=text name= "msg" id= "msg" size=10 maxlength=8 value= "Hello" >< Script>evil_script () </script> " ></form>

Example 2

<form...><input type=text name= "msg" id= "msg" size=10 maxlength=8 value=<? = $msg?>></form>

Attacking XSS input

Hello Onmouseover=evil_script ()

Replace dynamic content

Replace the $msg with a malicious XSS input:

<form...><input type=text name= "msg" id= "msg" size=10 maxlength=8 Value=hello Onmouseover=evil_ Script () ></form>

Analysis

From Example 1 you can see that its XSS attack input contains HTML special characters < > "

As you can see from Example 2, its XSS attack input does not contain the five HTML characters mentioned in the previous section, but the "value" property value is not enclosed in double quotes.

Solution Solutions

Call Htmlspecialchars ($STR, ent_quotes) to add the following 5 kinds of HTML special characters < > & ' "Escape, and enclose the property value in double quotes. Such as:

<form...><input type=text name= "msg" id= "msg" size=10 maxlength=8 value= "<? = Htmlspecialchars ($msg, ent_quotes))?> " ></form>

Precautions

Escaping the value of input must consider the consistency of the display and storage data, that is, data displayed on the browser side and stored in the server-side background may become inconsistent due to escaping. For example, the background raw data stored on the server side contains the above 5 special characters, but is not escaped, in order to prevent the XSS attack, the HTML special characters are escaped in the browser-side output:

1. When the form is submitted again, the stored content becomes the escaped value.

2. When using JavaScript to manipulate form elements, you must consider that values may have been escaped when you need to use the values of the form elements.

HTML text for dynamic content

Example

<b> Welcome: < = $welcome _msg?></b> Attacking XSS input <script>evil_script () </script> Replace dynamic content Replace the $welcome_msg with the malicious XSS input: <b> welcome: <script>evil_script () </script></b>

Analysis

,< in the background of HTML text > Word Inode introduces HTML markup,& May think of the beginning of the character entity encoding, so it is necessary to < > & Escape

Solution Solutions

For the sake of brevity, use Htmlspecialchars () to escape 5 HTML special characters, such as:

<b> welcome: <? = Htmlspecialchars ($welcome _msg,, ent_noquotes)?></b>

The value of the URL is dynamic content

Script/style/img/activex/applet/frameset ... If the src or href attributes of the tag are dynamic content, you must make sure that the URLs do not point to malicious links.

Example 1

<script src=<? = "$script _url>" > Attacking XSS input Http://evil.org/evil.js Replace dynamic content Replace the $script_url with the malicious XSS input: <script src= "Http://evil.org/evil.js" >

Example 2

<img src= "<? = $img _url> " > Attacking XSS input Javascript:evil_script () Replace dynamic content Replace the $img_url with the malicious XSS input: <img src= "Javascript:evil_script ()" >

Analysis

In general, try not to let the value of the URL be controlled by the user. If the user needs to define their own style and display effect, also can not let the user directly control the content of the entire URL, but provide a predefined style for the user to set up, assemble, and then by the background program based on the user's choice of combination into a secure URL output.

Character Set encoding

The browser needs to know the character set encoding in order to display the page correctly. If the character set encoding is not explicitly defined in content-type or meta, the browser will have an algorithm to guess the character set encoding of the Web page. such as <script>alert (Document.cookie) </script> The UTF-7 code is:

+adw-script+ad4-alert (Document.cookie) +adw-/script+ad4-

If +adw-script+ad4-alert (document.cookie) +adw-/script+ad4-as dynamic content at the top of the page and routed to the browser side, IE will think this page is UTF-7 encoded, so that the page does not display properly.

Solution Solutions

Explicitly defines the character set encoding for a Web page, such as

<meta http-equiv=content-type content= "text/html; Charset=utf-8 ">

Dynamic content is a parameter of the JavaScript event handler function

JavaScript event handler functions such as onclick/onload/onerror/onmouseover/parameters may contain dynamic content.

Example

<input type= "button" value= "Go to" onclick= ' Goto_url ("<? = $target _url> "); ' > Attacking XSS input foo"); Evil_script (" Replace dynamic content The HTML parser will parse the Web page before the JavaScript parser, replacing $target_url with malicious XSS input: <input type= "button" value= "Go to" onclick= ' Goto_url ("foo"); Evil_script (""); > Dynamic content in JavaScript code snippets

Example

< SCRIPT language= "javascript1.2" > var msg= ' <? = $welcome _msg?> ‘; ... </SCRIPT> Attack XSS input 1 Hello '; Evil_script (); // Replace dynamic content Replace the $welcome _msg with the malicious XSS input: < SCRIPT language= "javascript1.2" > var msg= ' Hello '; Evil_script (); ‘; ... </SCRIPT> Attack XSS Input 2 Hello</script><script>evil_script ();</script><script> Replace dynamic content Replace the $welcome_msg with the malicious XSS input: <script> var msg = ' hello</script> <script>evil_script ();</script> <script> '//...//do something with Msg_text </script>

Analysis

As shown above, using dynamic content in the JavaScript context requires great care. In general, try to avoid or reduce the use of dynamic content in the context of Javascript, if dynamic content must be used, the development or code audit must consider the possible value of these dynamic content, whether it will lead to XSS attacks.

Build PHP library function Check input

Web developers must understand that it is not enough to build secure WEB applications only when the client uses JavaScript functions to detect and filter illegal inputs. As mentioned earlier, attackers can easily use tools to bypass JavaScript validation or even SSL encryption to enter malicious data. The encoding of dynamic content at the output can only serve as a double protection, and more importantly, the input should be verified on the server side. PHP provides functions such as Strpos (), Strstr (), Preg_match () to detect illegal characters and strings, and the Preg_replace () function can be used to replace illegal strings. OWASP PHP Filters Open source project provides some PHP library functions for filtering illegal input as a reference. Some common tests and filters include:

Whether the input contains only valid characters;

Enter if for number, whether the number is in the specified range;

Whether the input string exceeds the maximum length limit;

Enter whether to meet the special format requirements, such as email address, IP address;

The relationship between the coupling and limitation of the different input boxes in logic;

Remove the input and trailing spaces;

Summarize

WEB application Security is a very important and wide-ranging topic. In order to prevent common XSS attacks, WEB developers must understand that the input is not only detected and filtered by the client, but also the input and output code library functions on the server side, and the server-side detection and filtering input The special characters are encoded in the context of the dynamic content and then sent to the browser side display.

Web Apps for XSS vulnerability testing