XSS攻击,这次一定会!

完整阅读本文大约需要5分钟。
开启本文前,先提出两个我在面试时被问到的题:
  1. 为了预防XSS攻击,我们会对用户的输入内容进行过滤,转义的时机应该是a.输入时前端处理 b.落库时后端处理 c.拼接HTML时 ?
  2. XSS攻击的预防,需要前端还是后端去做?
什么是XSS攻击 XSS攻击是Cross-Site Scripting的缩写,直白来说,就是页面被注入了恶意的代码——用户输入的内容跳出文本的限制,成了可执行的代码。
XSS攻击的分类 根据入侵代码的来源,通常将XSS攻击分成三类:
存储型 XSS 攻击
特点:恶意代码已经落库,被拼接到HTML中返回。
  1. 攻击者通过论坛评论区提交恶意代码到数据库;
  2. 其他用户打开论坛,服务端把恶意代码取出来,拼接在HTML中返回;
  3. 恶意代码在用户的浏览器端运行;
除了论坛,这类攻击还常见于用户私信发送。
比如用户提交评论到网站的数据库中。
评论内容:

被后端拼接后:
评论内容:

其他用户访问到这个页面,会跳出写着”XSS”的对话框
反射型 XSS 攻击
特点:恶意代码被拼接到URL上,被拼接到HTML中返回。
  1. 攻击者拼接出包含恶意代码的受害网站URL,诱导用户点击;
  2. 用户点击该URL,目标网站的服务器取出恶意代码,拼接到HTML返回;
  3. 恶意代码在其他用户的浏览器端运行;
这类攻击需要用户主动点击受害网站的URL,攻击者会通过通过QQ群或者邮件等方式诱导点击。
比如一个恶意URL可以长这样:http://xxx/search?keyword="
你好

被后端拼接后:
你好

点击后,页面会跳出写着”XSS”的对话框。
DOM 型 XSS 攻击
特点:恶意代码被拼接到URL上,被前端JavaScript代码执行。
  1. 攻击者拼接出包含恶意代码的受害网站URL,诱导用户点击;
  2. 用户点击该URL;
  3. 前端 JavaScript 取出 URL 中的恶意代码,恶意代码在用户的浏览器端运行;
DOM型和反射型的区别在于,DOM 型 XSS 攻击中,取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞。而其他两种 XSS 都属于服务端的安全漏洞。
上述三种XSS攻击的目的都一致:恶意代码在浏览器端运行后,窃取用户的本地存储数据:通过document.cookie获取用户的身份凭证,然后通过网络请求将数据发送给恶意服务器。
接下来就可以进行下一步:冒充用户去对受害网站发起请求完成指定操作,比如转账给攻击者的账户。
怎么预防XSS攻击 XSS攻击的实现需要有两个必要条件:
  1. 攻击者输入恶意代码;
  2. 浏览器执行恶意代码;
【XSS攻击,这次一定会!】先看第一点,是否可以避免攻击者输入恶意代码,先进行HTML转义呢?
如果我们在前端对输入的内容进行转义过滤,那么攻击者只要模拟发起请求,便绕了过前端,一样可以攻击成功。
如果落库时在后端进行转义过滤,我们会发现:
  1. 如果内容要提供给多端,只会在前端正常展示,在iOS/安卓上会变成乱码;
  2. 返回给前端的方式不一样,也不一定能正常展示,比如,正常的用户输入了 5 < 7 这个内容,在写入数据库前,被转义,变成了 5 < 7;
    1. 作为 HTML 拼接页面时,可以正常显示;
    2. 通过 Ajax 返回,然后赋值给 JavaScript 的变量时,前端得到的字符串就是转义后的字符。这个内容不能直接用于 Vue 等模板的展示,会和iOS/安卓一样,变成乱码 5 < 7
所以我们需要通过“防止浏览器执行恶意代码”来防范 XSS 攻击。
纯前端渲染 纯前端渲染是指,浏览器首先加载一个空白的HTML,然后执行该HTML引入的JS文件,JS通过AJAX获取业务数据,调用DOM API,更新到页面上。
因为是在前端,我们可以清楚地告诉浏览器:这是文本.innerText而不是HTML.innerHTML。这样浏览器就不会执行预期意外的代码。
纯前端渲染可以避免存储型和反射型的攻击,但没法避免DOM型,攻击者可以通过onload事件、href中嵌入javascript:...进行攻击。
转义HTML 对于需要考虑SEO的SSR项目,不得不在服务端拼接HTML文件。那么必须使用HTML转义库,基本规则是将& < > " ' /几个字符转义掉。
关注高危API 在前端渲染时,要谨慎使用.innerHTML.outerHTMLdocument.write()等直接插入HTML的API,其来源必须是可信的。
此外locationonclickonerroronloadonmouseover、还有 标签的 href 都可以把字符串当作代码执行。
其他通用策略
  1. 使用CSP:CSP即Content Security Policy内容安全策略,限制加载其他域下的资源,这样即使黑客插入了一个 Javascript文件,它也是无法被加载的;
  2. 开启HTTP only:禁止 JavaScript 读取某些敏感 Cookie,攻击者完成 XSS 注入后也无法窃取此 Cookie;
  3. 验证码:防止脚本冒充用户提交危险操作;
结语 读完本文,回到开头两个问题,我们知道了:
  1. 对用户输入内容转义,其时机必须在拼接HTML时,如果在落库前处理,会导致iOS/安卓乱码;
  2. XSS攻击的预防,需要RD一起完成,存储型和反射型攻击是后端的责任,DOM型是前端的责任;
XSS攻击,这次一定会!
文章图片

    推荐阅读