客户端HTML清理的安全性如何？

一尘不染

客户端HTML清理的安全性如何？

angularjs

最近，我一直在查看Pagedown.js，以在页面上使用mark-down而不是丑陋的只读textareas。

我非常谨慎，因为欺骗已转换的转换器似乎很容易。我已经看到了一些有关Angular.js及其html绑定的讨论，并且在Knockout.js
3.0发布时听到了一些关于html绑定以前不安全的信息。

似乎有人需要做的所有事情来禁用Pagedown.js中的消毒剂，例如-

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;
};

他们可以打开一个站点进行脚本注入。那不是真的吗

编辑

那么，为什么这样的库会打包一个净化器以使用客户端呢？当然，他们说不要渲染未经消毒的html，但下一行说要使用Markdown.Sanitizer。

Angular如何不使用消毒剂服务，还是闹剧呢？

阅读 161

2020-07-04

共1个答案

一尘不染

我相信对这种“消毒剂”的目的和性质有些误解。

清理程序（例如Angular的ngSanitize）的目的不是防止“不良”数据发送到服务器端。相反，这是另一种方式：那里有一个消毒程序来
保护非恶意用户免受恶意数据的侵害（是由于服务器端的安全漏洞（是的，没有任何设置是完美的）或从其他来源获取的）（那些您无法控制的））。

当然，作为客户端功能，可以绕过消毒剂，但是（因为有消毒剂可以保护用户（而不是服务器）），绕过它只会使绕过器不受保护（您不能对此做任何事情），您也不必在乎-
这是他们的选择）。

此外，清理程序还可以扮演另一个（可能更重要的）角色：清理程序是一种工具，可以帮助开发人员更好地组织其代码，从而更易于测试某些类型的漏洞（例如XSS攻击），甚至帮助进行此类安全漏洞的实际代码审核。

在我看来， Angular文档
很好地总结了这个概念：

严格上下文转义（SCE）是一种模式，其中AngularJS要求在某些上下文中进行绑定以产生一个值，该值被标记为可安全用于该上下文。
[…]
SCE以以下方式帮助编写代码：（a） 默认情况下是安全的， 并且（b）使得对安全漏洞（例如XSS，clickjacking等）的审核
更加容易 。

[…]
在一个更现实的例子，一个可呈现用户评论，博客文章等通过绑定。（HTML只是上下文的一个示例，其中呈现用户控制的输入会创建安全漏洞。）

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

您如何确保使用这些类型的绑定的每个位置都绑定到由库清理过的值（或返回为服务器可以安全渲染的值）？如何确保您不会意外 删除该行消毒 过的值，或者
重命名了某些属性/字段 ，却忘记了更新与消毒过的值的绑定？

为了安全起见，默认情况下，您要确保禁止任何此类绑定，除非您可以确定 明确表示 在该上下文中使用值进行绑定 是安全的
。然后，您可以 审核您的代码 （只需执行简单的grep即可），以确保仅针对那些您可以轻易告知的安全值进行此操作-
因为这些值是从服务器接收到的，由库进行了清理，等等。您可以 组织自己的代码代码库来解决这个问题
-也许只允许特定目录中的文件执行此操作。确保该代码公开的内部API不会将任意值标记为安全值，这样就变得 更加易于管理 。

注1： 重点是我的。
注2： 很抱歉提供冗长的报价，但是我认为这是一件非常重要的事情（尽管很敏感），并且经常被人们误解。

2020-07-04