web安全机制问题详解之一:XSS

1,524 阅读9分钟

web安全是前端开发者们需要关注和掌握的必要内容。在写该记录之前,我也总是对安全策略这方面点到为止;但是在真正了解之后才发现,页面能安全活到现在也算是老天和后台、运维同事的关照了。😂

本次记录主要有三点:XSS、CSRF、CSP、请求劫持和https。

这一篇,会详细记录xss的攻击和防御。另外两点会分为两篇记录文:详解二详解详解四

1. XSS 漏洞的发生和修复

XSS(cross-site scripting)跨站脚本攻击是指页面被注入恶意代码。

例1:根据请求接口URL参数决定页面展示内容时:

<input type="text" value="<%= getParameter("keyword") %>">
<button>搜索</button>
<div>
  您搜索的关键词是:<%= getParameter("keyword") %>
</div>

getParameter('keyword')是http请求的函数

url:http://xxx/search?keyword="><script>alert('xss');</script>"

参数keyword会被重新拼接到HTML中:

<input type="text" value=""><script>alert('XSS');</script>"> 

<button>搜索</button><div> 您搜索的关键词是:"><script>alert('XSS');</script> </div>

恶意代码将被执行。

面对这种情况如何防范?

这里的原因是,浏览器把用户的输入当成脚本执行了,那么将这段内容转成文本就行。

<input type="text" value="<%= escapeHTML(getParameter("keyword")) %>">
<button>搜索</button>
<div>
  您搜索的关键词是:<%= escapeHTML(getParameter("keyword")) %>
</div>

excapeHTML()按照以下规则进行转译:

|字符|转义后的字符| |-|-| |&|&amp;| |<|&lt;| |>|&gt;| |"|&quot;| |'|&#x27;| |/|&#x2F;|

经转译后,最终浏览器接收到的响应为:

