xss csrf和其他网络攻击

# XSS（跨站脚本攻击）

XSS (Cross-Site Scripting)，跨站脚本攻击，因为缩写和CSS重叠，所以只能叫 XSS。跨站脚本攻击是指通过存在安全漏洞的Web网站注册用户的浏览器内运行非法的HTML标签或JavaScript进行的一种攻击。

# 存储型XSS

特点：

恶意脚本被存在数据库中
访问页面——>读数据——> 被攻击
危害最大，对全部用户可见

存储型 XSS 的攻击步骤：

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

# 反射型XSS

特点：

不涉及数据库
从URL上攻击

反射型 XSS 的攻击步骤：

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

# DOM型XSS

特点：

不需要服务器参与
恶意攻击的发起 + 执行，全在浏览器完成

DOM 型 XSS的攻击步骤：

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

# XSS 防御

输入检查。对于用户的输入进行检查、转义、过滤等。建立可信任的字符和html标签白名单，对于不在白名单吧内的字符或者标签进行过滤或编码；
设置HttpOnly，浏览器将禁止页面的JavaScript访问带有HttpOnly属性的cookie,来防止恶意脚本通过document.cookie访问到用户隐私数据；
配置浏览器 Content Security Policy(CSP) 安全策略
哪些源（域名）被认为是安全的
来自安全源的脚本可以执行，否则直接抛错
对eval + inline script 说不

如何配置：

服务器的响应头部：
Content-Security-Policy: script-src 'self' 同源
Content-Security-Pplicy: script-src 'self' https://domain.com

浏览器meta：
<meta http-equiv="Content-Security-Policy" content="script-src self">

1
2
3
4
5
6
7

在使用 .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量使用 .textContent、.setAttribute() 等。DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等，标签的href属性，JavaScript 的eval()、setTimeout()、setInterval()等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免。如果拼接 HTML 是必要的，就需要采用合适的转义库，对 HTML 模板各处插入点进行充分的转义。推荐一个前端防止XSS攻击的插件: js-xss(https://juejin.cn/post/6913344728515739661#heading-0)

# CSRF（跨站请求伪造）

CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

CSRF的一些特点：

在用户不知情的前提下
利用用户权限（cookie）
构造指定HTTP请求，窃取或修改用户敏感信息

攻击流程：

受害者登录a.com，并保留了登录凭证（Cookie）。
攻击者引诱受害者访问了b.com。
b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带a.com的Cookie。
a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。
a.com以受害者的名义执行了act=xx。
攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。

# 防御 CSRF

1.添加验证码(体验不好)
2.判断请求的来源:检测Referer和Origin(并不安全,Referer可以被更改)
Referer 可以作为一种辅助手段,来判断请求的来源是否是安全的, 但是鉴于 Referer 本身是可以修改的 , 因此不能仅依赖于 Referer。在HTTP协议中，每一个异步请求都会携带两个Header，用于标记来源域名：

Origin Header
Referer Header

1
2

这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端自定义内容。服务器可以通过解析这两个Header中的域名，确定请求的来源域。但是这两种都会出现不存在的情况。

Origin在以下两种情况下并不存在：


IE11同源策略： IE 11 不会在跨站CORS请求上添加Origin标头，Referer头将仍然是唯一的标识。最根本原因是因为IE 11对同源的定义和其他浏览器有不同，有两个主要的区别，可以参考MDN Same-origin_policy#IE_Exceptions


302重定向： 在302重定向之后Origin不包含在重定向的请求中，因为Origin可能会被认为是其他来源的敏感信息。对于302重定向的情况来说都是定向到新的服务器上的URL，因此浏览器不想将Origin泄漏到新的服务器上。

1
2
3
4
5
6
7

攻击者可以在自己的请求中隐藏Referer。如果攻击者将自己的请求这样填写：

 <img src="http://bank.example/withdraw?amount=10000&for=hacker" referrerpolicy="no-referrer">

那么这个请求发起的攻击将不携带Referer。另外在以下情况下Referer没有或者不可信：

1.IE6、7下使用window.location.href=url进行界面的跳转，会丢失Referer。
2.IE6、7下使用window.open，也会缺失Referer。
3.HTTPS页面跳转到HTTP页面，所有浏览器Referer都丢失。
4.点击Flash上到达另外一个网站的时候，Referer的情况就比较杂乱，不太可信。

1
2
3
4

3.使用Token(主流) CSRF攻击之所以能够成功, 是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的 Token。服务器通过校验请求是否携带正确的Token , 来把正常的请求和攻击请求区分开。跟验证码类似,只是用户无感知
4.Samesite Cookie属性为了从源头上解决这个问题, Google 起草了一份草案来改进 HTTP协议 , 为 Set-Cookie 响应头新增 Samesite 属性 , 它用来表明这个 Cookie 是个 "同站Cookie" , 同站 Cookie只能作为第一方 Cookie, 不能作为第三方 Cookie, Samesite 有两个属性值 , 分别是 Strict 和 Lax。部署简单, 并能有效防御 CSRF 攻击 , 但是存在兼容性问题 Samesite=Strict Samesite=Strict 被成为是严格模式 , 表明这个 Cookie 在任何情况都不可能作为第三方的 Cookie, 有能力阻止所有 CSRF攻击。此时 , 我们在B 站点下发起对 A 站点的任何请求, A站点的 Cookie 都不会包含在 cookie请求头中。

# SYN 泛洪攻击

TCP 只有经过三次握手才能连接，而 SYN 泛洪攻击就是针对 TCP 握手过程进行攻击：

攻击者发送大量的 SYN 包给服务器（第一次握手成功）
服务器回应(SYN + ACK）包（第二次握手成功）
但是攻击者不回应 ACK 包（第三次握手不进行）

导致服务器存在大量的半开连接，这些半连接可以耗尽服务器资源，使被攻击服务器无法再响应正常 TCP 连接，从而达到攻击的目的

# 防御方式

一种称为 SYN cookie 的有效防御现在已部署在大多数主要的操作系统中
在客户端发送 SYN 报文给服务器（第一次握手），服务端收到连接请求报文段后，服务器不会为此SYN创建半开连接，而是生成一个序列号（所谓的 cookie）一起发送给客户端（第二次握手），在这个阶段，服务器不会为该连接分配任何资源
客户端返回 ACK 报文给服务器（第三次握手），服务器会验证这个 cookie 值，只有验证成功才创建 TCP 连接，分配资源
如果客户端没有返回 ACK 报文给服务器，也不会对服务器造成任何的伤害，因为服务器没有分配任何资源给它

最近更新时间： 2022/09/28 16:26:36

← 拯救你的年底KPI：前端性能优化