How secure is client-side HTML sanitation?

Question

I've been looking at Pagedown.js lately for using markup on your pages instead of ugly read-only text areas.

I am very careful, although it seems that it is easy enough to fool a sanitized converter. I saw some discussion around Angular.js and html bindings, and also heard something when Knockout.js 3.0 came out that there was a previous inconsistency with the html binding.

It would seem that all you need to do to disable the sanitizer in Pagedown.js, for example, is something like

var safeConverter = new Markdown.Converter(); // safeConverter is open to script injection safeConverter = Markdown.getSanitizingConverter(); // safeConverter is now safe // Override the getSanitizingConverter pseudo-code Markdown.getSanitizingConverter = function () { return Markdown.Converter; }; 

and they can open the site before the injection script. Is that not so?

Edit

Then why should libraries like this use a disinfectant to use the client side? Of course, they say that they can not stand the unanitated html, but the next line says the use of Markdown.Sanitizer ..

How Angular does not open using the sanitizer service or is it just a farce?

Answer 1

I believe that there is a slight misunderstanding regarding the purpose and nature of such “disinfectants”.

The purpose of the sanitizer (for example, Angular ngSanitize ) is not to prevent the sending of "bad" data to the server. Quite the contrary: a disinfectant protects a non-malicious user from malicious data (either as a result of security on the server side (yes, no installation is perfect) or obtained from other sources (those that you do not control).

Of course, as a client function, the disinfectant can be circumvented, but (since the disinfectant protects the user (not the server)), bypassing it only leaving the bypass unprotected (that you can’t do anything and you don’t have to take care, it's their choice )

In addition, disinfectants can have a different (potentially more important) role: a disinfectant is a tool that helps a developer better organize their code so that it is easier to test for certain types of vulnerabilities (for example, XSS attacks) and even helps in the actual audit code for this kind of security hole.

In my opinion, Angular docs pretty clearly summarizes the concept:

Strict Context Shielding (SCE) is a mode in which AngularJS requires binding in certain contexts to get a value that is marked as safe for use in this context. [...]
SCE helps in writing code in a way that (a) is safe by default and (b) does an audit for security vulnerabilities such as XSS, clickjacking, etc. a lot easier .

[...]
In a more realistic example, you can create user comments, blog articles, etc. Through bindings. (HTML is just one example of a context in which processing user-driven input creates security vulnerabilities.)

In the case of HTML, you can use the library either on the client side or on the server side to disinfect unsafe HTML before binding to the value and rendering it in the document.

How would you ensure that every place using these types of bindings was bound to a value that was disinfected by your library (or returned as safe for rendering by your server?) How can you make sure that you did not accidentally delete a line that sanitized a value, or renamed some properties / fields and forgot to update the binding to a sanitized value?

To be protected by default, you want any such bindings to be prohibited if you cannot determine that something is explicitly saying safe in order to use the value for the binding in this context. You can then audit the code (a simple grep will do) to make sure that this is done only for those values ​​that you can easily say are safe - since they were received from your server, sanitized by your library, etc. You can organize your code base to help with this , perhaps only allow files in a specific directory. Ensuring that the internal API opened by this code does not mark arbitrary values ​​as safe, then becomes a more manageable task .

<sub> Note 1: Emphasis is mine.
Note 2: Sorry for the long quote, but I believe that this is very volatile (how sensitive) matter and one that is too often misunderstood. Sub>

Answer 2

You cannot sanitize the client side. Any user can always disable JavaScript or change the values ​​and send them to your server.

The server needs to double check this. The client side, in my opinion, is really just a usability function. Therefore, they know how they are gaining whether they are wrong or right.

In response to editing:

Most of them are convenience or functionality. For example, an unobtrusive check will make my text fields red if they put an invalid number. This is good, and I did not need to publish and check, and then change the border of the blablablabla text box ...

But when they make a message, I still need to check their details. I usually save this in the main library, which can be accessed by all applications (website, web service, mobile application, fat client, etc.).

Usability validation varies from platform to platform. But in the kernel, before any application trusts the data, it must check it in its trust barrier. No one can change the value of my if on the server, but everyone can change the value in their browser without disabling my JS.

Answer 3

Pagedown can run both on the server and on the client.

To disinfect html on the client, it makes sense to sanitize the output rather than the input. You will not disinfect before sending data to the server, but you can sanitize it after receiving data from the server.

Imagine that you are making a web service call on a client and receiving data from a third-party service. It can be transmitted through a disinfectant on the client prior to its provision. The user can disable sanitation on his own computer, but they only harm themselves.

It is also useful outside of security considerations only to prevent the user from accidentally entering the formatting of the surrounding page accidentally. For example, when entering an html message with real-time preview (for example, on StackOverflow).

Answer 4

Not at all safe.

Client side sanitation / validation should be used for several reasons:

• a simpler and faster way to tell the non-malicious user what they did wrong
• reduce the number of cases when a malicious user contacts your server (in case of errors)

Everything that you check can be changed because the client is not controlled by you. Things like dev console, fiddler , wirehark allows you to manipulate data in basically any way you want.

Thus, only the server is responsible for the actual sanitation / inspection.