详解前端安全(XSS&CSRF),看了这篇,面试再也不怕不会说安全相关的了

XSS

Cross-Site Scripting (跨站脚本攻击)简称XSS,是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本,使其在用户的浏览器上运行。利用这些恶意脚本,攻击者可获取用户的敏感信息,或者利用这些信息冒充用户向网站发起攻击者定义的请求。

3.在部分情况下,由于输入的限制,注入的恶意脚本比较短。但可以通过引入外部的脚本,并由浏览器执行,来完成比较复杂的攻击策略。

XSS注入方式

  •  HTML 中内嵌的文本中,恶意内容以 script 标签形成注入。
  • 在内联的 JavaScript 中,拼接的数据突破了原本的限制(字符串,变量,方法名等)。
  • 在标签属性中,恶意内容包含引号,从而突破属性值的限制,注入其他属性或者标签。
  • 在标签的 hrefsrc 等属性中,包含 javascript: 等可执行代码。
  • 在 onloadonerroronclick 等事件中,注入不受控制代码。
  •  style 属性和标签中,包含类似 b漏洞,构造出恶意的代码指令,进而利用恶意代码危害数据安全。

    2、XSS攻击的分类

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

    (1)存储型XSS

    存储型 XSS 的攻击步骤:

    1. 攻击者将恶意代码提交到目标网站的数据库中。
    2. 用户打开目标网站时,网站服务端将恶意代码从数据库取出,拼接在 HTML 中返回给浏览器。
    3. 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行。
    4. 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。

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

    (2)反射型XSS

    反射型 XSS 的攻击步骤:

    1. 攻击者构造出特殊的 URL,其中包含恶意代码。
    2. 用户打开带有恶意代码的 URL 时,网站服务端将恶意代码从 URL 中取出,拼接在 HTML 中返回给浏览器。
    3. 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行。
    4. 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。

    反射型 XSS 跟存储型 XSS 的区别是:存储型 XSS 的恶意代码存在数据库里,反射型 XSS 的恶意代码存在 URL 里。

    反射型 XSS 漏洞常见于通过 URL 传递参数的功能,如网站搜索、跳转等。

    由于需要用户主动打开恶意的 URL 才能生效,攻击者往往会结合多种手段诱导用户点击。

    POST 的内容也可以触发反射型 XSS,只不过其触发条件比较苛刻(需要构造表单提交页面,并引导用户点击),所以非常少见。

    (3)DOMXSS

    DOM 型 XSS 的攻击步骤:

    1. 攻击者构造出特殊的 URL,其中包含恶意代码。
    2. 用户打开带有恶意代码的 URL
    3. 用户浏览器接收到响应后解析执行,前端 JavaScript 取出 URL 中的恶意代码并执行。
    4. 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。

    DOM 型 XSS 跟前两种 XSS 的区别:DOM 型 XSS 攻击中,取出和执行恶意代码由浏览器端完成,不需要服务器解析响应的直接参与,属于前端 JavaScript 自身的安全漏洞

    对比表格

    XSS攻击类型 存储位置 插入点
    存储型XSS 后端数据库 HTML
    反射型XSS URL HTML
    DOMXSS 后端数据库/前端存储/URL 前端JavaScript

    XSS攻击的防御措施

    (1)输入过滤

    只要有输入数据的地方,就存在XSS攻击,XSS攻击就有两大因素:

    • 攻击者提交恶意代码
    • 浏览器执行恶意代码

    所以,防御措施主要从这两个方面下手:

    针对用户输入过程

    在用户输入过程中,前端过滤输入的恶意代码,然后再提交给后端,这是不可行的,攻击者完全可以绕过前端过滤,直接构造请求提交恶意代码。

    对于明确的输入类型,例如数字、URL、电话号码、邮件地址等等内容,进行输入过滤是必要的。

    所以不仅需要前端对输入的格式进行格式检查,然后后端做相关的过滤检查。

    针对浏览器执行恶意代码

    输入过滤不是万全之策,那就要防止浏览器执行恶意代码,这个分为两步进行:

    • 防止HTML中出现注入
    • 防止JavaScript执行时,执行恶意代码

    (2)预防存储型和反射型XSS攻击

    存储型和反射型 XSS 都是在服务端取出恶意代码后,插入到响应 HTML 里的,攻击者刻意编写的“数据”被内嵌到“代码”中,被浏览器所执行。

    预防这两种漏洞,有两种常见做法:

    • 纯前端渲染,代码和数据分离
    • 转义 HTML

    1)纯前端渲染

    纯前端渲染的过程:

    1. 浏览器先加载一个静态 HTML,此 HTML 中不包含任何跟业务相关的数据
    2. 然后浏览器执行 HTML 中的 JavaScript
    3. JavaScript 通过 Ajax 加载业务数据,调用 DOM API 更新到页面上

    在纯前端渲染中,会明确的告诉浏览器:下面要设置的内容是文本(.innerText),还是属性(.setAttribute),还是样式(.style)等等。浏览器不会被轻易的被欺骗,执行预期外的代码了。

    但纯前端渲染还需注意避免 DOM 型 XSS 漏洞(例如 onload 事件和 href 中的 javascript:xxx 等,请参考下文”预防 DOM 型 XSS 攻击“部分)。

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

    2)转义HTML

    如果拼接 HTML 是必要的,就需要采用合适的转义库,对 HTML 模板各处插入点进行充分的转义。

    常用的模板引擎,如 doT.jsejsFreeMarker 等,对于 HTML 转义通常只有一个规则,就是把 & < > " ' / 这几个字符转义掉,确实能起到一定的 XSS 防护作用,但并不完善:

    |XSS 安全漏洞|简单转义是否有防护作用| |-|-| |HTML 标签文字内容|有| |HTML 属性值|有| |CSS 内联样式|无| |内联 JavaScript|无| |内联 JSON|无| |跳转链接|无|

    所以要完善 XSS 防护措施,我们要使用更完善更细致的转义策略。

    (3)预防DOMXSS攻击

    DOM  XSS 攻击,实际上就是网站前端 JavaScript 代码本身不够严谨,把不可信的数据当作代码执行了。

    在使用 .innerHTML.outerHTMLdocument.write() 时要特别小心,不要把不可信的数据作为 HTML 插到页面上,而应尽量使用 .textContent.setAttribute() 等。

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

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

    <!-- 内联事件监听器中包含恶意代码 --> ![](https://awps-assets.meituan.net/mit-x/blog-images-bundle-2018b/3e724ce0.data:image/png,)  <!-- 链接内包含恶意代码 --> <a href="UNTRUSTED">1</a>
    <script> // setTimeout()/setInterval() 中调用恶意代码 setTimeout("UNTRUSTED") setInterval("UNTRUSTED")  // location 调用恶意代码 location.href = 'UNTRUSTED'  // eval() 中调用恶意代码 eval("UNTRUSTED") </script>

    (4)其他防御措施

    虽然在渲染页面和执行 JavaScript 时,通过谨慎的转义可以防止 XSS 的发生,但完全依靠开发的谨慎仍然是不够的。以下介绍一些通用的方案,可以降低 XSS 带来的风险和后果。

    1)Content Security Policy

    严格的 CSP 在 XSS 的防范中可以起到以下的作用:

    • 禁止加载外域代码,防止复杂的攻击逻辑。
    • 禁止外域提交,网站被攻击后,用户的数据不会泄露到外域。
    • 禁止内联脚本执行(规则较严格,目前发现 GitHub 使用)。
    • 禁止未授权的脚本执行(新特性,Google Map 移动版在使用)。
    • 合理使用上报可以及时发现 XSS,利于尽快修复问题。

    2)输入内容长度控制

    对于不受信任的输入,都应该限定一个合理的长度。虽然无法完全防止 XSS 发生,但可以增加 XSS 攻击的难度。

    3)其他

    • HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie,攻击者完成 XSS 注入后也无法窃取此 Cookie
    • 验证码:防止脚本冒充用户提交危险操作
    • 白名单: 对于显示富文本来说,不能通过上面的办法来转义所有字符,因为这样会把需要的格式也过滤掉。这种情况通常采用白名单过滤的办法,当然也可以通过黑名单过滤,但是考虑到需要过滤的标签和标签属性实在太多,更加推荐使用白名单的方式

     

    XSS攻击检测

    两种方法:

    (1)使用通用 XSS 攻击字符串手动检测 XSS 漏洞

    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()innerHTMLdocument.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

    (2)使用扫描工具自动检测 XSS 漏洞

    常见自动扫描工具寻找 XSS 漏洞,例如 ArachniMozilla HTTP Observatoryw3af 等

    5、XSS攻击简单总结

    • 防御存储型和反射型 XSS 是后端的责任。而 DOM 型 XSS 是前端 的责任。防御XSS 是需要后端和前端共同参与的系统工程
    • 转义应该在输出 HTML 时进行,而不是在提交用户输入时
    • 不同的上下文,如 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等,所需要的转义规则不一致。 业务 需要选取合适的转义库,并针对不同的上下文调用不同的转义规则
    • 不仅需要在全部需要转义的位置,对数据进行对应的转义。而且要防止多余和错误的转义,避免正常的用户输入出现乱码
    • 总结以下原则减少漏洞的产生:

      • 利用模板引擎 :开启模板引擎自带的 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 漏洞

     

    在开始本文之前,我们先提出一个问题,请判断以下两个说法是否正确:

    1.XSS 防范是后端 RD(研发人员)的责任,后端 RD 应该在所有用户提交数据的接口,对敏感字符进行转义,才能进行下一步操作。

    2.所有要插入到页面上的数据,都要通过一个敏感字符过滤函数的转义,过滤掉通用的敏感字符后,就可以插入到页面中。

    如果你还不能确定答案,那么可以带着这些问题向下看,我们将逐步拆解问题。

    XSS 漏洞的发生和修复

    XSS 攻击是页面被注入了恶意的代码,为了更形象的介绍,我们用发生在小明同学身边的事例来进行说明。

    一个案例

    某天,公司需要一个搜索页面,根据 URL 参数决定关键词的内容。小明很快把页面写好并且上线。代码如下:

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

    然而,在上线后不久,小明就接到了安全组发来的一个神秘链接:

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

    小明带着一种不祥的预感点开了这个链接 [请勿模仿,确认安全的链接才能点开] 。果然,页面中弹出了写着"XSS"的对话框。

    可恶,中招了!小明眉头一皱,发现了其中的奥秘:

    当浏览器请求 http://xxx/search?keyword="><script>alert('XSS');</script> 时,服务端会解析出请求参数 keyword,得到 "><script>alert('XSS');</script>,拼接到 HTML 中返回给浏览器。形成了如下的 HTML:

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

    浏览器无法分辨出 <script>alert('XSS');</script> 是恶意代码,因而将其执行。

    这里不仅仅 div 的内容被注入了,而且 input 的 value 属性也被注入, alert 会弹出两次。

    面对这种情况,我们应该如何进行防范呢?

    其实,这只是浏览器把用户的输入当成了脚本进行了执行。那么只要告诉浏览器这段内容是文本就可以了。

    聪明的小明很快找到解决方法,把这个漏洞修复:

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

    escapeHTML() 按照如下规则进行转义:

    |字符|转义后的字符|
    |-|-|
    |&|&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 >  

    恶意代码都被转义,不再被浏览器执行,而且搜索词能够完美的在页面显示出来。

    通过这个事件,小明学习到了如下知识:

    通常页面中包含的用户输入内容都在固定的容器或者属性内,以文本的形式展示。

    攻击者利用这些页面的用户输入片段,拼接特殊格式的字符串,突破原有位置的限制,形成了代码片段。

    攻击者通过在目标网站上注入脚本,使之在用户的浏览器上运行,从而引发潜在风险。

    通过 HTML 转义,可以防止 XSS 攻击。 [事情当然没有这么简单啦!请继续往下看]

    大家想必都听过xss攻击,那么这个xss到底是如何攻击、我们又应该如何防范的呢?

    xss攻击主要是针对表单的input文本框发起的,比如有这样一个文本框:

    详解前端安全(XSS&CSRF),看了这篇,面试再也不怕不会说安全相关的了

     

    xss攻击图1

    在说明一栏填入一段js代码,如果前端不进行过滤直接提交到后端(比如php),而php端也没有进行过滤直接入库,那么在下一个展示页面,就会发生这样的情况:

    详解前端安全(XSS&CSRF),看了这篇,面试再也不怕不会说安全相关的了

     

    xss攻击图2

    为什么会酱紫呢?

    因为我们在说明这一栏的input,会将后端返回的内容直接追加进去,导致js代码执行。

    可能有同学会不屑一顾:

    你弹个框又能怎样呢?大不了我关了就是了呗!

    那假设是cookie这样的敏感信息呢?我们不妨来做个试验:

    详解前端安全(XSS&CSRF),看了这篇,面试再也不怕不会说安全相关的了

     

    xss攻击图3

    执行代码:

    详解前端安全(XSS&CSRF),看了这篇,面试再也不怕不会说安全相关的了

     

    xss攻击图4

    这样就可以获取到一个用户的cookie了。那再进一步,如果把所有的cookie都想办法弄出来,然后存到自己的库里面的话。。。

    想想挺带劲的哈,咱们不妨动手搞一下。

    我们可以直接注入这样一段js脚本:

    详解前端安全(XSS&CSRF),看了这篇,面试再也不怕不会说安全相关的了

     

    xss攻击图5

    这段脚本呢,我就直接这么搞:

    详解前端安全(XSS&CSRF),看了这篇,面试再也不怕不会说安全相关的了

     

    xss攻击图6

    您别误会,我的本意不是创建一个图片,而是利用图片的src跨域属性,直接把cookie的值,传送到我的php后端代码里面,接下来就可以入库了哈哈~~

    by the way,将图片的宽高设置为0,用户是不会看到这个图片的,因此这段js一旦注入生效,所有的用户都会触发这个js,从而将自己的cookie源源不断的输送到我的php代码中。

    二、防范

    好了,原理有了一定的了解之后,接下来就是如何防范了。

    问题的源头在于js代码的注入,我们可以想个办法,不让js生效不就行了?

    大家要注意两头的防范:

    1)输入。

    在提交表单时,前端最好将文本内容转为html实体编码,也就是过滤掉<script>、<a>、这样的内容,然后再提交到后台去。当然保险起见,后台也要再做一遍html实体转码,然后再入库。

    2)输出。

    在显示文本内容时,最好也要做一次html实体编码转换后再显示,防止<script>标签生效