Prevent correct xss posture

Prevent correct xss posture

Xss attacks are common web attacks. If you have not heard of xss attacks, you can first understand the knowledge and principles of xss, such as XSS) "target =" _ blank "rel =" nofollow, noindex "> https://www.owasp.org/index.php/Cross-site_Scripting_ (XSS ).

The method to prevent xss attacks is also very simple: escape!

But the escape time? Is it escape before persistence or escape after data reading?

I chose the first method at first, because this method seems to be permanent, but now I am more and more inclined to the second method.

Select the first or second type based on your actual situation. We know that xss attacks are a web attack method, and its runtime environment is in the user's browser, that is, the user's runtime environment is uncontrollable. It seems good to escape before persistence, because we can use filter or interceptor to intercept all write requests for uniform escape. In this way, our business logic does not need to be escaped at all, because the data we have obtained is already escaped.

If the user's terminal is controllable, for example, the Native App, escape before the database is imported, because all the output methods are displayed in our App, naturally, there will be no xss attack problems. For example, if the user inputs <Haha> in the comment, do you think the user wants to output <Haha> or <Haha>? The result is obvious.

The reality is often complicated, not only black and white, 0 and 1, native and web, but also they are intertwined and intrude into each other's fields. Basically, most apps now have the sharing function, so malicious users can insert and inject code into the comments before sharing the comments, other shared users are at risk of being attacked. The solution is to perform global escape for the shared data. In fact, many template systems have already considered this issue for us. For example, Django and Jinja2 templates Enable Automatic escape by default. In the scenario of front-end and back-end separation, you can also have a front-end for escape.

Another reason why I recommend "do not escape read and escape" is the uncertainty of the escape format in the early stage and the diversity of the output in the later stage. If you are developing a rest server, you can communicate with the App in json format. For simplicity, before starting the business code, you escape all input data in html format. Therefore, you can safely share the data, because all the data has been escaped before persistence, and you will suffer from the unescape to the App data. If the boss asked you to output the data in xml format that day (may be input from other systems or print reports), then you will be more painful. Because the escape characters in xml and html are still somewhat different, you have to first restore the original data and then follow the xml format escape. If you think it is okay, I will admire you. If the boss asks you to have more output formats, you will be more painful. This is still because the input format is not considered to change. The logic becomes complicated due to an escape problem, and the system stability is not worth the candle.

Finally, let me end the advantages and disadvantages of the two methods:

Escape modeAdvantagesDisadvantagesEscape before warehouse receiving requires different outputs for multiple terminals once and for all, with insufficient flexibility. It cannot cope with changes in the later data format. Escape before reading is simple and flexible, each output data must be escaped in scenarios with various data formats. Manual processing is easy to omit.

I recommend the second method to prevent xss attacks. Although each output data needs to be escaped, if you use an automatically escaped template or framework for processing, it can greatly improve efficiency and avoid security issues. Finally, we should remind everyone that security is no small matter. Even if you think no one will attack the system, you still need to avoid these risks. Security is the cornerstone of the system.