欢迎光临散文网 会员登陆 & 注册

前端面试八股文之安全性问题

2021-06-07 15:41 作者:坏蛋Dan丶  | 我要投稿

这题面试时也几乎必问


1. XSS（Cross-Site Scripting）

中文翻译过来是“跨站脚本攻击”，由于缩写和CSS一样，因此使用XSS区分。

这种攻击是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。

理论上所有可输入的地方都存在XSS攻击风险。

这么说应该有些不好理解，那么说一个实例：

当你在实现评论功能时，你在拿到评论内容后使用innerHTML将它拼接到内容区并渲染，那么就有可能遭到XSS攻击：用户输入的如果是一段标签字符串：<h1>这是XSS攻击</h1>，那么在渲染时也会被渲染出来。这就是一个最简单的XSS攻击。

常见的XSS攻击有以下这些：

  • 在 HTML 中内嵌的文本中，恶意内容以 script 标签形成注入（刚刚的例子）。

  • 在内联的 JavaScript 中，拼接的数据突破了原本的限制（字符串，变量，方法名等），使用ajax获取后端的数据再使用eval转换拼接。

  • 在标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签（使用"将属性默认的"隔开然后再接入自己的代码）。

  • 在标签的 href、src 等属性中，包含 javascript: (伪协议)等可执行代码，当用户点击链接时便会触发XSS攻击。

  • 在 onload、onerror、onclick 等事件中，注入不受控制代码。

  • 在 style 属性和标签中，包含类似 expression(JS代码) 的 CSS 表达式代码（新版本浏览器已经可以防范）。

关于CSS的expression用法可以百度下。


XSS可分为以下三个类型：


1. 存储型

存储型 XSS 的攻击步骤：

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

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

  3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。

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

存储型 XSS(又被称为持久性XSS)攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。

它是最危险的一种跨站脚本，相比反射型XSS和DOM型XSS具有更高的隐蔽性，所以危害更大，因为它不需要用户手动触发。任何允许用户存储数据的web程序都可能存在存储型XSS漏洞，当攻击者提交一段XSS代码后，被服务器端接收并存储，当所有浏览者访问某个页面时都会被XSS。


2. 反射型


反射型 XSS 的攻击步骤：

  1. 攻击者构造出特殊的 URL，其中包含恶意代码。

  2. 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。

  3. 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。

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

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

反射型 XSS (也被称为非持久性XSS)漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。

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

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


3. DOM型

DOM 型 XSS 的攻击步骤：

  1. 攻击者构造出特殊的 URL，其中包含恶意代码。

  2. 用户打开带有恶意代码的 URL。

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

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

DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。

注意:
DOM通常代表在html、xhtml和xml中的对象，使用DOM可以允许程序和脚本动态的访问和更新文档的内容、结构和样式。它不需要服务器解析响应的直接参与，触发XSS靠的是浏览器端的DOM解析，所以防范DOM型XSS完全就是前端的责任,必须注意!!!。


说了这么多，那么该如何防范呢？

方法大致上可分为两种

  1. 针对注入的JS代码

  2. 针对任何可输入点

第一种方法需要分析xss攻击的目的，大部分都是拿用户数据，因此常见的是设置cookie的httpOnly为true，此时使用js无法获取cookie。

第二种方法最为常见，主要有以下这些方法：

① 对任何可以输入的地方都进行过滤操作（前后端均需要）

② 对特殊符号进行转义，比如：

③ 黑白名单过滤，白名单是只获取dom本身就有的属性，黑名单相反，过滤掉不需要的标签。

④ 针对存储型XSS攻击的服务器传回的html拼接问题

  • 可以使用纯前端（前后端分离），比如使用vue，极大部分情况下是不会使用到v-html指令的。并且vue在生成DOM的时候是会判断节点类型并通知浏览器要如何渲染的，比如tag = text的渲染成TextNode、tag = div渲染成Node，而非浏览器自己判断是什么节点。

  • 对服务器传回的数据进行转义等操作。

⑤ 针对DOM型XSS攻击（前端）

需要特别注意一些会将字符串等转换为别的并执行的事件或方法，比如：eval、innerHTML、setTimeout、内联的onload、onclick等。


⑥ 设置CSP安全策略

除了针对数据源的严格过滤以外，CSP安全策略的限制也是主要的XSS防范手段之一，通过在页面中设置允许加载的资源的来源，来严格限制页面可加载的脚本以及图片等资源，防止外部的脚本攻击后注入其他脚本以及内容。

CSP，内容安全策略，是一种基于内容的声明式网络应用程序机制，对缓解内容注入漏洞的危害非常有效。通过一系列指令告诉客户端（如浏览器）被保护资源（如页面）内只允许加载和执行指令集中限定的内容，类似白名单机制，不满足限定条件的资源和内容将被客户端阻断或不被执行。可以通过两种方式设置CSP，一种是meta标签，一种是HTTP响应头Content-Security-Policy

这个可以百度下，我没把握住。。

⑦ 设置响应头，由于兼容性问题，这里不详细说（这个我也没把握住）


2. CSRF（Cross-site request forgery）

中文翻译过来就是跨站请求伪造，是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。如:攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。


大佬的图：

hyddd大佬的解释图

链接：https://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html


从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

  • 1.登录受信任网站A，并在本地生成Cookie。

  • 2.在不登出A的情况下，访问危险网站B。

看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：

  • 1.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。

  • 2.你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）

  • 3.上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。

CSRF的特点

  • 攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。

  • 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。

  • 整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。

  • 跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。

CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。


那么该如何防范呢？


1.服务端进行CSRF防御

　　服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。

　　(1).Cookie Hashing(所有表单都包含同一个伪随机值)：

　　这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了:>

这个方法个人觉得已经可以杜绝99%的CSRF攻击了，那还有1%呢....由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，这就另外的1%。一般的攻击者看到有需要算Hash值，基本都会放弃了，某些除外，所以如果需要100%的杜绝，这个不是最好的方法。
　　(2).验证码

　　这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，厄....这个方案可以完全解决CSRF，但个人觉得在易用性方面似乎不是太好，还有听闻是验证码图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。

　　(3).One-Time Tokens(不同的表单包含一个不同的伪随机值)

　　在实现One-Time Tokens时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。





整理自：

https://juejin.cn/post/6844903781704925191

https://segmentfault.com/a/1190000022678120

https://blog.csdn.net/weixin_34034261/article/details/85690647


标签：

前端面试八股文之安全性问题的评论 (共 条)

分享到微博请遵守国家法律