Avoid common XSS filtering methods

0x01 many filters match special tags, including start and end angle brackets. However, many browsers accept blank characters before ending brackets, allowing attackers to easily avoid such filtering. Example: <script>

 
0x02 because many people write HTML code with lower-case characters, some filters only check commonly used lower-case malicious tags. For example: <ScRiPt>, avoid filtering by changing the case sensitivity of characters.
 
0x03 some filters match any pair of start and end angle brackets to delete any content, but you can usually end the injected tag by relying on the existing syntax to avoid such filtering. For example, you can control the value attribute values in the following code:
 
<Input type = "hidden" name = "pageid" value = "foo">
 
You can inject a new tag containing JavaScript using the following script that is not blocked by filtering:
 
Foo "> <x styple =" x: expression (alert (document. cookie ))
 
In many cases, browsers accept unfinished HTML tags. Attackers can exploit this behavior to avoid filtering. Construct HTML code similar to the following:
 
 
 
 
0x04 filter and match the start and end angle brackets to extract the content and compare the content with the label name blacklist. You can avoid filtering by using extra parentheses.
 
<Script> alert (document. cookie); // </script>
 
 
 
0x05 even if the text after the null byte is still returned in the application's response, if there is a NULL byte, some filters will stop processing the string. Insert an empty URL-encoded byte before the expression to avoid this filtering.
 
Foo % 00 <script>
 
 
 
0x06 in different target browsers, you can insert characters in the filtered expressions that can avoid filtering but still be accepted by the browser:
 
<Script/src =...
 
<Scr % 00ept>
 
Expr/*****/ession
 
 
 
0x07 if the data submitted by the user is normalized after the application is filtered, we can still use URL encoding or double encoding to filter the expressions, avoid filtering, and exploit the vulnerability.
 
% 3 cscript % 3e
 
% 253 cscript % 253e
 
 
 
0x08 because after the server executes all input confirmation, the effective attack code returned in the response will be parsed by the victim's browser, a special situation that avoids standardization occurs. Sometimes, attackers can encode the attack code in HTML to avoid input confirmation from the server. The victim's browser will parse the attack code again. For example, the expression Javascript is often blocked to prevent attacks using this protocol. However, attackers can use various browsers to encode the expression in HTML format. For example:
 
 
 
 
The above three examples use the standard UTF-8 encoding, the use of redundant fill data standard encoding, and omit the semicolon hexadecimal encoding. The combination of different encoding types requires a large number of combinations.
 
 
 
Sometimes we can successfully execute some JavaScript scripts, but some commands and keywords are restricted in the code. In this case, you can dynamically create and execute statements to avoid application filtering.
 
The application prevents users from submitting any data containing the expression document. cookie. You can avoid this filtering by using the following method:
 
Var a = "alert (doc" + "ument. coo" + "kie)"; eval ();
 
Or
 
Var a = "alert (" + String. fromCharCode (100,111, 99,117,109,101,110,116, 111,111,107,105,101,) + ")"; eval ();
 
 
 
Sometimes the application will encode some keywords in HTML (<to <,> to>;). In this case, the application may completely delete some characters or expressions, attackers try to use this kind of purification to prevent malicious code execution.
 
If you encounter this character purification setting, you need to find out which characters and expressions are purified by the application, and whether the attack can be performed through the remaining characters.
 
0x09 If filtering completely deletes some expressions and at least one deleted expression contains more than one character, the filtering may be avoided as long as the application does not perform recursive cleaning.
 
<Scr <script> EPT>
 
 
 
Assume that the application imposes a length limit on each field to prevent the insertion of valid attack strings. However, the attacker can still use the following method to distribute a script to three locations controlled by the attacker to send a valid Attack String:
 
Https://www.2cto.com/account. php? Page_id = "> <script>/* & seed = */alert (document. cookie);/* & mode = */</script>"
 
The final HTML is completely valid, and the source code block has become a JavaScript annotation (included between/* and */), so it is ignored by the browser. The injection script is executed.


The author's information is not found. Please see the prompt. Thank you.