javascript – 对XSS这是一个好主意吗？
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了javascript – 对XSS这是一个好主意吗？，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3243字，纯文字阅读大概需要5分钟。
内容图文
因为使用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>
现在浏览器将< scripts> .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(‘<script src=”http://code.jquery.com/jquery-1.5.2.min.js”></scr’ + ‘ipt>’);
您不需要“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.您可以将其称为全局设置.
jsPolicy简而言之：
HTML解析器 – >将脚本发送到JavaScript引擎 – >与jsPolicy比较 – >被允许？
A)是的,通过JavaScript引擎执行
B)不,忽略并向网站管理员发送报告
EDIT3：
参考Mike’s comment,这也是一个可能的设置：
window.policy.eval = false;
解决方法:
跨站点脚本在客户端进行.您的策略是在客户端定义的.看到问题？
我喜欢内容安全策略,我在所有项目中使用它.事实上,我正在开发一个JavaScript框架,它的一个要求是“对CSP友好”.
CSP> crossdomain.xml>你的政策.
内容总结
以上是互联网集市为您收集整理的javascript – 对XSS这是一个好主意吗？全部内容，希望文章能够帮你解决javascript – 对XSS这是一个好主意吗？所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。