freeBuf
主站

分类

云安全 AI安全 开发安全 终端安全 数据安全 Web安全 基础安全 企业安全 关基安全 移动安全 系统安全 其他安全

特色

热点 工具 漏洞 人物志 活动 安全招聘 攻防演练 政策法规

点我创作

试试在FreeBuf发布您的第一篇文章 让安全圈留下您的足迹
我知道了

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

Wireshark数据抓包分析之HTTP协议
蚁景科技 2021-02-18 16:33:56 430744
所属地 湖南省

HTTP 是一个无状态的协议。无状态 是指客户端 (Web 浏览器)和 服务器之间不 需要建立持久的链接。这 意味着当一个客户端向服务器端发出请求,然后Web 服务器返回响应 ”*”(response) ,连接就被关闭了,在服务器端不保留连接的有关信息 .HTTP 遵 循请求 (Request)/ 应答 (Response) 模型。客户端(Web 浏览器) 向Web 服务器发送请求, Web 服务器处理请求并返回适当的应答。所有 HTTP 连 接都被构造成一套请求和应答。在 该过程中 要经过4 个 阶段,包括建立连接、发送请求信息、发送 响应信息和关闭连接,如下图所示:

1.png

下面 详细介绍上图中描述的HTTP 工作流程,如下

客户端 通过TCP 三次握手与服务器建立连接。

TCP 建立连接成功后,向 服务器发送HTTP 请求。

服务器 接收客户端的HTTP 请求后,将返回应答,并向客户端发送数据

客户端 通过TCP 四次断开,与服务器断开 TCP 连接。

在今天的实验中,我们将通过模拟局域网的两台机器之间的数据传输,配置好HFS软件,来抓取和分析HTTP数据。

根据实验环境,本实验的步骤如下:

1. 配置HFS 软件,获取 HTTP 的 GET数据和POST 数据

2. 分析HTTP数据包

实战步骤一、配置HFS软件,获取HTTP的GET数据和POST数据

在 局域网环境中,我们使用一个小工具来实现HTTP 服务器。先在 服务器上配置HFS

1. 配置HFS软件

本地 解压,进入 文件夹,右键以管理员身份运行。如下

2.png

我们 先配置HFS ,这里能 达到我们的实验 要求,获取到GET 和 POST 数据包即可。点击左上角 的端口 ,输入 端口,这里我们用8080 , 如下,点击确定

3.png

在 虚拟文件系统区域,右键,选择“从磁盘 添加目录”, 选择一个真实 存在的目录(此处注意务必是真实存在的 ),弹出 的选择目录类型 中选择”真实 目录” ,此处 我们用桌面的解压缩目录, 可以看到目录 是红色的

4.png

右键 目录,点击设置”用户名及 密码”, 在弹出的对话框中输入 用户名和密码(demo/demo ), 点击 确定。

5.png

在右键 目录,点击”属性”, 选择”上传”sheet页 ,选中 任何人。点击确定,这样我们 就配置好了HFS 工具,可以在 客户端通过浏览器访问了。

2. 获取HTTP的GET数据和POST数据

下面 我们在测试者 机器上,打开Wireshark 抓包工具, 过滤条件输入ip.addr == 10.1.1.33 ,然后输入服务器 中HFS给出 的网址,等待 服务器响应。成功 之后,可以在测试者机器的 浏览器上看到页面, 如下:

image

这时候, 我们已经获取 到了HTTP 的 GET 方法。 我们将Wireshark 获取的数据包保存为 HTTP-Get。

点击 页面的登录,在对话框中输入用户名密码(demo/demo ),确定 之后等待 服务器响应。成功 如下

7.png

接下来 ,双击页面的文件夹(等待 服务器响应), 同时重新启动Wireshark ,等 待页面刷新成功,8.png

如 上图,会 在左侧 看到按钮 ,点击”上传”按钮 ,选择 文件,这里我们选择桌面上的“http-post.txt”,点击 上传。等待 服务器响应。提示 上传成功,如下

9.png