<input type="text" value="&quot;&gt;&lt;script&gt;alert(&#x27;XSS&#x27;);&lt;&#x2F;script&gt;">
<button>搜索</button>
<div>
  您搜索的关键词是:&quot;&gt;&lt;script&gt;alert(&#x27;XSS&#x27;);&lt;&#x2F;script&gt;
</div>

例2:a标签的href属性

<a href="<%= escapeHTML(getParameter("redirect_to")) %>">跳转...</a>

getParameter('redirect_to')为URL http://xxx/?redirect_to=javascript:alert('XSS')

即使做了转译,javascript:仍然是正确的href属性值,包括在javascript:前面加空格%20,也依然会跳过HTML转译检查。

解决办法:白名单过滤,禁止'javascript:'链接、非法schema等。

例3:把数据通过JSON的方式内联到HTML中

<script>
var initData = <%= data.toJSON() %>
</script>

这时不能使用escapeHTML(),因为转译"后,JSON格式会被破坏。

但是内联JSON也有不安全的地方:

  • 当 JSON 中包含 U+2028U+2029 这两个字符时,不能作为 JavaScript 的字面量使用,否则会抛出语法错误。
  • 当 JSON 中包含字符串 </script> 时,当前的 script 标签将会被闭合,后面的字符串内容浏览器会按照 HTML 进行解析;通过增加下一个 <script> 标签等方法就可以完成注入。

因此,需要escapeEmbedJSON()函数,对内联JSON进行转义:

|字符|转义后的字符| |-|-| |U+2028|\u2028| |U+2029|\u2029| |<|\u003c|

2. 漏洞总结

  • 恶意内容以<script>标签形式注入HTML内嵌的文本中
  • 内联的javascript中,拼接的数据超过escapeHTML()的限制
  • 标签属性中,恶意内容若包含引号,可以注入其他属性或标签
  • 标签的href、src属性中,包含javascript:等可执行代码
  • 在onload, onerror, onclick等事件中,注入恶意代码

3. XSS攻击的分类

利用恶意脚本攻击,攻击者可以获取用户的敏感信息如Cookie、SessionID等。

用户输入行为,以下内容都不可信:

  • 来自用户的 UGC(user generated content) 信息
  • 来自第三方的链接
  • URL 参数
  • POST 参数
  • Referer (可能来自不可信的来源)
  • Cookie (可能来自其他子域注入)

根据攻击来源,可以分为存储型、反射型和DOM型三类。

|类型|存储区|插入点|

|存储型 XSS|后端数据库|HTML| |反射型 XSS|URL|HTML| |DOM 型 XSS|后端数据库/前端存储/URL|前端 JavaScript

存储型XSS攻击步骤:

1. 攻击者将恶意代码提交到目标网站数据库

2. 用户打开目标网站时,网站服务端将恶意代码从数据库提出,拼接到HTML中返回给浏览器

3. 用户浏览器接收到响应后解析执行,恶意代码也被执行

4. 恶意代码窃取用户数据并发送到攻击者网站,或者冒充用户行为,调用目标网站接口执行恶意操作

这种攻击常见于带有用户保存数据的网站功能,如论坛发帖、商品评论、用户私信等。

反射型XSS攻击步骤:

1. 攻击者构造出包含恶意代码的URL

2. 用户打开含恶意代码的URL,网站服务端取出恶意代码并拼接到HTML返回浏览器

3. 浏览器解析执行,窃取用户数据或冒充用户行为

与存储型的区别,反射型的恶意代码存储在URL,存储型的存储在数据库。反射型XSS漏洞常见于通过URL传参的功能,如网站搜索、跳转等。

由于需要用户主动打开,所以会有多种诱导用户点击的手段。POST的内容也可以触发反射型XSS,只不过需要构造表单提交页面引导用户点击,所以少见。

DOM型攻击步骤:

1. 攻击者构造出包含恶意代码的URL

2. 用户打开该URL

3. 浏览器接收到响应后解析执行,前端JS取出URL中的恶意代码并执行。

4. 恶意代码窃取用户数据并发送到攻击者网站,或者冒充用户行为,调用目标网站接口执行恶意操作

DOM型XSS属于前端Javascript自身的安全漏洞,而前两种属于服务端的安全漏洞。

4. XSS攻击的预防

据上所属,XSS攻击主要有两大要素:

1. 攻击者提交恶意代码

2. 浏览器执行恶意代码

从一开始的案列中得知,最简单的是对用户输入文本的转义。但是也知道转义存在弊端。

除此转义之外,也可以对一些必要的输入做检查,如电话号码、数字、URL、邮件地址等。

预防存储型和反射型XSS

存储型和反射型都是在服务端取出恶意代码后,插入html的,被浏览器执行。所以常见的预防方式有两种:改成纯前端渲染,把代码和数据分隔开;对html做充分转义。

纯前端渲染:浏览器先加载静态页面(不包含任何业务相关的数据),再执行javascript,通过ajax加载业务数据,调用DOM API更新到页面上。纯前端渲染中,浏览器会明确文本(.innerText),属性(.setAttribute),还是样式(.style)等等。但仍须注意避免DOM型XSS(请参考下文‘预防DOM型XSS攻击’)。

很多内部、管理系统中,适合使用纯前端渲染;但对于性能要求高的,或有SEO需求的页面,拼接HTML的问题仍存在。

转义HTML:除了上面说到的excapeHTML()等方法外,还可以直接使用模板引擎,如ejs、doT.js、FreeMarker等,通常就是把& < > " ' /这些转义掉,确实能起到一定的转义作用,但并不完善。所以还可以结合后台编程语言,找到合适的转义库。如JAVA工程里,常用的转义库org.owasp.encode,不同上下文要使用相应的转移规则。

预防DOM型XSS攻击

DOM型XSS攻击就与前段javascript代码本身是否严谨有关。

尽量避免使用.innerHTML、outerHTML、document.write(),而换成.textContent、.setAttribute()等。

如果用Vue/React技术栈,并且不使用v-html/dangerouslySetInnerHTML功能,就在前段render阶段避免innerHTL、outerHTML的XSS隐患。

DOM 中的内联事件监听器,如 locationonclickonerroronloadonmouseover 等,<a> 标签的 href 属性,JavaScript 的 eval()setTimeout()setInterval() 等,都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API,很容易产生安全隐患,请务必避免。

其他XSS预防措施

Content Security Policy,俗称csp,在http请求时可在请求头中显示。作用:

  • 禁止加载规定域以外的代码
  • 禁止外域提交,网站被攻击后,用户的数据不会泄露到外域
  • 禁止内联脚本执行
  • 禁止未授权脚本执行
  • 合理上报XSS问题,利于尽快修复

输入内容长度控制。

cookie的http-only限制:cookie只允许同域http请求携带,不允许读取和修改。

验证码:图片验证码、短信验证码等等。

5. XSS检测

通用XSS攻击字符串手动检测。

扫描工具自动检测,如Arachni、Mozilla HTTP Observatory、w3af等。

6. 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 的方法比较危险,如果框架允许,使用 createElementsetAttribute 之类的方法实现。或者采用比较成熟的渲染框架,如 Vue/React 等。
  • 时刻保持警惕 在插入位置为 DOM 属性、链接等位置时,要打起精神,严加防范。
  • 增加攻击难度,降低攻击后果 通过 CSP、输入长度配置、接口安全措施等方法,增加攻击的难度,降低攻击的后果。
  • 主动检测和发现 可使用 XSS 攻击字符串和自动扫描工具寻找潜在的 XSS 漏洞。