XSS 攻击的预防
Posted aurstin
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了XSS 攻击的预防相关的知识,希望对你有一定的参考价值。
XSS 攻击的预防
XSS 攻击有两大要素:
1.攻击者提交恶意代码。
2.浏览器执行恶意代码。
针对第一个要素:我们是否能够在用户输入的过程,过滤掉用户输入的恶意代码呢?
输入过滤
在用户提交时,由前端过滤输入,然后提交到后端。这样做是否可行呢?
答案是不可行。一旦攻击者绕过前端过滤,直接构造请求,就可以提交恶意代码了。
那么,换一个过滤时机:后端在写入数据库前,对输入进行过滤,然后把“安全的”内容,返回给前端。这样是否可行呢?
我们举一个例子,一个正常的用户输入了 5 < 7
这个内容,在写入数据库前,被转义,变成了 5 < 7
。
问题是:在提交阶段,我们并不确定内容要输出到哪里。
这里的“并不确定内容要输出到哪里”有两层含义:
1.用户的输入内容可能同时提供给前端和客户端,而一旦经过了escapehtml()
,客户端显示的内容就变成了乱码( 5 < 7
)。
2.在前端中,不同的位置所需的编码也不同。
当 5 < 7
作为 HTML 拼接页面时,可以正常显示:< div title = “comment” > 5 < 7 </ div >。
当 5 < 7
通过 Ajax 返回,然后赋值给 javascript 的变量时,前端得到的字符串就是转义后的字符。这个内容不能直接用于 Vue 等模板的展示,也不能直接用于内容长度计算。不能用于标题、alert 等。
所以,输入侧过滤能够在某些情况下解决特定的 XSS 问题,但会引入很大的不确定性和乱码问题。在防范 XSS 攻击时应避免此类方法。
当然,对于明确的输入类型,例如数字、URL、电话号码、邮件地址等等内容,进行输入过滤还是必要的。
既然输入过滤并非完全可靠,我们就要通过“防止浏览器执行恶意代码”来防范 XSS。这部分分为两类:
1.防止 HTML 中出现注入。
2.防止 JavaScript 执行时,执行恶意代码。
预防存储型和反射型 XSS 攻击
存储型和反射型 XSS 都是在服务端取出恶意代码后,插入到响应 HTML 里的,攻击者刻意编写的“数据”被内嵌到“代码”中,被浏览器所执行。
预防这两种漏洞,有两种常见做法:
1.改成纯前端渲染,把代码和数据分隔开。
2.对 HTML 做充分转义。
纯前端渲染
纯前端渲染的过程:
1.浏览器先加载一个静态 HTML,此 HTML 中不包含任何跟业务相关的数据。
2.然后浏览器执行 HTML 中的 JavaScript。
3.JavaScript 通过 Ajax 加载业务数据,调用 DOM API 更新到页面上。
在纯前端渲染中,我们会明确的告诉浏览器:下面要设置的内容是文本(.innerText
),还是属性(.setAttribute
),还是样式(.style
)等等。浏览器不会被轻易的被欺骗,执行预期外的代码了。
但纯前端渲染还需注意避免 DOM 型 XSS 漏洞(例如 onload
事件和 href
中的 javascript:xxx
等,请参考下文”预防 DOM 型 XSS 攻击“部分)。
在很多内部、管理系统中,采用纯前端渲染是非常合适的。但对于性能要求高,或有 SEO 需求的页面,我们仍然要面对拼接 HTML 的问题。
转义 HTML
如果拼接 HTML 是必要的,就需要采用合适的转义库,对 HTML 模板各处插入点进行充分的转义。
常用的模板引擎,如 doT.js、ejs、FreeMarker 等,对于 HTML 转义通常只有一个规则,就是把 & < > " ‘ /
这几个字符转义掉,确实能起到一定的 XSS 防护作用,但并不完善:
|XSS 安全漏洞|简单转义是否有防护作用|
|-|-|
|HTML 标签文字内容|有|
|HTML 属性值|有|
|CSS 内联样式|无|
|内联 JavaScript|无|
|内联 JSON|无|
|跳转链接|无|
所以要完善 XSS 防护措施,我们要使用更完善更细致的转义策略。
例如 Java 工程里,常用的转义库为 org.owasp.encoder
。以下代码引用自 org.owasp.encoder 的官方说明。
<!-- HTML 标签内文字内容 -->
< div > < %= Encode.forHtml ( UNTRUSTED ) %> </ div >
<!-- HTML 标签属性值 -->
< input value = "<%= Encode.forHtml(UNTRUSTED) %>" />
<!-- CSS 属性值 -->
< div style = "width:<= Encode.forCssString(UNTRUSTED) %>" >
<!-- CSS URL -->
< div style = "background:<= Encode.forCssUrl(UNTRUSTED) %>" >
<!-- JavaScript 内联代码块 -->
< script >
var msg = "<%= Encode.forJavaScript(UNTRUSTED) %>" ;
alert(msg);
</ script >
<!-- JavaScript 内联代码块内嵌 JSON -->
< script >
var __INITIAL_STATE__ = JSON .parse( ‘<%= Encoder.forJavaScript(data.to_json) %>‘ );
</ script >
<!-- HTML 标签内联监听器 -->
< button
onclick = "alert(‘<%= Encode.forJavaScript(UNTRUSTED) %>‘);" >
click me
</ button >
<!-- URL 参数 -->
< a href = "/search?value=<%= Encode.forUriComponent(UNTRUSTED) %>&order=1#top" >
<!-- URL 路径 -->
< a href = "/page/<%= Encode.forUriComponent(UNTRUSTED) %>" >
<!--
URL.
注意:要根据项目情况进行过滤,禁止掉 "javascript:" 链接、非法 scheme 等
-->
< a href = ‘<%=
urlValidator.isValid(UNTRUSTED) ?
Encode.forHtml(UNTRUSTED) :
"/404"
%>‘ >
link
</ a >
可见,HTML 的编码是十分复杂的,在不同的上下文里要使用相应的转义规则。
预防 DOM 型 XSS 攻击
DOM 型 XSS 攻击,实际上就是网站前端 JavaScript 代码本身不够严谨,把不可信的数据当作代码执行了。
在使用 .innerHTML
、.outerHTML
、document.write()
时要特别小心,不要把不可信的数据作为 HTML 插到页面上,而应尽量使用 .textContent
、.setAttribute()
等。
如果用 Vue/React 技术栈,并且不使用 v-html
/dangerouslySetInnerHTML
功能,就在前端 render 阶段避免 innerHTML
、outerHTML
的 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 漏洞呢?
经过一番搜索,找到了两个方法:
1.使用通用 XSS 攻击字符串手动检测 XSS 漏洞。
2.使用扫描工具自动检测 XSS 漏洞。
除了手动检测之外,还可以使用自动扫描工具寻找 XSS 漏洞,例如 Arachni、Mozilla HTTP Observatory、w3af 等。
XSS 攻击的总结
整体的 XSS 防范是非常复杂和繁琐的,我们不仅需要在全部需要转义的位置,对数据进行对应的转义。而且要防止多余和错误的转义,避免正常的用户输入出现乱码。
虽然很难通过技术手段完全避免 XSS,但我们可以总结以下原则减少漏洞的产生:
利用模板引擎
开启模板引擎自带的 HTML 转义功能。例如:
在 ejs 中,尽量使用
<%= data %>
而不是<%- data %>
;在 doT.js 中,尽量使用
{{! data }
而不是{{= data }
;在 FreeMarker 中,确保引擎版本高于 2.3.24,并且选择正确的
freemarker.core.OutputFormat
。
避免内联事件
尽量不要使用 onLoad="onload(‘{{data}}‘)"
、onClick="go(‘{{action}}‘)"
这种拼接内联事件的写法。在 JavaScript 中通过 .addEventlistener()
事件绑定会更安全。
避免拼接 HTML
前端采用拼接 HTML 的方法比较危险,如果框架允许,使用 createElement
、setAttribute
之类的方法实现。或者采用比较成熟的渲染框架,如 Vue/React 等。
时刻保持警惕
在插入位置为 DOM 属性、链接等位置时,要打起精神,严加防范。
增加攻击难度,降低攻击后果
通过 CSP、输入长度配置、接口安全措施等方法,增加攻击的难度,降低攻击的后果。
主动检测和发现
可使用 XSS 攻击字符串和自动扫描工具寻找潜在的 XSS 漏洞。
参考文献
Wikipedia. Cross-site scripting, Wikipedia.
OWASP. XSS (Cross Site Scripting) Prevention Cheat Sheet, OWASP.
OWASP. Use the OWASP Java Encoder-Use-the-OWASP-Java-Encoder), GitHub.
Ahmed Elsobky. Unleashing an Ultimate XSS Polyglot, GitHub.
Jad S. Boutros. Reducing XSS by way of Automatic Context-Aware Escaping in Template Systems, Google Security Blog.
Vue.js. v-html – Vue API docs, Vue.js.
React. dangerouslySetInnerHTML – DOM Elements, React.
原文参考:https://www.freebuf.com/articles/web/185654.html-美团技术团队
以上是关于XSS 攻击的预防的主要内容,如果未能解决你的问题,请参考以下文章
前端技能树,面试复习第 36 天—— 浏览器原理:如何预防 XSS 攻击与 CSRF 攻击