作者： admin

发布于

API Token 提取与会话劫持 (Session Hijacking)：如何在流量中识别和提取会话令牌？

嘿，大家好！今天咱们来聊点刺激的——API Token 提取与会话劫持，保证让你听完冷汗直冒，然后默默地检查自己的代码和网络配置。 开场白：令牌的诱惑 想象一下，你是一家银行的安全主管，你的任务是保护用户的银行账户。 用户的账户密码就相当于银行金库的钥匙，非常重要！ 那么token是什么呢？ token 就相当于用户进入银行大厅后，保安发给你的一个临时通行证，有了这个通行证，你就可以在银行大厅里办理各种业务，而不需要每次都出示你的“钥匙”（账户密码）。 API Token 和 Session Token 就像互联网世界的通行证，它们允许用户在一段时间内访问受保护的资源，而无需重复验证身份。但如果这些通行证落入坏人之手，那可就惨了。 第一部分：API Token 的那些事儿 API Token 是一种用于身份验证的字符串，通常由服务器生成并颁发给客户端。客户端在后续的请求中携带这个 Token，服务器通过验证 Token 来确认客户端的身份。 Token 的类型 Bearer Token: 最常见的类型，通常在 HTTP 请求头的 Authorization 字段中携带，格式为 Auth …

继续阅读“API Token 提取与会话劫持 (Session Hijacking)：如何在流量中识别和提取会话令牌？”

发布于

请求混淆 (Request Obfuscation)：如何通过自定义编码、请求头伪造等方式混淆 HTTP 请求，以逃避检测？

各位靓仔靓女们，晚上好！我是今晚的讲师，咱们今晚来聊点刺激的——HTTP请求混淆。听说过吗？就是把你的HTTP请求乔装打扮一下，让那些“火眼金睛”的检测系统认不出来，从而达到一些……嗯，不可告人的目的。（当然，我们只是学习技术，不要干坏事哦！） 咱们今天就来好好扒一扒，怎么通过各种骚操作，把HTTP请求变成一个“百变怪”，让它看起来像模像样，但实际上却暗藏玄机。 一、啥是请求混淆？为啥要搞它？ 简单来说，请求混淆就是通过各种技术手段，改变HTTP请求的结构或内容，使得它看起来和正常的请求不太一样。 为啥要搞它呢？原因有很多： 绕过WAF (Web Application Firewall) 和 IDS (Intrusion Detection System)： 这些安全设备会根据HTTP请求的特征来判断是否存在恶意攻击。如果我们能把请求伪装得不像攻击，就能成功绕过它们。 逃避审计和监控： 有时候，我们需要隐藏我们的真实行为，防止被记录或跟踪。 测试安全性： 请求混淆也是渗透测试中常用的手段，可以用来测试目标系统的安全性。 但是！记住！我们学习请求混淆是为了更好地保护自己，而不是去搞破坏 …

继续阅读“请求混淆 (Request Obfuscation)：如何通过自定义编码、请求头伪造等方式混淆 HTTP 请求，以逃避检测？”

发布于

Proxy Server 配置：如何配置一个能拦截 WebSocket 和 HTTP/2 流量的透明代理？

各位听众，大家好！今天咱们来聊聊代理服务器那些事儿，特别是怎么配置一个能“偷窥” WebSocket 和 HTTP/2 流量的透明代理。别害怕，我说的“偷窥”是指技术上的流量分析，不是真的让你去干坏事儿啊！ 咱们的目标是，让用户毫无察觉的情况下，他们的 WebSocket 和 HTTP/2 流量经过我们的代理服务器，并且我们可以抓取这些流量进行分析、修改，或者做其他你想做的事情。 开场白：代理服务器的“前世今生” 代理服务器，简单来说，就像一个中间人。你的电脑（客户端）想访问某个网站，不是直接去访问，而是先找到这个中间人，告诉它：“嘿，帮我看看这个网站”，然后中间人再去访问网站，把结果拿回来给你。 传统的代理服务器，需要你在浏览器或者操作系统里设置代理地址和端口。而咱们今天要讲的“透明代理”，就厉害了，它不需要用户做任何设置，流量会自动跑到代理服务器来。 第一幕：为什么要“偷窥” WebSocket 和 HTTP/2？ 你可能会问，HTTP/1.1 不是已经够用了吗？WebSocket 和 HTTP/2 到底有什么特别的，值得我们费这么大劲去“偷窥”呢？ WebSocket： 传统的 …

继续阅读“Proxy Server 配置：如何配置一个能拦截 WebSocket 和 HTTP/2 流量的透明代理？”

发布于

WebTransport (HTTP/3 基于 QUIC) 流量分析：如何解密 QUIC 连接并分析其上的 WebTransport 协议数据？

