-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
6 changed files
with
205 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
--- | ||
title: 跨域及其解决方案 | ||
author: lvzl | ||
--- | ||
|
||
<script setup> | ||
import XmindViewer from '@/XmindViewer' | ||
</script> | ||
|
||
<XmindViewer url="https://mp-cb2e47ef-a802-469a-a81c-2b6efa9f8b60.cdn.bspapp.com/blog-resource/xmind/cross-origin.xmind"/> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,76 @@ | ||
--- | ||
title: 网络安全之CSRF攻击 | ||
author: lvzl | ||
--- | ||
|
||
## 是什么 | ||
|
||
CSRF(Cross-site request forgery)跨站请求伪造:攻击者**诱导受害者进入第三方网站,在第三方网站中,向被攻击网站发送跨站请求**。利用受害者在被攻击网站已经获取的注册凭证,绕过后台的用户验证,达到冒充用户对被攻击的网站执行某项操作的目的。 | ||
|
||
一个典型的 CSRF 攻击有着如下的流程: | ||
|
||
1. 受害者登录 a.com,并保留了登录凭证(Cookie)。 | ||
2. 攻击者引诱受害者访问了 b.com。 | ||
3. b.com 向 a.com 发送了一个请求:a.com/act=xx。浏览器会… | ||
4. a.com 接收到请求后,对请求进行验证,并确认是受害者的凭证,误以为是受害者自己发送的请求。 | ||
5. a.com 以受害者的名义执行了 act=xx。 | ||
6. 攻击完成,攻击者在受害者不知情的情况下,冒充受害者,让 a.com 执行了自己定义的操作。 | ||
|
||
## 特点是什么 | ||
|
||
1. CSRF(通常)发生在第三方域名。 | ||
2. CSRF 攻击者不能获取到 Cookie 等信息,只是使用。 | ||
3. 通常是跨域请求 | ||
|
||
## 有哪些类型 | ||
|
||
### GET 类型的 CSRF | ||
|
||
```html | ||
<img src="http://bank.example/withdraw?amount=10000&for=hacker" > | ||
``` | ||
访问含有这个 img 的页面后,浏览器会自动向`http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker`发出一次 HTTP 请求。bank.example 就会收到包含受害者登录信息的一次*跨域请求*。 | ||
|
||
### POST 类型的 CSRF | ||
|
||
```html | ||
<form action="http://bank.example/withdraw" method=POST> | ||
<input type="hidden" name="account" value="xiaoming" /> | ||
<input type="hidden" name="amount" value="10000" /> | ||
<input type="hidden" name="for" value="hacker" /> | ||
</form> | ||
<script> document.forms[0].submit(); </script> | ||
|
||
``` | ||
|
||
访问该页面后,表单会自动提交,相当于模拟用户完成了一次 POST 操作。 | ||
|
||
### 链接类型的 CSRF | ||
|
||
```html | ||
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank"> | ||
重磅消息!! | ||
<a/> | ||
|
||
``` | ||
|
||
需要点击才会中招。 | ||
|
||
## 如何防范 | ||
|
||
1. 同源检测,通过请求头中的 origin、referer 确定域名是否是合法的域名,外域直接禁止。但在某些场景可能两者都获取不到,这种情况建议直接禁止;还有可能 referer 被修改,并不太可靠。 | ||
2. CSRF Token | ||
- 用户登录以后 -> 加密算法对数据进行加密生成 token,并将用户信息放到 session -> 返回给前端,但是不能放到 cookie 了 | ||
- 用户请求,带上这个 token -> 服务器解密这个 token,并从 session 取出用户信息比对,看是否一致。不过针对那种 标签上的 href、src 等请求,就需要开发人员手动设置上 token | ||
- 这种方式 session 默认存储在单机服务器内存中,只能运用在单机的服务器上,不适用于分布式的服务。 | ||
- 读取和验证CSRF Token会引起比较大的复杂度和性能问题 | ||
3. 分布式校验 | ||
- 服务器通过一种加密算法根据用户信息得到一个token(userinfo.签名),保证签名不容易被破解,不再往 session 存 token | ||
- 请求携带过来的token,拿到 userinfo,只需要再按同样的加密算法计算一次,比较与携带过来的是否一致,即可得出是不是伪造的token | ||
- 比较可靠 | ||
4. 双重cookie验证,双重Cookie采用以下流程: | ||
- 在用户访问网站页面时,向请求域名注入一个Cookie,内容为随机字符串(例如csrfcookie=v8g9e4ksfhw)。 | ||
- 在前端向后端发起请求时,取出Cookie,并添加到URL的参数中(接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw)。 | ||
- 后端接口验证Cookie中的字段与URL参数中的字段是否一致,不一致则拒绝。 | ||
- 安全性还是没有CSRF Token高 | ||
5. sameSite 设置为 strict,表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie,绝无例外。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
--- | ||
title: http 响应状态码 | ||
author: lvzl | ||
--- | ||
|
||
HTTP 请求状态码是 Web 服务器向客户端返回的 3 位数字代码,用于指示 HTTP 请求的结果和状态。这些状态码分为五个不同的类别,每个类别具有特定的含义。以下是一些常见的 HTTP 请求状态码和它们的含义: | ||
|
||
1. **1xx(信息性状态码)**:这些状态码表示请求已被接收,继续处理。 | ||
|
||
- **100 Continue**: 服务器正在等待继续的请求头。客户端可以发送请求的主体部分。 | ||
|
||
2. **2xx(成功状态码)**:这些状态码表示请求已成功被服务器接收、理解、并接受。 | ||
|
||
- **200 OK**: 请求成功,服务器已经返回请求的资源。 | ||
- **201 Created**: 请求已成功,并且服务器创建了新的资源。 | ||
- **204 No Content**: 请求成功,但服务器没有返回任何内容。 | ||
|
||
3. **3xx(重定向状态码)**:这些状态码表示客户端需要执行额外的操作以完成请求。 | ||
|
||
- **301 Moved Permanently**: 资源已永久移动到新位置,客户端应该更新其链接。 | ||
- **302 Found**: 资源临时移动到新位置,客户端应该使用新位置重新发起请求(有时用于实现重定向)。 | ||
- **304 Not Modified**: 资源未被修改,客户端可以使用缓存的内容。 | ||
|
||
4. **4xx(客户端错误状态码)**:这些状态码表示客户端发送的请求有误,服务器无法处理。 | ||
|
||
- **400 Bad Request**: 请求语法或参数错误,服务器无法理解。 | ||
- **401 Unauthorized**: 请求未进行身份验证或身份验证失败。 | ||
- **403 Forbidden**: 服务器拒绝了请求,通常因为权限不足。 | ||
- **404 Not Found**: 请求的资源在服务器上未找到。 | ||
- **405 Method Not Allowed**: 请求使用了不被允许的 HTTP 方法。 | ||
|
||
5. **5xx(服务器错误状态码)**:这些状态码表示服务器在处理请求时发生了错误。 | ||
|
||
- **500 Internal Server Error**: 服务器遇到了意外的错误,无法完成请求。 | ||
- **502 Bad Gateway**: 服务器作为网关或代理,从上游服务器接收到无效响应。 | ||
- **503 Service Unavailable**: 服务器暂时不可用,通常是由于维护或过载。 | ||
- **504 Gateway Timeout**: 服务器作为网关或代理,从上游服务器没有及时收到响应。 | ||
|
||
这些 HTTP 状态码是 HTTP 协议的一部分,用于在客户端和服务器之间传递关于请求和响应状态的信息。它们帮助开发人员和系统管理员了解请求的结果以及如何处理它们。当开发 Web 应用程序时,理解这些状态码是非常重要的,因为它们可以帮助您调试和解决问题。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
--- | ||
title: 网络 | ||
author: lvzl | ||
--- | ||
记录一些网络相关的知识! | ||
|
||
<script setup> | ||
import XmindViewer from '@/XmindViewer' | ||
</script> | ||
|
||
<XmindViewer url="https://mp-cb2e47ef-a802-469a-a81c-2b6efa9f8b60.cdn.bspapp.com/blog-resource/xmind/browser-rendering-flow.xmind"/> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
module.exports = { | ||
navText: '计算机网络相关', | ||
sort: 9, | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,65 @@ | ||
--- | ||
title: 网络安全之XSS攻击 | ||
author: lvzl | ||
--- | ||
|
||
## 是什么 | ||
|
||
`Cross-Site Scripting`(跨站脚本攻击)简称 `XSS`,是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本,使之在用户的浏览器上运行。利用这些恶意脚本,攻击者可获取用户的敏感信息如 `Cookie` 等,进而危害数据安全。 | ||
为了和 `CSS` 区分,这里把攻击的第一个字母改成了 `X`,于是叫做 `XSS`。 | ||
`XSS` 的本质是:**恶意代码未经过滤,与网站正常的代码混在一起;浏览器无法分辨哪些脚本是可信的,导致恶意脚本被执行。** | ||
|
||
## 特点是什么 | ||
|
||
**恶意代码直接在用户的终端执行,可以访问用户信息(cookie 等),发起攻击请求** | ||
|
||
## 有哪些类型 | ||
|
||
`XSS` 攻击可分为`存储型`、`反射型`和 `DOM 型`三种。 | ||
|
||
### 存储型 | ||
|
||
假如我在掘金写的文章里,加了一些恶意的脚本: | ||
|
||
```html | ||
<script>alert('我正在攻击你')</script> | ||
``` | ||
|
||
如果掘金没有处理,那么当别的用户打开我的文章,我的脚本就能执行,这就是典型的存储型`XSS` 攻击。 | ||
|
||
### 反射型 | ||
|
||
我这次改了一种方式,我在文章里加了一个超链接: | ||
|
||
```html | ||
嘿,点击这里查看有趣的照片:<a href="https://xxx.com/?image=<script>alert('这可是你自己点了,我才攻击你');</script>">点击这里</a> | ||
``` | ||
|
||
这就是典型的反射型`XSS` 攻击。 | ||
|
||
### DOM 型 | ||
|
||
假如掘金的评论是前端动态添加到页面,那么我在评论中写到: | ||
|
||
```html | ||
<script>alert('我正在攻击你')</script> | ||
``` | ||
|
||
此时正在浏览这篇文章的另一个人的客户端收到我新增的评论,然后未经过任何处理的情况下添加了这个评论到页面(比如通过 `document.write`、`innerHtml`),那么恶意代码将执行。 | ||
|
||
### 区别 | ||
|
||
- 反射型 XSS 跟存储型 XSS 的区别是:存储型 XSS 的恶意代码存在数据库里,反射型 XSS 的恶意代码存在 URL 里。 | ||
- DOM 型 XSS 跟前两种 XSS 的区别:DOM 型 XSS 攻击中,取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞,而其他两种 XSS 都属于服务端的安全漏洞。 | ||
|
||
## 如何防范 | ||
|
||
1. 输入校验长度、合法性能避免一些 XSS 攻击 | ||
2. 后端使用可靠的转义库来转译 html | ||
3. 纯前端渲染,明确的告诉浏览器:要设置的内容是文本(.innerText),还是属性(.setAttribute),还是样式(.style)等等。浏览器不会被轻易的被欺骗,执行预期外的代码。针对内部管理系统可以,SEO 要求高的系统不行 | ||
4. DOM 中的内联事件监听器,慎用 | ||
5. Vue 中慎用 v-html | ||
6. Js 中使用 .innerHTML、.outerHTML、document.write() 时要特别小心,不要把不可信的数据作为 HTML 插到页面上,而应尽量使用 .textContent、.setAttribute() 等。 | ||
7. cookie 设置成 Http-Only,这样可以防止脚本被 JS 读取 | ||
8. 敏感操作加验证码多层验证,防止脚本冒充用户执行 | ||
9. 合理配置CSP(内容安全策略) |