我们保存 抓包文件 ,名字 为HTTP-Post。 任务一,就 到这里。

实战步骤二、分析HTTP数据包

1. HTTP报文格式

HTTP 由请求和响应 两部分组成,所以对应的也有两种报文格式。下面分别 介绍HTTP 请求报文格式和 HTTP响应 报文格式。

HTTP 请求报文格式

10.png

以上 表格中,第1 行 为“ 请求行” , 第2 、3、4 行为 “请求 头部”, 第5 行 为空行,第6 行 为“请求 正文”。 下面分别 介绍这4 部分:

(1) 请求 行:由3部分组成,分别为:请求方法、URL(见备注1)以及协议版本,之间由空格分隔, 请求方法包括GET、POST等。 协议版本的格式为:HTTP/主版本号.次版本号,常用的有HTTP/1.0和HTTP/1.1。

(2) 请求头部包含很多客户端环境以及请求正文的有用信息。请求头部 由“关键字 :值”对 组成,每行一堆,关键字和值之间使用英文“:”分隔。

(3) 空行,这一行非常重要,必不可少。表示请求头部结束,下面就是请求正文。

(4) 请求正文: 可选部分,比如GET 请求就没有请求正文;POST 比如以提交表单数据方式为请求正文。

HTTP 响应报文格式

11.png

以上 表格中,第1 行 为“状态 行” , 第2 、3、4 行为 “响应 头部”, 第5 行 为空行,第6 行 为“响应 正文”。 下面分别 介绍这4 部分:

(1) 状态 行由 由3部分组成,分别为:协议版本,状态码,状态码描述,之间由空格分隔。 状态代码为3位数字,200~299的状态码表示成功,300~399的状态码指资源重定向,400~499的状态码指客户端请求出错,500~599的状态码指服务端出错(HTTP/1.1向协议中引入了信息性状态码,范围为100~199)。这里列举几个常见的:

状态码说明
200响应成功
400客户端请求有语法错误,不能被服务器识别
404请求资源不存在
500服务器内部错误

(3) 空行,这一行非常重要,必不可少。表示响应头部结束

(4) 响应 正文,服务器返回的文档,最常见的为HTML网页。

2. HTTP的头域

在HTTP的 请求消息 和应答消息中,都包含头域。头域 分为4 种 ,其中请求 头域和应答头域分别只在请求消息和应答消息中出现,通用头域和实体头域在两种消息中都可以出现,但实体头域只有当 消息中包含了实体数据时 才会出现。下面分别 介绍这4 种 头域中的域名城和功能。

HTTP请求头域

Header解释
Accept指定客户端能够接收的内容类型
Accept-Charset浏览器可以接受的字符编码集。
Accept-Encoding指定浏览器可以支持的web服务器返回内容压缩编码类型。
Accept-Language浏览器可接受的语言
Accept-Ranges可以请求网页实体的一个或者多个子范围字段
AuthorizationHTTP授权的授权证书
Cache-Control指定请求和响应遵循的缓存机制
Connection表示是否需要持久连接。(HTTP 1.1默认进行持久连接)
CookieHTTP请求发送时,会把保存在该请求域名下的所有cookie值一起发送给web服务器。
Content-Length请求的内容长度
Content-Type请求的与实体对应的MIME信息
Date请求发送的日期和时间
Expect请求的特定的服务器行为
From发出请求的用户的Email
Host指定请求的服务器的域名和端口号
If-Match只有请求内容与实体相匹配才有效
If-Modified-Since如果请求的部分在指定时间之后被修改则请求成功,未被修改则返回304代码
If-None-Match如果内容未改变返回304代码,参数为服务器先前发送的Etag,与服务器回应的Etag比较判断是否改变
If-Range如果实体未改变,服务器发送客户端丢失的部分,否则发送整个实体。参数也为Etag
If-Unmodified-Since只在实体在指定时间之后未被修改才请求成功
Max-Forwards限制信息通过代理和网关传送的时间
Pragma用来包含实现特定的指令
Proxy-Authorization连接到代理的授权证书
Range只请求实体的一部分,指定范围
Referer先前网页的地址,当前请求网页紧随其后,即来路
TE客户端愿意接受的传输编码,并通知服务器接受接受尾加头信息
Upgrade向服务器指定某种传输协议以便服务器进行转换(如果支持)
User-AgentUser-Agent的内容包含发出请求的用户信息
Via通知中间网关或代理服务器地址,通信协议
Warning关于消息实体的警告信息
Accept指定客户端能够接收的内容类型

