Web 安全

kelly0721

于 2021-01-17 01:05:48 发布

阅读量149

点赞数

分类专栏：前端性能优化

本文链接：https://blog.csdn.net/kelly0721/article/details/112468560

版权

前端性能优化专栏收录该内容

4 篇文章 0 订阅

订阅专栏

一、同源策略

如果两个 URL 的协议、域名和端口都相同，我们就称这两个 URL 同源。

来自不同源的 JavaScript 脚本对当前 DOM 对象不可读和写的操作。
不同源的站点无法读取当前站点的 Cookie、IndexDB、LocalStorage等数据。
限制了通过 XMLHttpRequest 等方式将站点的数据发送给不同源的站点。

解决同源策略的方法

跨文档消息机制: 可以通过 window.postMessage 的 JavaScript 接口来和不同源的 DOM 进行通信。
跨域资源共享（CORS）: 跨域资源在服务端设置允许跨域，就可以进行跨域访问控制，从而使跨域数据传输得以安全进行。
内容安全策略（CSP）: 主要以白名单的形式配置可信任的内容来源，在网页中，能够使白名单中的内容正常执行（包含 JS，CSS，Image 等等），而非白名单的内容无法正常执行。

二、XSS

XSS（Cross Site Script，跨站脚本攻击）是指攻击者在网站上注入恶意的客户端代码，通过恶意脚本对客户端网页进行篡改，从而在用户浏览网页时，对用户浏览器进行控制或者获取用户隐私数据的一种攻击方式。（xss攻击的目标为浏览器，通过写恶意脚本进行跨站篡改浏览器正常信息展示，窃取用户信息）

XSS攻击可以分为3类：反射型（非持久型）、存储型（持久型）、基于DOM。

反射型 XSS 攻击

反射型（Reflected XSS ）发出请求时，XSS代码出现在url中，作为输入提交到服务器端，服务器端解析后响应，XSS代码随响应内容一起传回给浏览器，最后浏览器解析执行XSS代码。这个过程像一次反射，所以叫反射型XSS。
在这里插入图片描述

存储型 XSS 攻击

存储型 Stored XSS和 Reflected XSS的差别就在于，具有攻击性的脚本被保存到了服务器端（数据库，内存，文件系统），存储型的XSS漏洞和反射型形成的原因是一样的，也在输入输出时造成的问题，不同的是存储型的XSS下可以将攻击者的脚本注入后台存储起来，结构更加持久的危害。

比如在input, textarea等所有可能输入文本信息的区域，输入<script src="http://恶意网站"></script>等，提交后信息会存在服务器中，当用户再次打开网站请求到相应的数据，打开页面，恶意脚本就会将用户的 Cookie 信息等数据上传到黑客服务器。

在这里插入图片描述

基于 DOM 的 XSS 攻击

DOM型（DOM-based or local XSS）即基于DOM或本地的 XSS 攻击：其实是一种特殊类型的反射型 XSS，它是基于 DOM文档对象模型的一种漏洞。可以通过 DOM来动态修改页面内容，从客户端获取 DOM中的数据并在本地执行。基于这个特性，就可以利用 JS脚本来实现 XSS漏洞的利用。

预防策略

使用 Httponly Cookie：将cookie等敏感信息设置为httponly，这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段，但是在js脚本中却不能访问这个cookie，这样就避免了XSS攻击利用JavaScript的document.cookie获取cookie。
输入过滤：对所有的输入做严格的校验，包括对 URL、查询关键字、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。(客户端和服务器都需要)
净化和过滤掉不必要的html标签，比如：<iframe>, <script>等 ; 净化和过滤掉不必要的Javascript的事件标签，比如：onclick, onfocus等
输出转义：转义单引号，双引号，尖括号等特殊字符，可以采用htmlencode编码或者过滤掉这些特殊字符
CSP，全称为 Content Security Policy，即内容安全策略。主要以白名单的形式配置可信任的内容来源，在网页中，能够使白名单中的内容正常执行（包含 JS，CSS，Image 等等），而非白名单的内容无法正常执行，从而减少跨站脚本攻击（XSS），当然，也能够减少运营商劫持的内容注入攻击。
配置方式：
```
//1、meta

<meta http-equiv="Content-Security-Policy" content="script-src 'self'">

//2、Http 头部

Content-Security-Policy:
script-src 'unsafe-inline' 'unsafe-eval' 'self' *.54php.cn *.yunetidc.com *.baidu.com *.cnzz.com *.duoshuo.com *.jiathis.com;report-uri /error/csp
```

三、CSRF

