客户端 HTML 清理的安全性如何? [英] How safe is client-side HTML Sanitization?

问题描述

我最近一直在研究 Pagedown.js，因为它可以在我的页面上使用 Mark-down 而不是丑陋的只读文本区域.

I have been looking at Pagedown.js lately for the allure of using mark-down on my pages instead of ugly readonly textareas.

我非常谨慎，因为它似乎很容易欺骗经过消毒的转换器.我看到了一些关于 Angular.js 的讨论，它是 html 绑定，并且在 Knockout.js 3.0 出现时也听说过一些关于 html 绑定的不安全性.

I am extremely cautious though as it seems easy enough to dupe the sanitized converter. I have seen some discussion around Angular.js and it's html bindings and also heard something when Knockout.js 3.0 came out that there had been a previous unsafeness to the html binding.

似乎有人需要做的就是在 Pagedown.js 中禁用消毒剂，例如 -

It would seem all someone would need to do to disable the sanitizer in Pagedown.js for instance 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 could open a site up to script injection. Is that not true?

编辑

那么为什么像这样的库会打包一个消毒剂来使用客户端呢?当然他们说不要渲染未经处理的 html，但下一行说使用 Markdown.Sanitizer..

Then why would libraries like that package a sanitizer to use client-side? Sure they say don't render unsanitized html but the next line says use Markdown.Sanitizer..

Angular 为何对消毒剂服务不开放，或者这只是一场闹剧?

How is Angular not open to it with the sanitizer service or is that just a farce as well?

推荐答案

我相信人们对此类消毒剂"的目的和性质存在一些误解.

I believe there is a little misunderstanding about the purpose and nature of such "sanitizers".

清理程序(例如 Angular 的 ngSanitize)的目的是不是防止将坏"数据发送到服务器端.恰恰相反:消毒剂可以保护非恶意用户免受恶意数据的侵害(要么是服务器端安全漏洞的结果(是的，没有完美的设置)或从其他来源(您无法控制的来源)获取).

The purpose of a sanitizer (e.g. Angular's ngSanitize) is not to prevent "bad" data from being sent to the server-side. It is rather the other way around: A sanitizer is there to protect the non-malicious user from malicious data (being either a result of a security hole on the server side (yeah, no setup is perfect) or being fetched from other sources (ones that you are not in control of)).

当然，作为客户端功能，可以绕过消毒剂，但是(因为消毒剂是为了保护用户(而不是服务器))绕过它只会使绕过者不受保护(您不能做任何事情，也不应该在乎 - 这是他们的选择).

Of course, being a client-side feature, a sanitizer could be bypassed, but (since the sanitizer is there to protect the user (not the server)) bypassing it would only leave the bypasser unprotected (which you can't do anything about, nor shouldn't you care - it's their choice).

此外，消毒剂(可以)还有另一个(可能更重要)的作用:消毒剂是一种工具，可帮助开发人员更好地组织代码，使其更易于针对某些类型的漏洞(例如 XSS 攻击)进行测试) 甚至有助于实际代码审计此类安全漏洞.

Furthermore, sanitizers (can) have another (potentially more important) role: A sanitizer is a tool that helps the developer to better organize their code in a way that it is more easily testable for certain kinds of vulnerabilities (e.g. XSS attacks) and even helps in the actual code auditing for such kind of security holes.

在我看来，Angular docs 很好地总结了这个概念整齐:

In my opinion, the Angular docs summarize the concept pretty neatly:

严格上下文转义 (SCE) 是一种模式，在这种模式下，AngularJS 需要在某些上下文中进行绑定，以生成标记为可安全用于该上下文的值.
[...]
SCE 以 (a) 默认安全和 (b) 对安全漏洞(例如 XSS、点击劫持等)进行审核的方式协助编写代码.a容易多了.

Strict Contextual Escaping (SCE) is a mode in which AngularJS requires bindings in certain contexts to result in a value that is marked as safe to use for that context.
[...]
SCE assists in writing code in way that (a) is secure by default and (b) makes auditing for security vulnerabilities such as XSS, clickjacking, etc. a lot easier.

[...]
在更现实的示例中，可以通过绑定呈现用户评论、博客文章等.(HTML 只是呈现用户控制的输入会产生安全漏洞的上下文的一个示例.)

[...]
In a more realistic example, one may be rendering user comments, blog articles, etc. via bindings. (HTML is just one example of a context where rendering user controlled input creates security vulnerabilities.)

对于 HTML，您可以在客户端或服务器端使用库来清理不安全的 HTML，然后再绑定到值并将其呈现在文档中.

For the case of HTML, you might use a library, either on the client side, or on the server side, to sanitize unsafe HTML before binding to the value and rendering it in the document.

您将如何确保使用这些类型绑定的每个地方都绑定到一个由您的库清理的值(或作为安全返回供您的服务器呈现?)您如何确保您没有意外删除清理过的值的行，或者重命名了一些属性/字段而忘记更新到清理过的值的绑定?

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

为了在默认情况下安全，您希望确保禁止任何此类绑定，除非您可以确定某些内容明确表示在该上下文中使用绑定值是安全的.然后，您可以审核您的代码(一个简单的 grep 就可以)，以确保仅对那些您可以轻松判断是安全的值执行此操作 - 因为它们是从您的服务器收到的，并由您的库进行了清理等.您可以组织您的代码库以帮助解决此问题 - 也许只允许特定目录中的文件执行此操作.确保该代码公开的内部 API 不会将任意值标记为安全，然后成为更易于管理的任务.

To be secure by default, you want to ensure that any such bindings are disallowed unless you can determine that something explicitly says it's safe to use a value for binding in that context. You can then audit your code (a simple grep would do) to ensure that this is only done for those values that you can easily tell are safe - because they were received from your server, sanitized by your library, etc. You can organize your codebase to help with this - perhaps allowing only the files in a specific directory to do this. Ensuring that the internal API exposed by that code doesn't markup arbitrary values as safe then becomes a more manageable task.

<子>注意 1:重点是我的.
注 2: 抱歉引用过长，但我认为这是一个非常重要(同样敏感)的问题，而且经常被误解.

_{Note 1: Emphasis is mine.
Note 2: Sorry for the lengthy quote, but I consider this to be a very improtant (as much as sensitive) matter and one that is too often misunderstood.}

这篇关于客户端 HTML 清理的安全性如何?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！