应答 头域只在应答消息中出现,是Web 服务器向浏览器提供的一些状态和要求。如下

HTTP应答头域

Header解释
Accept-Ranges表明服务器是否支持指定范围请求及哪种类型的分段请求
Age从原始服务器到代理缓存形成的估算时间(以秒计,非负)
Allow对某网络资源的有效的请求行为,不允许则返回405
Cache-Control告诉所有的缓存机制是否可以缓存及哪种类型
Content-Encodingweb服务器支持的返回内容压缩编码类型。
Content-Language响应体的语言
Content-Length响应体的长度
Content-Location请求资源可替代的备用的另一地址
Content-MD5返回资源的MD5校验值
Content-Range在整个返回体中本部分的字节位置
Content-Type返回内容的MIME类型
Date原始服务器消息发出的时间
ETag请求变量的实体标签的当前值
Expires响应过期的日期和时间
Last-Modified请求资源的最后修改时间
Location用来重定向接收方到非请求URL的位置来完成请求或标识新的资源
Pragma包括实现特定的指令,它可应用到响应链上的任何接收方
Proxy-Authenticate它指出认证方案和可应用到代理的该URL上的参数
Retry-After如果实体暂时不可取,通知客户端在指定时间之后再次尝试
Serverweb服务器软件名称
Set-Cookie设置Http Cookie
Trailer指出头域在分块传输编码的尾部存在
Transfer-Encoding文件传输编码
Vary告诉下游代理是使用缓存响应还是从原始服务器请求
Via告知代理客户端响应是通过哪里发送的
Warning警告实体可能存在的问题
WWW-Authenticate表明客户端请求实体应该使用的授权方案
refresh应用于重定向或一个新的资源被创造,在5秒之后重定向(由网景提出,被大部分浏览器支持)

通用 头域既可以用在 请求消息中,也可以用在应答消息。

HTTP通用头域

Header解释
Cache-ControlCache-Control指定请求和响应遵循的缓存机制,可以附带很多的规定值。
Connection表示是否需要持久连接
Date表示消息发送的时间
PragmaPragma头域用来包含实现特定的指令,最常用的是Pragma:no-cache,用于定义页面缓存
Trailer表示以Chunked编码传输的实体数据的尾部存在哪些头域
Transfer-EncodingWEB 服务器表明自己对本响应消息体(不是消息体里面的对象)作了怎样的编码,比如是否分块(chunked),例如:Transfer-Encoding: chunked
Upgrade它可以指定另一种可能完全不同的协议,如HTTP/1.1客户端可以向服务器发送一条HTTP/1.0请求,其中包含值为“HTTP/1.1”的Update头部,这样客户端就可以测试一下服务器是否也使用HTTP/1.1了。
Via列出从客户端到 OCS 或者相反方向的响应经过了哪些代理服务器,他们用什么协议(和版本)发送的请求。
Warning用于警告应用到实体数据上的缓存操作或转换可能缺少语义透明度。

只有在请求和应答消息中包含实体数据时, 才需要实体头域。 请求消息中的实体数据是一些由浏览器向web服务器提交的数据,如在浏览器中采用POST方式提交表单时,浏览器就要把表单中的数据封装在请求消息的实体数据部分。应答消息中的实体数据是web服务器发给浏览器的媒体数据,如网页,图片和文档等。实体头域说明了实体数据的一些属性。如下表

HTTP实体头域