CSRF（Cross-site request forgery，跨站请求伪造），是一种网络攻击方式。也被称为：one click attack/session riding，缩写为：CSRF/XSRF。
简单来说，就是引诱用户打开黑客的网站，在黑客的网站中，利用用户的登录状态发起的跨站请求，包括伪造邮件，盗刷银行卡，银行转帐的行为等。

1. CSRF攻击攻击原理及过程

one登录受信任网站A，并在本地生成Cookie 。
one在不退出A的情况下，访问危险网站B。
危险网站B上有一个<img>标签：<img src=“http://www.examplebank.com/account=one&amount=1000&payfor=Badman” >
这个标签的src不指向一张图片，而是一个http请求，这个请求向银行要求将Alice的1000元转给Badman，由于one的浏览器上有cookie，这样浏览器发出的这个请求就能得到响应执行。这样one的钱就被偷了。

CSRF攻击主要是因为Web的隐式身份验证机制，Web的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该是不是来自于用于本人，所以在防范CSRF攻击时，我们需要防范的关键点是在请求中放入黑客不能伪造的信息。

2. 发起 CSRF 攻击的三个必要条件

目标站点一定要有 CSRF 漏洞；
用户要登录过目标站点，并且在浏览器上保持有该站点的登录状态；
需要用户打开一个第三方站点，如黑客的站点等。

3. 预防策略

Cookie 的 SameSite 属性。

Cookie 的SameSite 选项通常有 Strict、Lax 和 None 三个值

Strict，浏览器会完全禁止第三方 Cookie。
Lax ,在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie。但如果在第三方站点中使用 Post 方法，或者通过 img、iframe 等标签加载的 URL，这些场景都不会携带 Cookie。
None, 在任何情况下都会发送 Cookie 数据

验证请求的来源站点

在服务器端验证请求来源的站点，就是验证 HTTP 请求头中的 Origin和 Referer属性。
Referer 是 HTTP 请求头中的一个字段，记录了该 HTTP 请求的来源地址。
Origin 属性只包含了域名信息，并没有包含具体的 URL 路径。
这是 Origin 和 Referer 的一个主要区别。

服务器的策略是优先判断 Origin，如果请求头中没有包含 Origin 属性，再根据实际情况判断是否使用 Referer 值。

使用验证码

关键操作页面加上验证码，后台收到请求后通过判断验证码可以防御CSRF。但这种方法对用户不太友好。

在请求地址中添加 token 并验证

HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

在 HTTP 头中自定义属性并验证

通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个自定义的HTTP 头属性，并把 token 值放入其中。
这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。
但是这种方法的局限性非常大,一般不推荐使用

四、SQL注入

拼接 SQL 时未仔细过滤，黑客可提交畸形数据改变语义。比如查某个文章，提交了这样的数据 id=-1 or 1=1等。1=1 永远是true，导致where语句永远是ture.那么查询的结果相当于整张表的内容，攻击者就达到了目的。或者，通过屏幕上的报错提示推测 SQL 语句等。

预防策略

禁止目标网站利用动态拼接字符串的方式访问数据库
减少不必要的数据库抛出的错误信息
对数据库的操作赋予严格的权限控制
净化和过滤掉不必要的SQL保留字，比如：where, or, exec 等

五、点击劫持

出现场景

诱使用户点击看似无害的按钮（实则点击了透明 iframe 中的按钮）
监听鼠标移动事件，让危险按钮始终在鼠标下方
使用 HTML5 拖拽技术执行敏感操作（例如 deploy key

预防策略

服务端添加 X-Frame-Options 响应头,这个 HTTP 响应头是为了防御用 iframe 嵌套的点击劫持攻击。这样浏览器就会阻止嵌入网页的渲染。
JS 判断顶层视口的域名是不是和本页面的域名一致，不一致则不允许操作，top.location.hostname === self.location.hostname；
敏感操作使用更复杂的步骤（验证码、输入项目名称以删除）

六、window.opener 安全问题

window.opener 表示打开当前窗体页面的的父窗体的是谁。例如，在 A 页面中，通过一个带有 target="_blank" 的 a 标签打开了一个新的页面 B，那么在 B 页面里，window.opener 的值为 A 页面的 window 对象。

一般来说，打开同源(域名相同)的页面，不会有什么问题。但对于跨域的外部链接来说，存在一个被钓鱼的风险。比如你正在浏览购物网站，从当前网页打开了某个外部链接，在打开的外部页面，可以通过 window.opener.location 改写来源站点的地址。利用这一点，将来源站点改写到钓鱼站点页面上，例如跳转到伪造的高仿购物页面，当再回到购物页面的时候，是很难发现购物网站的地址已经被修改了的，这个时候你的账号就存在被钓鱼的可能了。