Correct posture for preventing XSS

Correct posture for preventing XSS

XSS attacks are a very common means of attack in web attacks. If you have not heard of XSS attacks, you can first understand the relevant knowledge and principles of XSS, such as: XSS) "target=" _blank "rel=" Nofollow,noindex ">https://www.owasp.org/ Index.php/cross-site_scripting_ (XSS).

The way to protect against XSS attacks is simple: Escape!

But the time to escape? Is it escaped before persistence, or is it after reading the data escape?

I began to think and I chose the first way, because it looked like once and for all, but now I'm getting more and more inclined to the second way.

Actually choose the first or the second need according to your actual situation to decide. We know that XSS attack is a means of web attack, it is running in the user's browser, that is, the user's operating environment is not controllable. Then escaping before persisting seems like a good idea, because we can use filter or interceptor to intercept all write requests and uniformly escape. In this way, our business logic does not require care escaping at all, because the data we have taken is already escaped.

If the user's terminal is controllable, such as: Native App, then to escape before warehousing appears superfluous, because all the output is shown in our App, naturally there will be no problem of XSS attack. For example, the user entered in the comments < Haha, you think the user wants to output < Haha, or < haha > it? The result is obvious.

The reality of the situation is often complex, not only black and white, 0 and 1, native and the web, more of them are intertwined and invade each other's fields. Basically, most apps now have a sharing feature, so a malicious user can simply insert the injected code into the comment and share the comment, so the other users who are being shared are at risk of being attacked. The solution is to globally escape the shared data, and in fact many of the template systems have helped us consider this part of the problem, such as Django and Jinja2 templates that are automatically escaped by default. If the scene is separated from front to back, there can also be a front end for escape.

I recommend the use of "inbound non-escaped read escape" There is also a reason, that is the early escape format uncertainty and the late output of the diversity. If you are developing a rest server, you communicate with the app using JSON format. For simplicity, you escaped all input data in HTML format before starting the business code. Then you can be very confident that the data you share is safe, because all of the data is escaped before it is persisted, and you are painfully unescape the data to the app. If the boss asks you to export the data in XML format (which may be an input requirement for other systems or a print report), you will be more miserable. Because XML and HTML escape characters are somewhat different, you have to unescape back the original data and then escape again in XML format. If that makes you feel OK, then I'm starting to admire you a little bit. If the boss also asks you to have more output format, then you will be more miserable, this is still without considering the input format changes in the case. Because an escaped problem causes logic to become complex, the stability of the system is not worth the candle.

Finally, let me end the pros and cons of these two approaches:

Escape Mode	Advantages	Disadvantages
Escape before warehousing	Once	Requires different outputs for multi-terminal, less flexibility to cope with late data format changes
Escaping before reading	A simple, flexible scenario that can handle a variety of data formats	Each output data needs to be escaped, manual processing is easy to omit

I recommend a second way to protect against XSS attacks. Although each output data needs to be escaped, if you use a template or framework with automatic escape, then you can greatly improve efficiency and avoid security problems. Finally, we should remind you that security is no small matter, even if you feel that no one will attack the system, or to avoid these risks, security is the cornerstone of the system.

Reference documents:

Why Escape-on-input are a bad idea

When does you escape your data?

This article used cc-by-sa-3.0 license, please follow it.

Correct posture for preventing XSS