web安全安全问题用户身份被盗用、用户密码泄露、用户资料被盗取、网站数据库泄露主要包含：跨站脚本攻击XSS跨站请求伪造攻

安全问题

用户身份被盗用、用户密码泄露、用户资料被盗取、网站数据库泄露

主要包含：

跨站脚本攻击XSS

跨站请求伪造攻击CSRF

前端Cookies安全性

点击劫持攻击

传输过程安全问题

用户密码安全问题

SQL注入攻击

同源策略

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

浏览器默认两个相同的源之间是可以相互访问资源和操作 DOM 的。两个不同的源之间若想要相互访问资源或者操作 DOM，那么会有一套基础的安全策略的制约，我们把这称为同源策略。具体来讲，同源策略主要表现在 DOM、Web 数据和网络这三个层面。

DOM 层面：

同源策略限制了来自不同源的 JavaScript 脚本对当前 DOM 对象读和写的操作。

let pdom = opener.documentp
dom.body.style.display = "none"

该代码中，对象 opener 就是指向第一个页面的 window 对象，我们可以通过操作 opener 来控制第一个页面中的 DOM。

数据层面：

同源策略限制了不同源的站点读取当前站点的 Cookie、IndexDB、LocalStorage 等数据。由于同源策略，我们依然无法通过第二个页面的 opener 来访问第一个页面中的 Cookie、IndexDB 或者 LocalStorage 等内容。

网络层面：

同源策略限制了通过 XMLHttpRequest 等方式将站点的数据发送给不同源的站点。

安全和便利性的权衡：

同源策略会隔离不同源的 DOM、页面数据和网络通信，进而实现 Web 页面的安全性。

安全性和便利性是相互对立的，虽然同源策略保证了一定的安全性，但是也让web项目的开发和使用变得不够灵活，因此在安全性和灵活性之间也做出了一些权衡通过出让一些安全性去满足比如：

页面中可以嵌入第三方资源

**跨域资源共享和跨文档消息机制
**

跨域资源共享(CORS)可以允许XMLHttpRequest 和 Fetch进行跨域请求的

跨文档消息机制通过window.postMessage和不同源的 DOM 进行通信。

XSS(Cross Site Scripting)跨站脚本攻击

跨站脚本攻击是指恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入的Script代码会被执行，从而达到恶意攻击用户的目的。

XSS类型：

存储型XSS攻击、反射型XSS攻击、基于DOM的XSS攻击

存储型XSS攻击：

黑客利用站点漏洞将一段恶意 JavaScript 代码提交到网站的数据库中；
然后用户向网站请求包含了恶意 JavaScript 脚本的页面；
当用户浏览该页面的时候，恶意脚本就会将用户的 Cookie 信息等数据上传到服务器。

反射型XSS攻击：

反射型 XSS 攻击过程中，恶意 JavaScript 脚本属于用户发送给网站请求中的一部分，随后网站又把恶意 JavaScript 脚本返回给用户。当恶意 JavaScript 脚本在用户页面中被执行时，黑客就可以利用该脚本做一些恶意操作。
Web 服务器不会存储反射型 XSS 攻击的恶意脚本，这是和存储型 XSS 攻击不同的地方。

基于 DOM 的 XSS 攻击：

基于 DOM 的 XSS 攻击是不牵涉到页面 Web 服务器的。具体来讲，黑客通过各种手段将恶意脚本注入用户的页面中，比如通过网络劫持在页面传输过程中修改 HTML 页面的内容，这种劫持类型很多，有通过 WiFi 路由器劫持的，有通过本地恶意软件来劫持的，它们的共同点是在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据。

阻止XSS攻击方式：

1、服务器对输入脚本进行过滤和转码

2、利用 CSP：让服务器决定浏览器能够加载哪些资源，让服务器决定浏览器是否能够执行内联 JavaScript 代码

限制加载其他域下的资源文件，这样即使黑客插入了一个 JavaScript 文件，这个 JavaScript 文件也是无法被加载的；
禁止向第三方域提交数据，这样用户数据也不会外泄；
禁止执行内联脚本和未授权的脚本；
还提供了上报机制，这样可以帮助我们尽快发现有哪些 XSS 攻击，以便尽快修复问题。

3、使用 HttpOnly 属性

由于很多 XSS 攻击都是来盗用 Cookie 的，因此还可以通过使用 HttpOnly 属性来保护我们 Cookie 的安全。

通常服务器可以将某些 Cookie 设置为 HttpOnly 标志，HttpOnly 是服务器通过 HTTP 响应头来设置的

使用 HttpOnly 标记的 Cookie 只能使用在 HTTP 请求过程中，所以无法通过 JavaScript 来读取这段 Cookie

CSRF攻击--陌生链接不要随便点

CSRF 英文全称是 Cross-site request forgery，所以又称为“跨站请求伪造”，是指黑客引诱用户打开黑客的网站，在黑客的网站中，利用用户的登录状态发起的跨站请求。简单来讲，CSRF 攻击就是黑客利用了用户的登录状态，并通过第三方的站点来做一些坏事。

和 XSS 不同的是，CSRF 攻击不需要将恶意代码注入用户的页面，仅仅是利用服务器的漏洞和用户的登录状态来实施攻击。

自动发起 Get 请求

<!DOCTYPE html>
<html>
  <body>
    <h1>黑客的站点CSRF演示</h1>
    <img src="https://aa?bb=cc">
  </body>
</html>

比如黑客把一些页面的转账请求隐藏成一张图片资源，当该页面被加载时，浏览器会自动发起 img 的资源请求，如果服务器没有对该请求做判断的话，那么服务器就会对该请求进行处理。

自动发起 POST 请求

除了自动发送 Get 请求之外，有些服务器的接口是使用 POST 方法的，所以黑客还需要在他的站点上伪造 POST 请求，当用户打开黑客的站点时，就自动提交 POST 请求。

引诱用户点击链接

比如页面伪装成一张美女图片诱导用户去点击

和 XSS 不同的是，CSRF 攻击不需要将恶意代码注入用户的页面，仅仅是利用服务器的漏洞和用户的登录状态来实施攻击。

如何防止 CSRF 攻击：

1、充分利用好 Cookie 的 SameSite 属性

因为黑客会利用用户的登录状态来发起 CSRF 攻击，而 Cookie 正是浏览器和服务器之间维护登录状态的一个关键数据，因此要阻止 CSRF 攻击，应该从第三方站点发送请求时禁止 Cookie 的发送。

在 HTTP 响应头中，通过 set-cookie 字段设置 Cookie 时，可以带上 SameSite 选项

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

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

2、验证请求的来源站点

服务器端通过Referer字段或origin属性验证请求来源的站点

3、CSRF Token

在浏览器向服务器发起请求时，服务器生成一个 CSRF Token。CSRF Token 其实就是服务器生成的字符串，然后将该字符串植入到返回的页面中。

在浏览器端如果要发起转账的请求，那么需要带上页面中的 CSRF Token，然后服务器会验证该 Token 是否合法。如果是从第三方站点发出的请求，那么将无法获取到 CSRF Token 的值，所以即使发出了请求，服务器也会因为 CSRF Token 不正确而拒绝请求。