同源策略
什么是同源:如果两个地址是==相同的协议,相同的域名和端口==,那么就是同源的 DOM 层面。同源策略限制了来自不同源的 JavaScript 脚本对当前 DOM 对象读和写的操作。 数据层面。同源策略限制了不同源的站点读取当前站点的 Cookie、IndexDB、LocalStorage 等数据。 网络层面。同源策略限制了通过 XMLHttpRequest 等方式将站点的数据发送给不同源的站点。
XSS
XSS 全称是 Cross Site Scripting,“跨站脚本”。XSS 攻击是指黑客往 HTML 文件中或者 DOM 中注入恶意脚本,从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段
表现是什么?
- 可以窃取 Cookie 信息,==document.cookie==访问
- 可以监听用户行为 ==addEventListener==
- 可以通过修改 DOM 伪造假的登录窗口,用来欺骗用户输入用户名和密码等信息
- 还可以在页面内生成浮窗广告,这些广告会严重地影响用户体验等
存储型xss
graph LR
R[黑客] --> |注入| B
A[客户端-黑客] --> |提交| B(存储DB)
B --> C{用户请求}
C -->|返回| D[客户端]
D --> E[触发窃取Cookie]
反射型xss
Web 服务器不会存储反射型 XSS 攻击的恶意脚本,这是和存储型 XSS 攻击不同的地方。
graph LR
R[黑客] --> |携带恶意javascript| B[服务直接返回]
B --> C{客户端解析}
C --> D[客户端调用脚本行为]
D --> E[用户点击]
基于 DOM 的 XSS 攻击
基于 DOM 的 XSS 攻击是不牵涉到页面 Web 服务器的。具体来讲,黑客通过各种手段将恶意脚本注入用户的页面中,比如通过网络劫持在页面传输过程中修改 HTML 页面的内容,这种劫持类型很多,有通过 WiFi 路由器劫持的,有通过本地恶意软件来劫持的,它们的共同点是在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据
预防XSS
- 服务器对输入脚本进行过滤或转码
<script>alert(123)</script>
=> <sciprt>alert(123)</script>
- 充分利用 CSP
- CSP 的核心思想是让服务器决定浏览器能够加载哪些资源,让服务器决定浏览器是否能够执行内联 JavaScript 代码。
- 限制加载其他域下的资源文件,这样即使黑客插入了一个 JavaScript 文件,这个 JavaScript 文件也是无法被加载的;
- 禁止向第三方域提交数据,这样用户数据也不会外泄;
- 禁止执行内联脚本和未授权的脚本;
- 上报机制
- 使用 HttpOnly 属性
使用 HttpOnly 属性来保护我们 Cookie 的安全,使用 HttpOnly 标记的 Cookie 只能使用在 HTTP 请求过程中
CSRF 攻击
CSRF 英文全称是 Cross-site request forgery,所以又称为“跨站请求伪造”,是指黑客引诱用户打开黑客的网站,在黑客的网站中,利用用户的登录状态发起的跨站请求。简单来讲,CSRF 攻击就是==黑客利用了用户的登录状态==,并通过第三方的站点来做一些坏事。 ==利用服务器的漏洞和用户的登录状态来实施攻击==
手段
- 自动发起 Get 请求
<!DOCTYPE html>
<html>
<body>
<h1>黑客的站点:CSRF攻击演示</h1>
<img src="https://time.geekbang.org/sendcoin?user=hacker&number=100">
</body>
</html>
- 自动发起 POST 请求
<!DOCTYPE html>
<html>
<body>
<h1>黑客的站点:CSRF攻击演示</h1>
<form id='hacker-form' action="https://time.geekbang.org/sendcoin" method=POST>
<input type="hidden" name="user" value="hacker" />
<input type="hidden" name="number" value="100" />
</form>
<script> document.getElementById('hacker-form').submit(); </script>
</body>
</html>
- 引诱用户点击链接
<div>
<img width=150 src=http://images.xuejuzi.cn/1612/1_161230185104_1.jpg> </img> </div> <div>
<a href="https://time.geekbang.org/sendcoin?user=hacker&number=100" taget="_blank">
点击下载美女照片
</a>
</div>
防止 CSRF 攻击
发起攻击的必备条件
- 第一个,目标站点一定要有 CSRF 漏洞
- 第二个,用户要登录过目标站点,并且在浏览器上保持有该站点的登录状态;第三个,需要用户打开一个
- 第三方站点,可以是黑客的站点,也可以是一些论坛
预防手段
- 充分利用好 Cookie 的 SameSite 属性
- 从第三方站点发起的请求,那么需要浏览器禁止发送某些关键 Cookie 数据到服务器;
- 同一个站点发起的请求,那么就需要保证 Cookie 数据正常发送。
- SameSite 选项通常有 Strict、Lax 和 None 三个值
- Strict 最为严格。如果 SameSite 的值是 Strict,那么浏览器会完全禁止第三方 Cookie
- Lax 相对宽松一点。在跨站点的情况下,从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie。
- 如果使用 None 的话,在任何情况下都会发送 Cookie 数据
- 验证请求的来源站点: 在服务器端验证请求来源的站点
- 验证HTTP 请求头中的 Referer 和 Origin 属性
- 服务器的策略是优先判断 Origin,如果请求头中没有包含 Origin 属性,再根据实际情况判断是否使用 Referer 值
- CSRF Token
- 在浏览器向服务器发起请求时,服务器生成一个 CSRF Token
- 在浏览器端如果要发起转账的请求,那么需要带上页面中的 CSRF Token,然后服务器会验证该 Token 是否合法
HTTPS
graph TD
W[HTTP]
A[HTTP] --> B[TCP]
B --> C[IP]
C --> D[数据链路层]
Y[HTTPS]
F[HTTP] --> |加密| E[安全层SSL/TLS]
E --> |解密| F
E --> G[TCP]
G --> J[IP]
J --> K[数据链路层]
- 对发起 HTTP 请求的数据进行加密操作和对接收到 HTTP 的内容进行解密操作。
- 使用对称加密
graph LR
A[确认阶段-安全握手]
B[浏览器] --> |1.加密套件 & client-rendom| S[服务器]
S[服务器] --> |2.加密套件 & server-random| B[浏览器]
B[浏览器] --> |3.浏览器确认| S[服务器]
S[服务器] --> |4.服务器确认| B[浏览器]
C[通信阶段]
E[浏览器] --> |计算密钥| V[服务器]
E[浏览器] --> |传输| V[服务器]
V[服务器] --> |计算密钥| E[浏览器]
- 使用非对称加密
graph LR
A[确认阶段-安全握手]
B[浏览器] --> |1.加密套件| S[服务器]
S[服务器] --> |2.加密套件+公钥| B[浏览器]
B[浏览器] --> |3.浏览器确认| S[服务器]
S[服务器] --> |4.服务器确认| B[浏览器]
C[通信阶段]
E[浏览器] --> |传输数据+公钥| V[服务器]
V[服务器] --> |私钥解密验证返回数据| E[浏览器]
- 对称加密和非对称加密搭配使用 (混合加密)
- 首先浏览器向服务器发送对称加密套件列表、非对称加密套件列表和随机数 client-random;
- 服务器保存随机数 client-random,选择对称加密和非对称加密的套件,然后生成随机数 service-random,向浏览器发送选择的加密套件、service-random 和公钥;
- 浏览器保存公钥,并生成随机数 pre-master,然后利用公钥对 pre-master 加密,并向服务器发送加密后的数据;
- 最后服务器拿出自己的私钥,解密出 pre-master 数据,并返回确认消息。
- 添加数字证书
- 这个权威机构称为 CA(Certificate Authority),颁发的证书就称为数字证书(Digital Certificate)。
- 申请数字证书是不需要提供私钥的,要确保私钥永远只能由服务器掌握;
- 数字证书最核心的是 CA 使用它的私钥生成的数字签名;
- 内置 CA 对应的证书称为根证书,根证书是最权威的机构,它们自己为自己签名,我们把这称为自签名证书。