各位观众老爷，大家好！我是今天的主讲人，咱们今天聊点刺激的，聊聊如何扒掉 WebTransport 的“底裤”，看看它到底在干些啥！当然，这里说的“底裤”指的是 QUIC 连接加密，我们要做的是合法合规的流量分析。 WebTransport 可是个好东西，它基于 HTTP/3 和 QUIC，能提供低延迟、可靠、双向的通信通道，特别适合实时应用。但就像所有网络协议一样，我们需要理解它的工作方式，才能更好地开发、调试和安全审计。 QUIC：WebTransport 的坚实后盾 首先，得说说 QUIC。QUIC 可以看作是 TCP + TLS + HTTP/2 的合体加强版，解决了 TCP 的队头阻塞、握手延迟等问题。它使用 UDP 作为传输层协议，内置了加密和拥塞控制机制。 解密 QUIC 连接：拿到钥匙是关键 QUIC 协议默认是加密的，所以直接抓包看到的都是加密数据，没法直接分析 WebTransport 的内容。要解密 QUIC 连接，我们需要拿到会话密钥。通常有两种方法： 预共享密钥 (Pre-Shared Key, PSK)： 如果 WebTransport 应用使用了预共享密钥 …

继续阅读“WebTransport (HTTP/3 基于 QUIC) 流量分析：如何解密 QUIC 连接并分析其上的 WebTransport 协议数据？”

发布于

gRPC-Web 流量解密与协议逆向：如何从 Protobuf 编码的 gRPC-Web 请求中提取有效负载？

各位观众老爷，大家好！今天咱们来聊聊 gRPC-Web 的那些事儿，尤其是关于如何扒开它的外衣，看看里面到底装了些啥。如果你曾经被 gRPC-Web 搞得头晕脑胀，不知道怎么解密它的流量，逆向它的协议，那这篇文章绝对能帮到你。 前言：啥是 gRPC-Web？ 简单来说，gRPC-Web 就是 gRPC 的一个变种，专门为浏览器环境量身定制。由于浏览器天然的限制，无法直接使用标准的 gRPC 协议，所以 Google 大佬们搞出了 gRPC-Web 这么个东西。它通过一个 Envoy 之类的代理服务器，将浏览器发出的 HTTP/1.1 请求转换成标准的 gRPC 请求，然后再发送给后端的 gRPC 服务。 一、为什么要解密 gRPC-Web 流量？ 你可能会问，好好的流量，干嘛要解密？原因有很多： 调试： 当你的前端和后端联调出现问题时，解密流量可以让你清晰地看到客户端发了什么，服务端回了什么，从而快速定位问题。 安全分析： 如果你需要分析 gRPC-Web 应用的安全性，解密流量是必不可少的。你可以检查客户端是否发送了敏感信息，服务端是否返回了不安全的数据等等。 协议逆向： 假设你想要 …

继续阅读“gRPC-Web 流量解密与协议逆向：如何从 Protobuf 编码的 gRPC-Web 请求中提取有效负载？”

发布于

HTTP/2 Frame 解析：如何从原始二进制流中提取 HEADERS, DATA, SETTINGS 等帧，并对其进行篡改？

HTTP/2 帧解析与篡改：一场二进制世界的探险 大家好，我是你们今天的导游，带大家深入HTTP/2的二进制丛林，一起探险帧（Frame）的秘密，并学习如何成为一位“帧”的艺术家，创造性地修改它们。 首先，我们得明确一点：HTTP/2 帧是HTTP/2通信的基石。所有的数据，包括请求头、响应体，甚至连接控制信息，都被封装在帧中进行传输。理解帧的结构，就等于掌握了HTTP/2的命脉。 HTTP/2 帧结构：拆开“乐高玩具” HTTP/2 帧由以下几个关键部分组成，可以想象成一个精心设计的“乐高玩具”： 字段名称 长度 (bytes) 描述 Length 3 帧负载的长度，不包括帧头（Length 和 Type，Flags，R）。最大值为 2^24 – 1 (16,777,215)。 Type 1 帧的类型，决定了帧的含义。例如，HEADERS、DATA、SETTINGS 等。 Flags 1 帧的标志位，用于指示帧的特定属性。不同的帧类型有不同的标志位定义。 R 1 保留位，必须设置为 0。 （虽然这个字段没什么实际用处，但也不能忽略它，毕竟它也是帧结构的一部分。） Stre …

继续阅读“HTTP/2 Frame 解析：如何从原始二进制流中提取 HEADERS, DATA, SETTINGS 等帧，并对其进行篡改？”

发布于

WebSocket 协议的帧结构和 Masking (掩码) 机制是什么？如何对其进行流量解密和数据包篡改？

各位老铁，早上好！今天咱就来聊聊 WebSocket 协议里那些弯弯绕绕的东西，尤其是它的帧结构和 Masking (掩码) 机制。我会像唠嗑一样，把这个听起来高大上的东西给你们扒个精光，让你们不仅能看懂，还能动手玩起来，甚至能搞点“小破坏”（当然，仅限于学习研究啊！）。 WebSocket 帧结构：拆解“快递包裹” WebSocket 协议就像一个高效的快递系统，它把数据分成一个个“包裹”（帧）来传输。每个“包裹”都有自己的格式，我们得先了解这些格式，才能知道里面装的是啥。 WebSocket 帧的基本结构如下： 0 1 2 3 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 +-+-+-+-+——-+-+————-+——————————-+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V| …

