前端常见的安全问题及防范措施

七里香777

已于 2022-10-28 22:20:00 修改

阅读量465

点赞数

分类专栏：笔记文章标签：安全前端网络

于 2022-10-27 22:42:57 首次发布

本文链接：https://blog.csdn.net/weixin_44286392/article/details/127555289

版权

笔记专栏收录该内容

45 篇文章 0 订阅

订阅专栏

跨站脚本攻击（XSS）

XSS是一种代码注入攻击，攻击者通过在网站注入恶意脚本，使之在用户的浏览器上运行，从而盗取用户的信息，比如cookie，localstorage等。

造成XSS的原因：网站没有对恶意代码进行过滤，与正常的代码混合在一起，浏览器没办法分辨哪些脚本是可信的，从而导致恶意代码的执行。

有以下三种攻击类型：

存储型

攻击者将恶意脚本长期保存在服务端数据库中，用户一旦访问相关页面数据，恶意脚本就会被执行。常见于搜索、微博、社区贴吧评论等。

攻击步骤：

攻击者将恶意代码提交到⽬标⽹站的数据库中；
⽤户打开⽬标⽹站时，⽹站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器；
⽤户浏览器接收到响应后解析执⾏，混在其中的恶意代码也被执⾏；
恶意代码窃取⽤户数据并发送到攻击者的⽹站，或者冒充⽤户的⾏为，调⽤⽬标⽹站接⼝执⾏攻击者指定的操作。

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

反射型

恶意脚本属于用户发送给网站请求中的一部分，随后网站又将这部分返回给用户，恶意脚本在页面中被执行。一般发生在前后端一体的应用中，服务端逻辑会改变最终的网页代码。

攻击步骤：

攻击者构造出特殊的 URL，其中包含恶意代码；
⽤户打开带有恶意代码的 URL 时，⽹站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器；
⽤户浏览器接收到响应后解析执⾏，混在其中的恶意代码也被执⾏；
恶意代码窃取⽤户数据并发送到攻击者的⽹站，或者冒充⽤户的⾏为，调⽤⽬标⽹站接⼝执⾏攻击者指定的操作。

反射型 XSS 漏洞常⻅于通过 URL 传递参数的功能，如⽹站搜索、跳转等。由于需要⽤户主动打开恶意的 URL 才能⽣效，攻击者往往会结合多种⼿段诱导⽤户点击。

反射型攻击与存储型攻击的区别：存储型 XSS 的恶意代码存在数据库⾥，反射型 XSS 的恶意代码存在 URL ⾥。

DOM型

DOM型攻击指的是通过修改页面的DOM节点形成的XSS。目前更流行前后端分离的项目，反射型 XSS 无用武之地。但基于DOM的XSS攻击不需要经过服务器，因为网页本身的 JavaScript 也是可以改变 HTML 的，攻击者正是利用这一点来实现插入恶意脚本。

攻击步骤：

攻击者构造出特殊的 URL，其中包含恶意代码；
⽤户打开带有恶意代码的 URL；
⽤户浏览器接收到响应后解析执⾏，前端 JavaScript 取出 URL 中的恶意代码并执⾏；
恶意代码窃取⽤户数据并发送到攻击者的⽹站，或者冒充⽤户的⾏为，调⽤⽬标⽹站接⼝执⾏攻击者指定的操作。

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

防范措施

输入过滤（会引起很大的不确定性和乱码问题，不推荐使用）
预防存储型和反射型攻击：改成纯前端渲染，把代码和数据分隔开；对HTML做充分转义；
预防DOM型攻击：对于 DOM 型的攻击，主要是前端脚本的不可靠而造成的，对于数据获取渲染和字符串拼接的时候应该对可能出现的恶意代码情况进行判断。
内容安全策略（CSP，Content Security Policy）：CSP 的本质是建立一个白名单，告诉浏览器哪些外部资源可以加载和执行，从而防止恶意代码的注入攻击。（我们只需要配置规则，如何拦截由浏览器自己来实现。）
两种方式开启CSP：①设置 HTTP 首部中的 Content-Security-Policy；②设置meta标签
设置cookie的HttpOnly属性，使得脚本无法获取cookie；
使用验证码，避免脚本伪装成用户执行一些操作。

跨站请求伪造（CSRF）

攻击者诱导用户进入一个第三方网站，然后该网站向被攻击网站发送跨站请求。如果用户在被攻击网站中保存了登录状态，那么攻击者就可以利用这个登录状态，绕过后台的用户验证，冒充用户向服务器执行一些操作。

本质：利用 cookie 会在同源请求中携带发送给服务器的特点，以此来冒充用户。

攻击过程：

用户登录A网站，并且保留了登录凭证（Cookie）
攻击者引诱该用户访问B网站
B网站向A网站发送了一个请求，浏览器请求头中会默认携带 A 网站的 Cookie
A 网站服务器收到请求后，经过验证发现用户是登录了的，所以会处理请求

有以下三种攻击类型：

GET型

比如在网站中的一个 img 标签里构建一个请求，当用户打开这个网站的时候就会自动发起提交。

POST型

比如构建一个表单，然后隐藏它，当用户进入页面时，自动提交这个表单，相当于模拟用户完成了一次POST操作。

链接型

比如在 a 标签的 href 属性里构建一个请求，然后诱导用户去点击。链接类型的CSRF并不常见，比起其他两种用户打开页面就中招的情况，这种需要用户点击链接才会触发。这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击。

特点

攻击一般在第三方网站发起
攻击者不是直接窃取数据，而是冒充受害者提交一些操作，整个过程攻击者并不能获取到受害者的登录凭证，只能是“冒充”
跨站请求可用各种方式，比如图片URL，超链接，表单提交等

防范措施

同源检测： CSRF大多来自第三方网站，那我们可以直接禁止第三方域名，或者不受信任的域名对我们发起请求；
CSRF Token： 浏览器向服务器发请求时，服务器会生成一个CSRF Token，当浏览器再次发请求时，就需要携带这个CSRF Token，服务器验证 CSRF Token 是否一致；而从第三方网站发出的请求是无法获取用户页面中的 CSRF Token 值的。
对Cookie进行双重验证： 服务器在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串，然后当用户再次向服务器发送请求的时候，从 cookie 中取出这个字符串，添加到 URL 参数中，然后服务器通过对 cookie 中的数据和参数中的数据进行比较，来进行验证。使用这种方式是利用了攻击者只能利用 cookie，但是不能访问获取 cookie 的特点。并且这种方法比 CSRF Token 的方法更加方便，并且不涉及到分布式访问的问题。这种方法的缺点是如果网站存在 XSS 漏洞的，那么这种方式会失效。同时这种方式不能做到子域名的隔离。
给Cookie设置合适的SameSite： 当从 A 网站登录后，会从响应头中返回服务器设置的 Cookie 信息，而如果 Cookie 携带了 SameSite=strict 则表示完全禁用第三方站点请求头携带 Cookie，比如当从 B 网站请求 A 网站接口的时候，浏览器的请求头将不会携带该 Cookie。