1. filter "<" and ">" tags
The ultimate goal of XSS cross-site attacks is to introduce script code to execute in the user's browser. Therefore, the most basic and simple filtering method is to convert the "<" and ">" mark.
Replace (str, "<", "& # x3C;") replace (str, ">", "& # x3E;") 2. HTML attribute Filtering
The above code can filter out the "<" and ">" tags, preventing attackers from constructing HTML tags. However, attackers may exploit existing attributes, such as the image insertion function, to change the path attribute of an image to a piece of script code, as shown in figure
After the above code is executed, it can also achieve the purpose of cross-site. In addition, many HTML tags support the form of "javascript: Cross-Site Code". Therefore, attackers need to convert the input data as follows:
Replace (str, "javascript:", "") replace (str, "jscript:", "") replace (str, "vbscript :","")
Once the entered statements contain "javascript", "jscript", and "vbscript", they are replaced by blank spaces.
3. filter special characters: &, carriage return, and space
Because the value of the HTML attribute can be expressed in the form of "& # ASCii", the previous cross-site code can be changed to this:
to break through the filter program and continue the cross-site attack, using the code:
Replace (str, "&", "& # x26;") replace "&" with "& # x26;", and the subsequent statements become invalid. However, there are other ways to bypass filtering, because the method of filtering keywords has many vulnerabilities. Attackers can construct the following attack code:
here, the keyword is blank, and the Tab key is precisely split, the above code becomes invalid again, so you may consider filtering tabs and spaces to prevent such cross-site attacks.
4. Complete prevention of cross-site HTML attributes
Even if the program designer thoroughly filters out a variety of dangerous characters, it does cause a lot of trouble for the attacker to carry out cross-site intrusion. The attacker can still exploit program defects to launch attacks, attackers can use the aforementioned attributes and event mechanisms to construct and execute script code. For example, the following Image Tag code is available:
This is a typical cross-site attack example using the onerror event. Therefore, many programmers filter the event, once the keyword "onerror" is found, the conversion is filtered.
However, the time cross-site method that attackers can exploit is not only an onerror method, but also a variety of attributes that can be used to construct cross-site attacks. For example:
This event attribute can also implement cross-site attacks. It can be noted that there is a space between "src =" # "and" style ", that is, the attributes must be separated by spaces, so the programmer may filter spaces, to prevent such attacks. However, if spaces are filtered out, attackers can break through it.
This code exploits the scripting language Rule vulnerability, comments in the script language are expressed as blank spaces. Therefore, the comments of the Code are described to achieve the space effect, so that the statement can be executed.
Summary
The root cause of the above attacks is that the user's label is unauthorized, resulting in confusion between input data and program code. Therefore, the method to ensure program security is to restrict the space entered by users and allow users to perform activities in a safe space.
After filtering "<" and ">", you can place your input in the output field between double quotation marks. Then let the user input be in a safe field. This is to prevent the user from crossing the license tag by filtering the double quotation marks ("") in the user input data.
In addition, if you filter out spaces and Tab keys, you don't have to worry about keyword splitting. Finally, filter out the "script" keyword and convert it &.
As long as you notice the above five-point filtering, you can basically ensure the security of website programs and avoid cross-site attacks.
Of course, vulnerabilities are inevitable. To completely ensure security, discarding the HTML Tag function is the safest solution. However, this may reduce the program's performance.
Extracted from the precipitated blog