Question

因为使用Origin / X-Frame-Options http标头并不是很受欢迎，我不认为Firefox中的新CSP会更好（开销，复杂等）我想提出一个建议一个新的JavaScript / ECMA版本。

但首先我发表这个想法，你可以说它是不是坏了。我称之为简单 jsPolicy ：

每个使用JavaScript的人都将脚本放在他的html头中。那么为什么我们不使用它们来添加我们的策略来控制所有后续脚本。例如：

<html>
<head>
<title>Example</title>
<script>
window.policy.inner = ["\nfunction foo(bar) {\n  return bar;\n}\n", "foo(this);"];
</script>
</head>
<body>
<script>
function foo(bar) {
  return bar;
}
</script>
<a href="#" onclick="foo(this);">Click Me</a>
<script>
alert('XSS');
</script>
</body>
</html>

现在，浏览器将＆lt; scripts＆gt; .innerHTML和onclick.value与策略中的那些进行比较，因此不会执行（忽略）最后一个脚本元素块。

当然，将所有内联代码加倍是没有用的，所以我们使用校验和。例如：

crc32("\nfunction foo(bar) {\n  return bar;\n}\n");

结果“1077388790”

现在是完整的例子：

if (typeof window.policy != 'undefined') {
  window.policy.inner = ["1077388790", "2501246156"];
  window.policy.url = ["http://code.jquery.com/jquery*.js","http://translate.google.com/translate_a/element.js?cb=googleTranslateElementInit"];
  window.policy.relative = ["js/*.js"];
  window.policy.report = ["api/xssreport.php"];
}

浏览器只需要比较是否在policy.inner中设置了内联脚本的校验和，或者是否script.src URL适合policy.url。

注意：policy.relative背后的想法是仅允许本地脚本：

window.policy.url = false;
window.policy.relative = ["js/*.js"];

注意：policy.report应该与CSP几乎相同（将阻止的脚本和URL发送到api）：
https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-unofficial-draft-20110315.html#violation-report-syntax

重要的：

政策不能设置两次（否则会抛出警告）=常量
要考虑：策略只能在头部设置（否则会发出警告）
该策略仅用于检查属于html源的脚本，而不是用于即时放置的脚本。例：
document.write（'＆lt; script src =“http://code.jquery.com/jquery-1.5.2.min.js”＆gt;＆lt; / scr'+'ipt＆gt;'）;
您不需要“http：//code.jquery.com ...”的policy.url定义，因为policy.inner校验和验证了完整的脚本源。这意味着即使policy.url设置为false，也会加载源（是的，它仍然是安全的！）。这可以简单地使用该策略。
如果缺少其中一项政策，则没有限制。这意味着空policy.relative会导致允许所有本地文件。这保证了向后兼容性
如果其中一个策略设置为“false”，则不允许使用（默认为true）。例：
policy.inner = false;
这不允许任何内联脚本
该策略仅忽略不允许的脚本并向控制台发出警告（错误将停止执行允许的脚本，这不是必需的）

我认为这会使XSS变得不可能，而不是CSP，它也会避免持久的XSS（只要没有人覆盖策略），并且更新会更容易。

您怎么看？

修改
以下是Javascript中的示例：
http://www.programmierer-forum.de/php/js-policy-against-xss.php

当然我们无法控制脚本执行，但它显示了如果jsPolicy兼容的浏览器可以如何工作。

EDIT2：
不要以为我在谈论编写一个小的javascript函数来检测xss !!我的 jsPolicy 想法必须是新JavaScript引擎的一部分。您可以将它与放置在.htaccess文件中的php设置进行比较。您无法在运行时更改此设置。相同的要求适用于jsPolicy。您可以将其称为global setting。

jsPolicy简而言之：
HTML解析器 - ＆gt;将脚本发送到JavaScript引擎 - ＆gt;与jsPolicy比较 - ＆gt;是允许的？
A）是的，通过JavaScript引擎执行 B）不，忽略并向网站管理员发送报告

EDIT3 ：
参考Mike's comment这也是一个可能的设置：

window.policy.eval = false;

Answer 1

跨客户端脚本在客户端进行。您的策略是在客户端定义的。看到问题了？

我喜欢内容安全策略，我在所有项目中使用它。事实上，我正在开发一个JavaScript框架，它的一个要求是“对CSP友好。”

CSP＆gt; crossdomain.xml＆gt;你的政策。

Answer 2

绝大多数XSS攻击来自“可信”来源，至少就浏览器而言。它们通常是回声用户输入的结果，例如在论坛中，并没有正确地逃避输入。你永远不会从链接到jquery获得XSS，并且你来自任何其他链接源的极很少。

如果您尝试进行跨域脚本编写，则无法获得远程脚本的校验和。

所以虽然你的想法看起来很好，但我并没有真正看到它。

Answer 3

这个想法不断浮出水面并经常重新浮动......每次安全专家都将其揭穿并不意味着听起来很苛刻，但这不是开发问题，而是安全问题。具体而言，大多数开发人员都没有意识到有多少变体，向量，漏洞利用和规避技术。

正如这里提到的其他一些答案，问题是你的解决方案无法解决问题，是否信任任何到达浏览器的东西，因为在客户端你无法知道代码是什么什么是数据即使您的解决方案也无法阻止这种情

参见例如this question on ITsec.SE了解实施此问题的一些实际问题。（你的问题有点像那个，或多或少......）

顺便说一句，重新CSP - 请检查other question on ITsec.SE。

Answer 4

该策略仅用于检查属于html源的脚本，而不是用于即时放置的脚本。例：文件撰写（ ''）; 您不需要“http：//code.jquery.com ...”的policy.url定义，因为policy.inner校验和验证了完整的脚本源。这意味着即使policy.url设置为false，也会加载源（是的，它仍然是安全的！）。这可以简单地使用该政策。

看起来你已经把整场比赛送到了这里。

如果我有像

这样的代码

// Pull parameters out of query string.
var match = location.search.match(/[&?]([^&=]+)=([^&]*)/);

window[decodeURIComponent(match[1])](decodeURIComponent(match[2]));

有人欺骗用户使用查询字符串?eval=alert%28%22pwned%22%29访问我的网站，然后他们已经过XSS，并且您的政策没有采取任何措施阻止它。

这对XSS来说是个好主意吗？

4 个答案: