3 第三天【2024/1/1】
一：学习部分
-
抓包
-
意义
当目标的信息不清楚，比如一些内封的小程序或者软件，需要抓包来获得IP等额外信息
-
常见抓包工具
-
Fiddler
这是一个http协议调试代理工具，能够记录并检查你的电脑和互联网之间的http通讯。
-
Charles
这是一个HTTP代理服务器、HTTP监视器、反转代理服务器，当浏览器连接Charles 的代理访问互联网时，Charles可以监控浏览器发送和接收的所有数据。
-
TCPDump
可以将网络中传输的数据包完全截获下来提供分析。支持针对网络层、协议、主机、网络或端口的过滤。
-
BurpSuite
适用于攻击web应用程序的集成平台，包含了许多工具。
-
Wireshark
网络封包分析软件。截获网络封包，并尽可能地提供最为详细的网络封包资料。
-
科来网络分析系统
国产，捕获并分析网络中传输的底层数据包。
总体而言比较类似于Wireshark软件，但是可以自动筛选不同的应用程序的请求数据，图形化界面更加人性。
-
-
为什么需要用到这么多的工具？
因为针对的是不同的使用场景
有些APP里面的数据包，使用的不是HTTP协议，而是使用的其他协议，这个时候使用FIddler等工具就无法捕获到数据包，可以转而使用Wireshark工具来进行捕获。
封包不同于抓包，需要使用Wireshark等其他软件进行捕获。
-
-
安装相关工具
安装完成之后需要安装相应的证书才能抓包
-
Charles
证书安装教程：
https://blog.csdn.net/weixin_45459427/article/details/108393878 -
Fidder
证书安装教程：
https://blog.csdn.net/weixin_45043349/article/details/120088449
-
BurpSuite
证书安装教程：
https://blog.csdn.net/qq_36658099/article/details/81487491
-
-
案例演示——安卓模拟器小游戏，使用封包监听工具重发送数据包实现功能再触发
-
场景复现
- 打开安卓模拟器，打开“封包监听工具1.13”
- 清空监听工具中其他数据包，选中待捕获的目标进程，然后快速触发小游戏中的某个功能，演示中点击的是小游戏中的“回城”功能
- 触发功能之后，停止捕获
- 查看捕获的数据封包，分析功能实现的效果，分析猜测是通过“发送”封包来实现的，所以找其中的“发送”类别的封包，然后重新发送
- 成功再次触发“回城”效果
-
二：思考待完成部分
-
安装安卓模拟器
安装逍遥或者雷神模拟器
-
思考：针对于“封包监听工具再触发功能”案例演示
-
思考下面这样一种场景：
如果应用的一个功能的实现方式，是通过在应用中只在交互界面中出现过一次来实现对用户的再次访问的限制，而不在后台对数据重复请求进行验证，则可能通过这种效果实现用户对该功能的多次非法访问。
-
这种方式可能会面临哪些不适用的场景？
后台对发送的数据加以限制检查应该是破解这种手段的方法之一。【未经验证猜测】
如何进行限制检查？【未经验证猜测】
-
思考的一种解决思路是，发送请求的时候，都需要通过某种手段构造一个合法封包，需要将之前发送过的封包都识别为非法封包，这样可以使得重发送的封包无效。
但是如果实现对初次发送的封包识别为有效，重发送的封包识别为无效呢？
关键应该在于找到初次和重新发送封包的差异性。
如何让后台识别出封包是初次发送还是重新发送的呢？
-
后台每次都对发送过来的封包进行一个记录？
这种方式不太合理，考虑单个用户与应用在短时间内的交互就可能产生大量的封包请求，若用户数量增加，封包请求更大，还使用存储记录的方法就不是很合理了。更别说，所有请求都还要对比数据库中此前记录过的请求来验证是否存在然后再进行处理，这样还会极大的拖延封包的处理速度，系统的效率只会越来越低。
-
使用签名技术
在思考解决方式的时候，一直在思考有没有这样的一种签名技术，也就是单次签名。希望这个签名技术的实现效果是：“对某一内容进行签名，验证者可以验证一次，但是在验证之后这个签名就失去其作用，后续的验证都会不通过”。
询问了GPT的回复如下：
目前主流的签名技术通常都是具有持久性的，一旦签名生成，验证者可以在任何时间验证签名的有效性。然而，根据你的描述，你似乎希望一种一次性的签名技术，即在验证一次之后签名就失效。 这种需求有点不同于传统的数字签名，因为数字签名通常是用于长期验证数据的完整性和真实性。如果你想要一种一次性的签名效果，你可能需要考虑一些特殊的方法，例如基于时间或特定事件触发的签名机制。 以下是一种可能的解决方案的简要描述： 基于时间的签名： 你可以在签名时嵌入一个时间戳，并规定签名的有效期。验证者只能在规定的时间范围内验证签名，超过这个时间范围则验证失败。 事件触发的签名： 你也可以规定某个特定的事件触发签名的有效性。一旦触发了这个事件，签名就会失效。这可能需要一些外部系统或者智能合约的支持，以便在事件发生时通知验证系统。 需要注意的是，这样的一次性签名系统在实际应用中可能会面临一些复杂性和安全性的挑战。确保在设计和实现过程中充分考虑各种攻击场景和安全性需求，以防止潜在的滥用。貌似，想要实现存在验证次数的签名不太可能，想要实现验证次数的必须还是得借助于外部系统。
上面介绍的基于时间的验证稍微考虑了一下感觉也不太符合要求。
- 就比如发送封包的时候，同时附带上了时间参数，同时将其作为签名的一部分参数签名后发送，规定只有在多久之内的数据才会是有效的。那么这个时间的约束范围就很暧昧：如果时间约束过长，那么攻击者就有充足的时间去重新发送这个封包并造成威胁效果；如果时间约束过短，那么可能对用户的网络性能要求过高，如果用户的网络不佳，可能所有的正常请求都会被识别为非法请求，而让普通用户与攻击者比较竞争网络设备的性能这显然是不合理的。
-
在询问了GPT之后，给出了几种实现方式的可能
-
使用一次性令牌
在每个请求中使用一次性的令牌或 nonce（number used once）。服务器收到请求后会检查令牌是否已经使用过，如果已经使用过则拒绝请求。这样可以防止攻击者重复使用相同的请求 -
使用短暂有效的密钥
生成一次性的密钥，仅在非常短的时间窗口内有效。这样可以确保密钥的有效性受时间的限制，防止攻击者在较长时间内重复使用相同的密钥。 -
基于序列号的验证
在每个请求中包含一个递增的序列号。服务器可以维护一个记录最后处理的序列号，确保新请求的序列号大于已处理的最大序列号。这可以防止攻击者回放较旧的请求 -
应用层的挑战-应答验证
在请求中包含一个服务器生成的挑战（challenge），客户端必须正确响应该挑战才能被认为是合法请求。这种方式可以有效防范简单的重放攻击
思考了之后，觉得其中的第二点不太合理，有点类似于上面的基于时间的验证，其他的几点除了第一种方式不太了解，其他的部分都还是有点合理的。
基于序列号的验证：每次请求序列次数+1，对请求序列次数作为签名参数进行签名确保请求序列次数有效，请求序列次数不需要持久化存储，当用户断开连接之后可以清空。另一种减少请求序列数据的存储手段是，按照以天或者小时或者是一分钟作为界限，每次都清空之前的所有请求序列，重新开始新的请求序列计数。
比如当以分钟作为界限的时候，需要传送并签名的是两个数据，一个是时间，一个是请求序列。时间参数可以这样设置，2024/1/1/n，其中n是这一天的第几个分钟，然后另一个参数是请求序列。这样，服务器在接收到请求的时候首先验证时间段是否符合要求，符合要求之后再查看请求序列是否满足大于数据库里所记录的当前时段的请求序列最大值。
对于这个删除的行为，做了进一步的思考。
考虑到在每个界限的交接，不能在每个界限转变的时候就立马删除上一个时间段的所有请求序列数据，可以同时保留两个请求序列，一个是当前的，一个是上一个阶段的。每次进入下一阶段，把数据库中的“上一个阶段的请求序列数据”清空并标识为“当前请求序列数据”，把“当前阶段的请求序列数据”标识为“上一个阶段的请求序列数据”，然后将新的请求序列数据写入“当前请求序列数据”。
应用层的挑战-应答验证：相当于设置一个只有客户端应用才能回答上来的问题，当服务器收到请求之后，会针对于这个请求向客户端发起应答验证，只有客户端正确的回答上了问题，才会对这个请求进行处理。
这个应答验证需要包含一些特殊标识，保证每次的提问都是不一样的，从而杜绝收集回答的答案来进行碰撞攻击。
-
-
-
-
2836
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
