首页 > 电脑常识 > 运维

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

admin 运维 2021-05-25 09:24:51
后台-系统设置-扩展变量-手机广告位-内容正文底部

XSS

Cross-Site Scripting (跨站脚本攻击)简称XSS,是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本,使其在用户的浏览器上运行。利用这些恶意脚本,攻击者可获取用户的敏感信息如Cookie、SessionID等,进而危害数据安全。

1.XSS的本质是:恶意代码未经过滤,与网站正常的代码混在一起;浏览器无法分辨哪些脚本是可信的,导致恶意脚本执行。

2.由于直接在用户的终端执行,恶意代码能够直接获取用户的信息,或者利用这些信息冒充用户向网站发起攻击者定义的请求。

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

XSS注入方式

  •  HTML 中内嵌的文本中,恶意内容以 script 标签形成注入。
  • 在内联的 JavaScript 中,拼接的数据突破了原本的限制(字符串,变量,方法名等)。
  • 在标签属性中,恶意内容包含引号,从而突破属性值的限制,注入其他属性或者标签。
  • 在标签的 hrefsrc 等属性中,包含 javascript: 等可执行代码。
  • 在 onloadonerroronclick 等事件中,注入不受控制代码。
  •  style 属性和标签中,包含类似 background-image:url("javascript:..."); 的代码(新版本浏览器已经可以防范)。
  • 在 style 属性和标签中,包含类似 expression(...) 的 CSS 表达式代码(新版本浏览器已经可以防范)。

总之,如果开发者没有将用户输入的文本进行合适的过滤,就贸然插入到 HTML 中,这很容易造成注入漏洞。攻击者可以利用漏洞,构造出恶意的代码指令,进而利用恶意代码危害数据安全。

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攻击类型存储位置插入点存储型XSS后端数据库HTML反射型XSSURLHTMLDOMXSS后端数据库/前端存储/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 漏洞,例如 Arachni、Mozilla HTTP Observatory、w3af 等

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攻击图1

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

 

xss攻击图2

为什么会酱紫呢?

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

可能有同学会不屑一顾:

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

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

 

xss攻击图3

执行代码:

 

xss攻击图4

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

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

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

 

xss攻击图5

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

 

xss攻击图6

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

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

二、防范

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

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

大家要注意两头的防范:

1)输入。

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

2)输出。

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


 

文章来源:https://blog.csdn.net/qq_32766999/article/details/117161229

后台-系统设置-扩展变量-手机广告位-内容正文底部
版权声明

本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。
本文地址:https://www.jcdi.cn/fwq1/30721.html

留言与评论(共有 0 条评论)
   
验证码:
后台-系统设置-扩展变量-手机广告位-评论底部广告位

教程弟

https://www.jcdi.cn/

统计代码 | 京ICP1234567-2号

Powered By 教程弟 教程弟

使用手机软件扫描微信二维码