Header解释
Allow列出由请求URI标识的资源所支持的方法集
Content-Encoding说明实体数据是如何编码的
Content-Language说明实体数据所采用的自然语言
Content-Length说明实体数据的长度
Content-Location说明实体数据的资源位置
Content-MD5给出实体数据的 MD5值,用于保证实体数据的完整性
Content-Range用于指定整个实体中的一部分的插入位置,他也指示了整个实体的长度。在服务器向客户返回一个部分响应,它必须描述响应覆盖的范围和整个实体长度
Content-Type用于向接收方指示实体的介质类型,指定 HEAD 方法送到接收方的实体介质类型,或 GET 方法发送的请求介质类型
Expires指定实体数据的有效期
Last-Modified指定服务器上保存内容的最后修订时间。

3. 分析GET方法的HTTP数据包

我们 以HTTP-Get 数据包为例 ,分析GET 方法的HTTP 请求和响应数据包。

分析HTTP请求包

我们 打开数据包,输入过滤条件ip.addr == 10.1.1.33,如下

12.png

前三个 是TCP 的三次握手,第四个 数据包则是客户端向服务器 发送的HTTP 请求包,我们来学习分析下,

13.png

HTTP 之前的协议,本次我们 不做讲解, 不懂的同学可以看之前的实验,我们来看下HTTP 协议。

Hypertext Transfer Protocol

GET / HTTP/1.1\r\n # 请求行信息

Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n # 专家信息

GET / HTTP/1.1\r\n

Severity level: Chat

Group: Sequence

Request Method: GET # 请求方法为 GET

Request URI: / # 请求的 URI

Request Version: HTTP/1.1 # 请求的版本为HTTP/1.1

Host: 10.1.1.33:8080\r\n # 请求的主机

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0\r\n # 浏览器类型

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8\r\n # 请求的类型

Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3\r\n # 请求语言

Accept-Encoding: gzip, deflate\r\n # 请求的编码格式

Connection: keep-alive\r\n # 使用持久连接

\r\n #空行

Full request URI: 10.1.1.33:8080/ # 请求的 URI 为10.1.1.33:8080

HTTP request 1/8

Response in frame: 2770 #应答 是第2770 帧

Next request in frame: 2775 # 下一个请求是第2775 帧

以上 就是HTTP 请求包的相关信息,可以看到客户端使用HTTP/1.1版本 向服务器发送了GEY 请求,请求 访问10.1.1.33 的 服务器。 将以上 信息填入到报文 格式中,如下

GET方法的HTTP请求报文格式

GET空格/空格HTTP/1.1\r\n
Accept:text/html,application/xhtml+xml,application/xml\r\n







Connection:keep-alive\r\n

\r\n




Full request URI: 10.1.1.33:8080/





分析HTTP响应包

根据请求包 的信息,我们已经知道, 响应包是第2770 帧 ,下面我们来看下

14.png

在HTTP 之前,我们看到了 下图显示的,TCP重组 片段, 这些片段共有2270 个 字节,由于超过 了TCP 数据包的最大数据分段(MSS ),所以将数据在TCP 层进行了分段。 从下面 的信息,可以看到 分断后的数据包及包大小,如#2767 (247 ), 其中2767 表示 帧号,大小 为247 个 字节。

15.png

下面 来看HTTP 的具体 部分

Hypertext Transfer Protocol

HTTP/1.1 200 OK\r\n # 响应行信息

Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n #专家 信息

HTTP/1.1 200 OK\r\n #HTTP 响应信息,响应码为200

Severity level: Chat

Group: Sequence

Request Version: HTTP/1.1 # 请求吧

Status Code: 200 # 状态码

Response Phrase: OK # 响应短语

Content-Type: text/html\r\n # 响应的内容类型

Content-Length: 2023\r\n #包 的长度

Content length: 2023

Accept-Ranges: bytes\r\n #服务器支持 的请求:字节

Server: HFS 2.3 beta\r\n # 服务器类型

Set-Cookie: HFS_SID=0.248448607278988; path=/; \r\n # 设置 Http Cookie

