Key considerations for preventing XSS attacks on websites

 

To completely prevent websites from being attacked by cross-site command code and Implicit Information Code, the system must check the user's input information and protect the webpage content, avoid unexpected and harmful behaviors.

 

Attackers usually use Cross-site command code (Cross-siteScripting) to attack website background vulnerabilities. It is different from SQLInjection attacks. The former means inputting information from the front-end of the Web to the website, causing the website to output maliciously controlled webpage content, which damages the system security. The latter is to input a string that is sufficient to change the content of the SQL statement executed by the system, so that the system can eventually attack.

 

However, from a more general perspective, these two attack methods are basically the same. They all use the input information deliberately produced by the system without checking the input information or insufficient checking, so that the system produces harmful behaviors that are not expected.

 

Is the filter input valid?

 

Therefore, to defend against such attacks, most people intuitively think of a way to filter the input information provided by users. In the face of information implicit code attacks, many people may think of filtering SQL keyword strings or characters in the input information. For example, if the user's input information contains single quotes, therefore, it is possible to create dangerous SQL statements. Therefore, many programmers will think of escape for single quotes to prevent attacks against information recessive code. This type of escape or filtering method is not difficult to avoid. For example, for single quotes, you can still Replace the single quotes with other types by using the special style supported by the database server, make the escape program invalid.

 

Similarly, in the face of cross-site command code attacks, many programmers first think of filtering user information that may cause doubts. For example, to filter character and SCRIPT strings, if the user's input information contains suspicious characters or strings, rewrite or disable the use. This filtering method can be called blacklist Filtering for specific targets, because the program first lists objects that cannot appear, and then filters.

 

Of course, in cross-site command code attacks, if you want to use the blacklist filter method, of course, it will not work. Because javascript alone is a string that can be produced at medium price in HTML, but the string format is not javascript. For example, the # x hexadecimal character representation is used to represent every character in the string javascript. Since there are too many rewrite forms, it is almost impossible to use the blacklist method.

 

Therefore, no matter what type of attacks you want to defend against, you should filter the information in a whitelist. This is opposite to the blacklist. It is not used to list objects that are not allowed, but to list acceptable objects.

 

Control Using forward Columns

 

In the face of information implicit code attacks, we recommend that you define a specific form for each column. For example, the date column can only contain numbers and diagonal lines, while the ID column, only English letters and bottom line characters can appear. In this way, it is not that easy to implant harmful components through information.

 

For cross-site command code attacks that also need to check the input information, to filter the input information, the best policy is to filter the information based on the whitelist. For example, if the user is allowed to input HTML syntax, only images can be input in an open format, and others are not. In this way, it is more difficult to avoid filtering rules.

 

Of course, the strict whitelist policy is adopted, and the procedure is difficult to write. In addition, the form of user information input is more limited, but this is a price that must be paid for security.

 

Code the webpage content to improve defense

 

In addition to filtering the input information in a whitelist, coding the output page content is also a practical skill. The filtering of input information prevents suspicious information, while the code for input is to make harmful information harmless.

 

Fortunately, many programming languages have released libraries to prevent cross-site command code attacks and assist programmers in coding HTML output content. For example, PHP htmlentities () or htmlspecialchars (), ASP Server. HTMLEncode (), ASP. NET Server. HtmlEncode (), and so on. It allows specialized libraries to process the code of input content, reduces the extra costs of the program designer's own development, and provides more comprehensive defense considerations. Microsoft also provides a library named MicrosoftAnti-CrossSiteScriptingLibrary, and provides various filtering and coding mechanisms for HTML, JavaScript, URL, XML, and VBScript. As a result. you can use this library to convert the strings input by the user or the output strings based on the user input strings into simple text, it does not include executing script programs on the browser, so it can reduce the risk of attacks.

 

Thoroughly analyze possible vulnerabilities of program code

 

When writing a program, if you can pay attention to the output of the input information and compile the code of the output page content, we believe it can increase the intensity of defense. However, how can we detect and prevent the existing program code from cross-site command code attacks? Basically, you can adopt a systematic analysis method.

 

If you want to check whether your program code has cross-site command code attacks, follow the suggestions in WritingSecureCode. First, you must list all the information sent from the user in your website program. The user information includes each column in the table read by your website program, query strings from the website, cookies, HTTP headers, and so on. Because, don't forget that all the information from users is "evil ".

 

After finding the information of each recipient, you can track the flow of each message in the application one by one and check the received information, whether the result is reflected in the output page. In the middle of this process, you may directly process the received information and send it as an output result. You may first store the received information in the information library or file, it will be sent as an output result later.

 

If the information you find will eventually become a part of the output page, you should check whether the information is "clean", that is, are you sure you want to filter this information or add code encoding during output. If not, this information may become a point where cross-site command code attacks are initiated. That is to say, you should handle the input and output of this information. Through the above steps, you can view the existing program code issues.

In addition, it is helpful to check whether your JavaScript programs use innerHTML and document. write () with security concerns. In addition, using eval () in JavaScript may also cause security problems. The eval () function allows a browser to directly use the parameter passed in to the function as an explain cribd formula or executable statement, dynamically evaluate or execute the formula value. If the value of the parameter received by eval () comes from a portion of the information entered by the user, the crisis may be high, because it means that, the user has the opportunity to control the JavaScript statements executed through eval (), and the system security is just like opening the door. This is why many codes have suggested not to use eval () recently, because it is too easy to form a security vulnerability.

 

Cross-site command code attacks are indeed very difficult to defend, but they may cause a lot of harm if you are not careful. Unfortunately, there are still a lot of Web Application designers who are not careful about it. I hope this will bring you a basic understanding. Cross-site command code attacks are also full of profound discussions and skills. They are not within the scope of this article. We suggest you study them yourself.