如何防止 JavaScript 中的原型污染 [英] How to prevent prototype pollution in JavaScript

问题描述

最近我偶然发现了 doT.js 中的漏洞.该漏洞的存在是因为攻击者可以利用原型污染来修改传递给 doT 的选项的值.

Recently I stumbled across a vulnerability in doT.js. The vulnerability exists because attackers can use prototype pollution to modify the values of the options passed in to doT.

示例:

var doT = require("dot");
var tempFn = doT.template("<h1>Here is a sample template " +
    "{{=console.log(23)}}</h1>");
tempFn({})

var doT = require("dot"); // prototype pollution attack vector
Object.prototype.templateSettings = {varname:"a,b,c,d,x=console.log(25)"};
// benign looking template compilation + application
var dots = require("dot").process({path: "./resources"});
dots.mytemplate();

然后我开始思考:这是否意味着几乎任何 JavaScript 库的 API 选项都可能因原型污染而受到损害?

Then I got to thinking: doesn't this mean that virtually any JavaScript library's API options can be compromised through prototype pollution?

例如，这里的 express.static 与选项一起使用.

For example, here's express.static used with options.

var options = {
  dotfiles: 'ignore',
  etag: false,
  extensions: ['htm', 'html'],
  index: false,
  maxAge: '1d',
  redirect: false,
  setHeaders: function (res, path, stat) {
    res.set('x-timestamp', Date.now())
  }
}

app.use(express.static('public', options))

攻击者不能设置Object.prototype.redirect = true，如果用户未指定，会发生重定向吗?肯定还有更多恶意用例.

Couldn't an attacker set Object.prototype.redirect = true, and, if unspecified by the user, a redirect would occur? And there are surely many more malicious use cases.

作为库作者，可以做些什么来允许传递选项但防止原型污染?

What can be done, as a library author, to allow passing in options but safeguard against prototype pollution?

我特别关注与 NPM 一起分发的包.例如，doT.js 的作者可以做些什么来解决这个漏洞?

I'm focusing specifically on packages distributed with NPM. For example, what could the authors of doT.js do to resolve the vulnerability?

推荐答案

作为库作者，可以做些什么来允许传递选项但防止原型污染?

What can be done, as a library author, to allow passing in options but safeguard against prototype pollution?

您可以使用 .hasOwnProperty() 检测属性是在您的实际对象上还是通过原型继承.但是，攻击者也可以覆盖 .hasOwnProperty() 并改变其行为.

You can detect whether a property is on your actual object or inherited via the prototype with .hasOwnProperty(). But, heck an attacker could overwrite .hasOwnProperty() too and change its behavior.

正如我在评论中所说的，在他们的 Javascript 程序中使用你的库的人可以完全访问你的代码.因此，他们甚至不必使用原型污染来修改内容 - 他们可以随意修改您的代码.

As I've said in the comments, someone using your library in their Javascript program has FULL source code access to your code. So, they don't even have to use prototype pollution to modify things - they can just hack away at your code however they want.

要完全保护您的代码，您要么只分发在不同进程中运行并具有进程间 API(例如 http 服务器)的已编译可执行文件，要么必须将代码放入服务中并且仅以这种方式提供访问权限.如果您要分发 Javascript 库，就其本质而言，您必须分发源代码，以便使用您的库的程序员可以真正对它做任何他们想做的事情.他们甚至不必诉诸原型技巧.

To fully protect your code, you'd have to either distribute only a compiled executable that runs in a different process and has an interprocess API (such as an http server) or you'd have to put your code into a service and only offer access that way. If you're distributing a Javascript library, by its very nature, you have to distribute source so the programmer using your library can really do anything they want to it. They don't even have to resort to prototype trickery.

这篇关于如何防止 JavaScript 中的原型污染的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！