Cache-Control: no-cache, no-store, must-revalidate, max-age=-1\r\n # 缓存控制

Content-Encoding: gzip\r\n # 实体数据的压缩格式

\r\n # 空行

HTTP response 1/8 #HTTP 响应

Time since request: 0.015248000 seconds # 响应使用的时间

Request in frame: 2763 # 请求的帧号为2763

Next request in frame: 2775 # 下一个请求 的 帧号2775

Next response in frame: 2778 #下一个响应 的帧号是2778

Content-encoded entity body (gzip): 2023 bytes -> 4375 bytes #内容 编码(gzip )

Line-based text data: text/html # 基于行的文本数据

根据 以上信息,可以知道服务器使用HTTP/1.1 200 OK 响应了 客户端的请求。将信息 填入到报文格式中,如下

GET方法的HTTP响应报文格式

HTTP/1.1空格200空格OK\r\n
Content-Type:text/html\r\n







Content-Encoding:gzip\r\n

\r\n




省略





4. 分析POST方法的HTTP数据包

分析HTTP请求包

下面 我们以HTTP-Post 为例,分析 POST 方法的 HTTP 请求和响应。打开 数据包,输入过滤条件ip.addr ==10.1.1.33, 显示 出的HTTP 中,Info列中还有POST 的即可 ,如下

16.png

我们 展开分析下

Hypertext Transfer Protocol #HTTP 协议

POST /hfs2_3b287/ HTTP/1.1\r\n # 请求行

Expert Info (Chat/Sequence): POST /hfs2_3b287/ HTTP/1.1\r\n #专家 信息

POST /hfs2_3b287/ HTTP/1.1\r\n

Severity level: Chat

Group: Sequence

Request Method: POST # 请求方法为 POST

Request URI: /hfs2_3b287/ # 请求 的URI

Request Version: HTTP/1.1 #请求 的版本

Host: 10.1.1.33:8080\r\n # 使用的主机

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0\r\n # 使用的浏览器类型

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8\r\n # 浏览器接受的类型

Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3\r\n # 希望使用的语言

Accept-Encoding: gzip, deflate\r\n # 可使用的编码格式,这里是 gzip 和 deflate

Referer: 10.1.1.33:8080/hfs2_3b287/\r\n #从 包含的URL 页面发起请求

Cookie: HFS_SID=0.248448607278988\r\n #Cookie信息

Cookie pair: HFS_SID=0.248448607278988

Authorization: Basic ZGVtbzpkZW1v\r\n #授权 证书信息

Credentials: demo:demo # 登录的用户名密码

Connection: keep-alive\r\n # 使用持久连接

Content-Type:multipart/form-data;boundary=---------------------------54542580413055\r\n # 请求的内容类型

Content-Length: 367\r\n # 包的长度

Content length: 367

\r\n # 空行

Full request URI: 10.1.1.33:8080/hfs2_3b287/ # 请求的 URI 为10.1.1.33:8080/hfs2_3b287

HTTP request 1/6

Response in frame: 3800 # 响应的帧号

Next request in frame: 3802 # 下一个请求的 正好

以上 就是使用POST 方法的 HTTP 请求包,可以看到请求的连接及登录的用户名密码等。将上面 的信息填入到报文格式中,如下

POST方法的HTTP请求报文格式

POST空格/hfs2_3b287/空格HTTP/1.1\r\n
Accept:text/html,application/xhtml+xml,application/xml\r\n







Content-Length:367\r\n

\r\n




忽略





另外 ,我们 在HTTP 的下面,看到了如下的内容

17.png

类型 的Multipart/form-data 是上传文件的一种方式。 Multipart/form-data 其实就是浏览器用表单上传文件的方式。最常见的情境是:在写邮件时,向邮件后添加附件,附件通常使用表单添加,也就是用 multipart/form-data 格式上传到服务器。我们 实验中向 服务器上传了一个文件,所以就是此类型。

在 看Wireshark中 的使用