继续阅读“WebSocket 协议的帧结构和 Masking (掩码) 机制是什么？如何对其进行流量解密和数据包篡改？”

发布于

HTTPS SSL/TLS 流量解密中，如何在没有服务器私钥的情况下，通过 MITM (中间人攻击) 工具进行解密和篡改？

各位观众，大家好！我是今天的讲师，很高兴能和大家一起聊聊一个稍微有点“危险”的话题：在没有服务器私钥的情况下，如何通过MITM（中间人攻击）工具解密和篡改HTTPS SSL/TLS流量。 不过，在开始之前，我要郑重声明：本文仅供技术学习和安全研究之用，请勿用于非法用途。任何滥用本文知识造成的后果，由使用者自行承担。 好了，声明完毕，咱们开始“飙车”吧！ 一、HTTPS 协议的简单回顾： 首先，我们需要简单回顾一下HTTPS协议的核心原理。HTTPS实际上就是HTTP over SSL/TLS，它通过SSL/TLS协议对HTTP数据进行加密，保证数据在传输过程中的安全性。这个加密的核心就是公钥/私钥体系。 简单来说： 服务器拥有私钥（Server Private Key）： 只有服务器才能持有，用于解密客户端发送的加密数据以及对服务器发送的数据进行签名。 服务器拥有公钥（Server Public Key）： 公开给客户端，用于客户端加密数据并验证服务器的身份。 客户端拥有随机生成的对称密钥（Session Key）： 用于加密客户端和服务器之间后续的通信数据，由客户端生成并使用服务器的 …

继续阅读“HTTPS SSL/TLS 流量解密中，如何在没有服务器私钥的情况下，通过 MITM (中间人攻击) 工具进行解密和篡改？”

发布于

HTTPS SSL Pinning (SSL证书锁定) 绕过：如何通过修改应用、操作系统或网络流量来绕过证书锁定？

各位观众老爷们，大家好！我是今天的主讲人，一个在代码堆里摸爬滚打多年的老码农。今天咱们来聊点刺激的——HTTPS SSL Pinning的绕过。 首先声明，咱们今天讨论的是技术，目的是了解安全机制，不是教唆大家去干坏事！学技术是为了更好的保护自己，可别用来搞破坏啊！ SSL Pinning 是个啥？ 简单来说，SSL Pinning就像给你的App加了个“白名单”。它会把服务器的SSL证书（或者证书的公钥、哈希）直接“钉”在你的App代码里。这样，App只会信任与这个“白名单”里的证书匹配的服务器。 为啥要这么做呢？因为普通的HTTPS连接，App会信任任何经过可信CA（证书颁发机构）签发的证书。但CA也可能被攻破，或者被某些邪恶势力控制，从而签发假的证书。有了Pinning，即使CA被攻破，攻击者也无法用假证书欺骗你的App。 绕过Pinning，为啥这么难？ Pinning把信任锚点从整个CA体系缩小到了特定的证书，大大提高了安全性。想要绕过它，意味着你需要找到方法让App信任一个非“白名单”里的证书，或者直接修改App的行为，让它忽略Pinning的检查。 那么，如何“优雅”地绕 …

继续阅读“HTTPS SSL Pinning (SSL证书锁定) 绕过：如何通过修改应用、操作系统或网络流量来绕过证书锁定？”

发布于

Subresource Integrity (SRI) 在保护第三方脚本完整性方面的局限性是什么？如何绕过它？

各位观众，晚上好！欢迎来到今天的“前端安全大作战”特别节目。我是你们的老朋友，bug终结者，今天咱们聊聊Subresource Integrity (SRI) 这玩意儿，看看它是不是真的那么靠谱，以及有哪些“不听话”的地方，还有那些“心怀不轨”的家伙是怎么绕过它的。 开场白：SRI，你的盾牌够硬吗？ 话说江湖上流传着一种叫做SRI的“神功”，据说能保护咱们的前端代码不被第三方CDN的坏人篡改。听起来是不是很厉害？就像给你的网页穿上了一层金钟罩铁布衫，刀枪不入。 但，等等！武侠小说里都说了，没有绝对的防御。再厉害的盾牌，也总有弱点。今天咱们就来扒一扒SRI的底裤，看看它到底有哪些局限性，又有哪些方法能绕过它，当然，我们学习这些是为了更好地保护我们的代码，而不是去干坏事啊！ 第一幕：SRI的基本原理，知己知彼 要想知道SRI的局限性，咱们得先了解它是个什么玩意儿。简单来说，SRI就是给你的外部资源（比如CDN上的JavaScript、CSS文件）生成一个唯一的“指纹”——哈希值。当浏览器加载这些资源的时候，会拿下载下来的文件的哈希值和你事先提供的哈希值进行比对。如果不一样，那就说明这个文件 …

继续阅读“Subresource Integrity (SRI) 在保护第三方脚本完整性方面的局限性是什么？如何绕过它？”