前端安全系列：如何防止XSS攻击？

DOM 中的内联变乱监听器，如 location、onclick、onerror、onload、onmouseover 等，<a> 标签的 href 属性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作为代码运行。假如不行信的数据拼接到字符串中转达给这些 API，很轻易发生安详隐患，请务必停止。

<!-- 内联变乱监听器中包括恶意代码 -->  
<img onclick="UNTRUSTED" onerror="UNTRUSTED" src="data:image/png,">  
<!-- 链接内包括恶意代码 -->  
<a href="UNTRUSTED">1</a>  
<script>  
// setTimeout()/setInterval() 中挪用恶意代码  
setTimeout("UNTRUSTED")  
setInterval("UNTRUSTED")  
// location 挪用恶意代码  
location.href = 'UNTRUSTED'  
// eval() 中挪用恶意代码  
eval("UNTRUSTED")  
</script> 

假如项目中有效到这些的话，必然要停止在字符串中拼接不行信数据。

其他 XSS 防御法子

固然在渲染页面和执行 JavaScript 时，通过审慎的转义可以防备 XSS 的产生，但完全依赖开拓的审慎如故是不足的。以下先容一些通用的方案，可以低落 XSS 带来的风险和效果。

Content Security Policy

严酷的 CSP 在 XSS 的防御中可以起到以下的浸染：

•  榨取加载外域代码，防备伟大的进攻逻辑。
•  榨取外域提交，网站被进攻后，用户的数据不会泄漏到外域。
•  榨取内联剧本执行（法则较严酷，今朝发明 GitHub 行使）。
•  榨取未授权的剧本执行（新特征，Google Map 移动版在行使）。
•  公道行使上报可以实时发明 XSS，利于尽快修复题目。

关于 CSP 的详情，请存眷前端安详系列后续的文章。

输入内容长度节制

对付不受信赖的输入，都应该限制一个公道的长度。固然无法完全防备 XSS 产生，但可以增进 XSS 进攻的难度。

其他安详法子

•  HTTP-only Cookie: 榨取 JavaScript 读取某些敏感 Cookie，进攻者完成 XSS 注入后也无法窃取此 Cookie。
•  验证码：防备剧本假充用户提交伤害操纵。

XSS 的检测

上述经验让小明收成颇丰，他也学会了怎样去提防和修复 XSS 裂痕，在一般开拓中也具备了相干的安详意识。但对付已经上线的代码，怎样去检测个中有没有 XSS 裂痕呢？

颠末一番搜刮，小明找到了两个要领：

1.  行使通用 XSS 进攻字符串手动检测 XSS 裂痕。
2.  行使扫描器材自动检测 XSS 裂痕。

在Unleashing an Ultimate XSS Polyglot一文中，小明发明白这么一个字符串：

jaVasCript:/*-/*`/*`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>x3csVg/<sVg/oNloAd=alert()//>x3e 

它可以或许检测到存在于 HTML 属性、HTML 笔墨内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等多种上下文中的 XSS 裂痕，也能检测 eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write() 等 DOM 型 XSS 裂痕，而且能绕过一些 XSS 过滤器。

小明只要在网站的各输入框中提交这个字符串，可能把它拼接到 URL 参数上，就可以举办检测了。

http://xxx/search?keyword=jaVasCript%3A%2F*-%2F*%60%2F*%60%2F*%27%2F*%22%2F**%2F(%2F*%20*%2FoNcliCk%3Dalert()%20)%2F%2F%250D%250A%250d%250a%2F%2F%3C%2FstYle%2F%3C%2FtitLe%2F%3C%2FteXtarEa%2F%3C%2FscRipt%2F--!%3E%3CsVg%2F%3CsVg%2FoNloAd%3Dalert()%2F%2F%3E%3E 

除了手动检测之外，还可以行使自动扫描器材探求 XSS 裂痕，譬喻 Arachni、Mozilla HTTP Observatory、w3af 等。

XSS 进攻的总结

我们回到最开始提出的题目，信托同窗们已经有了谜底：

1.XSS 防御是后端 RD 的责任，后端 RD 应该在全部用户提交数据的接口，对敏感字符举办转义，才气举办下一步操纵。

不正确。由于：

• 防御存储型和反射型 XSS 是后端 RD 的责任。而 DOM 型 XSS 进攻不产生在后端，是前端 RD 的责任。防御 XSS 是必要后端 RD 和前端 RD 配合参加的体系工程。

• 转义应该在输出 HTML 时举办，而不是在提交用户输入时。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!