​ 首先看wireshark 中字段与 Multipart/form-data 的对应关系: MIME Multipart Media Encapsulation :代表整个 Multipart/form-data 上传文件中的数据。

​ Encapsulated multipart part :代表表单中不同部分的数据。

​ Boundary :用来隔开表单中不同部分的数据。

​ 其次,

​ 1) MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary: "---------------------------54542580413055"

​ 这行指出这个请求是 multipart/form-data 格式的,且 boundary 是 “----------54542580413055” 这个字符串。

​ 2 )关于 Boundary : Boundary :用来隔开表单中不同部分的数据。实际上,每部分数据的开头都是由 “--”+boundary 开始的(这是 MIME 标准中讲述的标准内容)。

​ 3 ) Encapsulated multipart part :紧跟着 boundary 的是该部分数据的描述:

​ Content-Dispostion:form-data;name="Filename"\r\n

​ 每一个 part 至少一个 name 和一个 content 部分。

可以从 上面的multipart/form-data中 ,看到我们上传的文本名字为http-post.txt, 内容为“This is demo for HTTP POST”。

分析HTTP响应

根据Wireshark 现实的响应包帧数,我们来看下第3800 帧 。

18.png

Hypertext Transfer Protocol #HTTP 协议

HTTP/1.1 200 OK\r\n # 响应行

Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n #专家 信息

HTTP/1.1 200 OK\r\n # 响应信息

Severity level: Chat

Group: Sequence

Request Version: HTTP/1.1 # 请求版本

Status Code: 200 # 状态码

Response Phrase: OK #响应 短语

Content-Type: text/html\r\n # # 响应包类似

Content-Length: 570\r\n # 响应包长度

Content length: 570

Accept-Ranges: bytes\r\n #服务器支持 的请求:字节

Server: HFS 2.3 beta\r\n #web 服务器类型

Content-Encoding: gzip\r\n # 实体数据的压缩格式

\r\n #空行

HTTP response 1/6 # 响应

Time since request: 0.008774000 seconds # 响应请求的时间

Request in frame: 3798 #请求 的帧号

Next request in frame: 3802 # 下一个请求的帧号

Next response in frame: 3804 # 下一个响应的 帧号

Content-encoded entity body (gzip): 570 bytes -> 866 bytes #内容 编码(gzip )

Line-based text data: text/html # 文本内容

以上 就是POST 方法的 HTTP 响应包,可以看到服务器向客户端发送了 HTTP/1.1 200 OK响应 了HTTP 请求包。服务器类型为HFS 2.3 beta, 将数据填入到报文格式中

POST方法的HTTP响应报文格式

HTTP/1.1空格200空格OK\r\n
Server:HFS 2.3 beta\r\n







Content-Encoding:gzip\r\n

\r\n




省略





实验中我们 讲解了 主要的GET和POST 方法, 可以抓包 考虑, 学习其他的方法,动手提高能力 。

本文涉及相关实验:Wireshark数据抓包分析之HTTP协议

# Wireshark # HTTP
免责声明
1.一般免责声明:本文所提供的技术信息仅供参考,不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》,作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。
2. 适用性声明:文中技术内容可能不适用于所有情况或系统,在实际应用前请充分测试和评估。若因使用不当造成的任何问题,相关方不承担责任。
3. 更新声明:技术发展迅速,文章内容可能存在滞后性。读者需自行判断信息的时效性,因依据过时内容产生的后果,作者及发布平台不承担责任。
本文为 蚁景科技 独立观点,未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
蚁景科技 LV.9
湖南蚁景科技有限公司主要从事在线教育平台技术研究及网络培训产品研发,专注网络空间安全实用型人才培养,全面提升用户动手实践能力。
  • 907 文章数
  • 675 关注者
蚁景科技荣膺双项殊荣,引领网络安全教育新潮流
2025-03-28
FlowiseAI 任意文件写入漏洞(CVE-2025–26319)
2025-03-27
路由器安全研究:D-Link DIR-823G v1.02 B05 复现与利用思路
2025-03-18
文章目录