我最近一直在寻找Pagedown.js,因为我在页面上使用标记而不是丑陋的只读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如何使用消毒剂服务不对它开放,或者这只是一场闹剧?
答案 0 :(得分:18)
我认为对这类消毒剂的目的和性质存在一点误解。
清洁剂的目的(例如Angular' ngSanitize
)不以防止"坏"数据发送到服务器端。反过来说:消毒剂可以保护非恶意用户免受恶意数据攻击(服务器端的安全漏洞(是的,没有设置完美)或从其他来源(你无法控制的)获取。)。
当然,作为一个客户端功能,可以绕过消毒剂,但是(因为消毒剂可以保护用户(而不是服务器))绕过它只会使旁通者不受保护(你可以&#39)什么都不做,也不应该关心 - 这是他们的选择。
此外,消毒剂(罐头)还有另一个(可能更重要的)角色:消毒剂是一种工具,可以帮助开发人员更好地组织他们的代码,以便更容易测试某些类型的漏洞(例如XSS攻击) )甚至可以帮助实际的代码审核这类安全漏洞。
在我看来, Angular docs 非常巧妙地总结了这个概念:
严格上下文转义(SCE)是一种模式,在这种模式下,AngularJS需要在某些上下文中绑定,以产生一个标记为可安全用于该上下文的值。
[...]
SCE协助编写代码的方式:(a)默认是安全的和(b)使审核来解决安全漏洞,例如XSS,点击劫持等。 a很容易。[...]
在更现实的示例中,可以通过绑定来呈现用户评论,博客文章等。 (HTML只是渲染用户控制的输入会产生安全漏洞的上下文的一个示例。)对于HTML的情况,您可以在客户端或服务器端使用库来清理不安全的HTML,然后再绑定到值并在文档中呈现它。
您如何确保使用这些类型绑定的每个地方都绑定到您的库清理过的值(或者您的服务器可以安全地返回?)如何确保您没有这样做?意外删除已清理值的行,或重命名某些属性/字段并忘记更新绑定到已清理的值?
默认情况下,为了确保安全,您需要确保不允许任何此类绑定,除非您可以确定某些内容明确表示安全在该上下文中使用值进行绑定。然后,您可以审核您的代码(一个简单的grep会这样做),以确保只对那些您可以轻松告诉他们安全的值进行此操作 - 因为它们是从您的服务器接收的,由您的库清理您可以组织代码库以帮助解决此问题 - 可能只允许特定目录中的文件执行此操作。确保该代码公开的内部API不会将任意值标记为安全,然后变为更易于管理的任务。
<子>
注1:重点是我的。
注意2:对于冗长的引用感到抱歉,但我认为这是一个非常重要(尽可能敏感)的问题,而且常常被误解。
子>
答案 1 :(得分:8)
您无法对客户端进行消毒。任何人都可以随时关闭JavaScript或更改值并将其提交到您的服务器。
服务器需要来仔细检查。在我看来,客户端实际上只是一个可用性功能。因此,他们知道他们输入的内容是错误还是正确。
响应编辑:
大多数都是便利或提供功能。例如,unobtrusive validation如果输入的数字无效,我的文本框会显示为红色。这很好,我不需要发布和检查,然后更改文本框边框blablablabla ...
但是当他们发帖时,我仍然需要验证他们的数据。我通常将其保存在一个核心库中,该库可以跨应用程序共享(Web,Web服务,移动应用程序,胖客户端等)
可用性验证因平台而异。但在核心,在任何应用程序信任数据之前,它必须在其信任障碍内检查它。没有人可以在服务器上更改if
后面的值,但任何人都可以在不跳过我的JS的情况下更改浏览器中的值。
答案 2 :(得分:1)
Pagedown可以在服务器和客户端上运行。
为了在客户端上清理html,对输出而不是输入进行清理更有意义。在向服务器发送数据之前,您不会进行清理,但在从服务器接收数据后,您可能会进行清理。
想象一下,在客户端上进行Web服务调用并从第三方服务获取数据。在呈现之前,它可以通过客户端上的清理程序传递。用户可以在他们自己的计算机上禁用清理,但他们只会伤害自己。
出于安全原因,它也很有用,只是为了防止用户输入意外地修改周围页面的格式。例如在键入带有实时预览的html帖子时(如在StackOverflow上)。
答案 3 :(得分:0)
根本不安全。
客户端卫生/验证应该用于以下几个原因:
您验证的所有内容都可以更改,因为客户端不受您控制。像开发控制台,fiddler,wireshark这样的东西允许你以任何你想要的方式操纵数据。
因此,只有服务器负责真正的卫生/验证。