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

SSRF漏洞实战：从原理到防御的深度解析与渗透测试指南

news 2026/6/30 6:09:39

1. 项目概述：从一次内部渗透测试说起

去年，我们团队在对一个内部业务系统进行授权渗透测试时，遇到了一个典型的场景。目标是一个文件上传功能，它允许用户提供一个网络图片URL，系统会去抓取这个图片，然后压缩、打上水印，再存储到本地。听起来很平常，对吧？但就是这个看似无害的功能，让我们成功地从外网访问到了部署在内网、本不该被外部触及的Kubernetes集群元数据API，甚至差点摸到一台Redis服务器的数据。这一切的“罪魁祸首”，就是今天要深入拆解的服务器端请求伪造，也就是大家常说的SSRF。

简单来说，SSRF是一种由攻击者构造恶意请求，诱使服务器端应用向攻击者指定的内部或外部资源发起请求的安全漏洞。它的核心危害在于**“借刀杀人”**：利用受信任的服务器作为跳板，去探测或攻击其所在网络环境中的其他系统。这通常是因为应用程序在获取远程资源时，没有对用户提供的URL进行充分、严格的校验和过滤。你可能会想，这不就是个URL校验问题吗？但实战中，它的绕过技巧、利用场景和潜在危害，远比想象中复杂和深远。无论是云环境下的元数据服务、内网脆弱的数据库和缓存系统，还是各类中间件的管理接口，都可能成为SSRF攻击的“后花园”。

这篇文章，我将从一个实战渗透测试工程师的角度，不仅带你彻底理解SSRF的原理，更会结合大量真实案例和踩坑经验，详细拆解它的攻击手法、自动化探测思路、高级绕过技巧，以及真正有效的防御方案。无论你是刚入门的安全工程师、负责业务开发的程序员，还是需要评估系统风险的技术负责人，都能从中获得可直接复现的实操知识和避坑指南。

2. SSRF漏洞的核心原理与危害场景拆解

要理解SSRF，我们得先回到Web应用处理数据流的一个常见模式：服务器端出站请求。很多功能都依赖于此，例如：

数据获取：根据用户输入的URL抓取网页标题、预览图，或者获取远程API数据。
文件处理：就像开篇的例子，上传网络图片、文档。
Webhook或回调：处理第三方服务推送过来的通知，其中可能包含URL。
内部服务集成：应用需要调用同一个内网环境下的另一个服务的API。

漏洞产生的根本原因在于，应用程序过于信任用户提供的URL参数，并且发起请求的客户端（即服务器）通常拥有比普通用户更高的网络权限。它可能位于防火墙之后，可以访问内部网络段（如192.168.x.x，10.x.x.x，172.16.x.x-172.31.x.x），或者能够与云平台元数据服务（如AWS的169.254.169.254， Azure的169.254.169.254， GCP的metadata.google.internal）通信。

2.1 漏洞产生的技术根源

从代码层面看，一个存在SSRF漏洞的典型伪代码如下（以Python Flask为例）：

import requests from flask import request, jsonify @app.route('/fetch_url') def fetch_url(): url = request.args.get('url') # 直接获取用户输入的URL try: # 服务器代表用户发起请求 response = requests.get(url, timeout=5) return jsonify({'content': response.text[:500]}) # 返回部分内容 except Exception as e: return jsonify({'error': str(e)})

这段代码的问题一目了然：它直接将用户可控的url参数传递给了requests.get()，没有任何检查。攻击者可以将url参数替换为http://169.254.169.254/latest/meta-data/来尝试获取云服务器元数据。

更深层次的问题通常出现在以下几个环节：

校验逻辑缺失或薄弱：仅检查URL是否以http://或https://开头，或者用简单的正则匹配域名白名单，极易被绕过。
解析差异：应用程序代码、底层网络库（如libcurl）、后端服务（如ImageMagick）对URL的解析规则可能存在差异，导致黑名单过滤失效。
重定向跟随：服务器自动跟随HTTP 3xx重定向，而重定向的目标地址可能指向内网。
非HTTP/HTTPS协议支持：某些网络库支持file://、gopher://、dict://等协议，可能用于读取本地文件或与其他服务交互。

2.2 核心危害场景深度分析

SSRF的危害绝不仅仅是“读个数据”那么简单，它的攻击面可以非常广：

场景一：攻击云上元数据服务这是云环境下最高危的场景之一。几乎所有主流云厂商（AWS, Azure, GCP, Alibaba Cloud, Tencent Cloud等）都为虚拟机实例提供了一个特殊的、只能从实例内部访问的元数据服务端点（如169.254.169.254）。通过SSRF访问这些端点，攻击者可能获取到：

临时安全凭证：用于访问云API的Access Key和Secret Key，可能导致整个云账户沦陷。
实例身份信息：包括实例ID、区域、IP等。
用户数据：实例启动时传入的脚本或配置信息，可能包含敏感密码。

实操心得：在测试云上应用时，将169.254.169.254及其路径（如/latest/meta-data/，/latest/user-data）作为SSRF测试的必选项。同时注意，不同云厂商或同一厂商的不同服务，元数据端点可能有细微差别，需要积累自己的测试字典。

场景二：探测与攻击内网服务服务器通常有权访问整个内部网络。通过SSRF，攻击者可以：

端口扫描：通过判断请求的响应时间、错误信息或响应内容，来探测内网IP的哪些端口是开放的。例如，尝试请求http://192.168.1.1:22，如果连接超时或快速被拒，可能是端口关闭或过滤；如果返回特定的协议横幅（如SSH的SSH-2.0-OpenSSH），则证明端口开放。
攻击脆弱服务：直接与内网中存在的未授权访问或弱口令服务交互。例如：
- 攻击Redis：使用dict://协议或HTTP协议构造特定Payload执行命令。
- 攻击Memcached：通过UDP协议（如果支持）进行数据检索或注入。
- 攻击数据库：尝试连接内网的MySQL、MongoDB等。
- 攻击管理后台：访问Jenkins、Docker Registry、Consul、Nacos等服务的未授权管理界面。

场景三：绕过访问控制与身份认证有些内部服务的设计假设是“只有内网可访问，所以是安全的”，因此缺乏强认证。SSRF使得外部攻击者可以绕过网络层的ACL（访问控制列表），直接以服务器身份与这些服务对话。此外，如果服务器发起的请求会携带某些认证头（如X-Forwarded-For，或者用于内网服务间认证的JWT Token），攻击者可能间接利用这些凭证。

场景四：作为其他漏洞的跳板SSRF常常与其他漏洞形成“组合拳”：

与XXE结合：如果应用处理XML时存在XXE漏洞，且允许外部实体，那么通过加载外部实体的方式，可能将XXE转化为SSRF。
与文件上传结合：上传功能允许指定远程URL，可能触发服务器端请求。
与反序列化结合：某些反序列化漏洞在利用时，Payload中可能包含发起网络请求的类，从而触发SSRF。

3. 实战探测：手动与自动化方法详解

发现SSRF漏洞，需要敏锐的观察力和系统性的测试方法。它不像SQL注入有那么多自动化工具有效，更多依赖于对功能点的理解和手工测试。

3.1 功能点识别与手动测试

首先，你需要找到所有可能触发服务器出站请求的功能点。我通常会关注以下参数和功能：

参数名：url，link，path，file，src，image，api，endpoint，callback，feed，proxy等。
功能点：
- 头像/图片上传（支持网络URL）。
- 文档导入（支持从URL导入）。
- 网页预览/快照生成。
- OAuth授权回调（state或redirect_uri参数可能被滥用）。
- 数据采集/爬虫功能。
- PDF生成（服务端可能去获取HTML中的外部资源）。
- SSO单点登录中的某些参数。
- 任何提及“获取远程内容”、“调用外部API”的地方。

手动测试时，我习惯准备一个“测试服务器”，它有两个核心作用：

接收请求日志：查看服务器是否真的向我的指定地址发起了请求。
返回可控响应：用于测试盲SSRF（无回显）或进行重定向攻击。

最方便的工具是Burp Suite Collaborator或者自建一个带有公网IP的简易HTTP服务（用Python的http.server或nc -lvnp 80）。测试步骤：

基础探测：将参数值替换为你的测试服务器地址，如http://your-domain.burpcollaborator.net。观察测试服务器是否收到HTTP请求。请求中可能包含User-Agent、Via、X-Forwarded-For等头，这些信息有助于判断服务器使用的网络库。
协议探测：尝试不同的协议，如https://，file:///etc/passwd，dict://attacker:6379/info，gopher://your-server:80/_...。观察服务器的处理行为（是报错、返回内容，还是没有任何反应？）。
内网探测：如果确定存在SSRF，开始系统性地探测内网。使用Burp的Intruder模块，载入内网IP段（如192.168.0.0/24）和常见端口（80， 443， 22， 21， 3306， 6379， 8080等）的组合字典进行爆破。重点观察响应时间、长度和状态码的差异。
元数据端点探测：直接请求云元数据地址。对于盲SSRF，可以尝试让元数据服务将数据回传到你的测试服务器（例如，在某些云环境中，可以通过User-Data执行脚本将数据外带）。

3.2 自动化工具与技巧

完全依赖手动测试效率较低，我会结合一些半自动化的方法：

Burp Suite 插件：Collaborator Everywhere插件可以自动将浏览流量中的潜在参数替换为Collaborator地址，非常适合在被动扫描时发现SSRF点。SSRF Scanner等主动扫描插件也能提供一些帮助，但误报率需要人工复核。
自定义脚本：对于需要深度测试的目标，我会编写Python脚本。脚本的核心逻辑是：从Burp导出的请求中，自动识别和替换可能的URL参数，然后发送到测试服务器，并记录日志。同时，脚本可以集成内网端口扫描的逻辑。
流量分析：在测试过程中，密切监控服务器本身的出站流量（如果有权限）。有时应用可能请求失败，但在服务器日志或网络流量中留下了痕迹，这也能证明漏洞存在。

注意事项：自动化探测内网时，务必控制速率和并发，避免对目标内网服务造成拒绝服务攻击（DoS）。在授权测试中，这也是需要明确约定的规则。我通常将线程数控制在5以下，并在请求间添加随机延迟。

4. 高级绕过技巧与利用链构造

当你的测试请求被简单的黑名单或白名单拦截时，真正的挑战才开始。SSRF的绕过技巧五花八门，核心思路是利用URL解析的歧义性和校验与请求执行环节的不一致。

4.1 针对黑名单的绕过

假设应用禁止访问localhost，127.0.0.1，169.254.169.254等。

使用非常规IP表示法：
- 十进制IP：http://2130706433/(127.0.0.1的十进制表示)。
- 八进制IP：http://0177.0.0.1/或http://017700000001/(127.0.0.1的八进制)。
- 十六进制IP：http://0x7f000001/(127.0.0.1的十六进制)。
- 省略格式：http://127.1/，http://127.0.1/。
- IPv6地址：http://[::1]/(localhost的IPv6)，或者IPv6的压缩格式、嵌入IPv4的格式。
利用URL解析差异：
- 添加端口：http://127.0.0.1:80/可能绕过对127.0.0.1的字符串匹配。
- 利用@符号：http://expected-domain.com@malicious-domain.com。某些解析器会将@前的内容视为认证信息，实际请求的是malicious-domain.com。但现代浏览器和很多库已经能正确警告或处理，不过在服务端解析时仍可能有效。
- 利用#符号：http://malicious-domain.com#expected-domain.com。部分解析器会将#后的内容视为片段，不发送到服务器。但校验逻辑可能在客户端（JavaScript），而服务端库（如curl）会忽略片段，直接请求malicious-domain.com。
- 利用?和&：http://expected-domain.com?redirect=malicious-domain.com。如果校验只检查主机名部分，可能会通过。
域名重绑定攻击：这是对付IP黑名单的“杀手锏”。原理是：你提供一个域名，该域名在DNS查询时，第一次返回一个合法的、在白名单内的IP地址（通过很短的TTL实现），让服务器的校验逻辑通过。紧接着，该域名迅速指向你真正想攻击的内网IP（如127.0.0.1）。由于服务器可能在校验后、实际发起请求前不进行第二次DNS解析（或使用了DNS缓存），就会请求到内网地址。实施此攻击需要你能控制一个域名并设置极短的TTL，或者使用现成的重绑定服务（如rbndr.us）。

4.2 针对白名单的绕过

如果应用只允许访问特定的域名（如api.trusted.com），难度更大，但仍有思路：

子域名接管：检查白名单域名是否存在未使用的子域名（如assets.api.trusted.com），并且该子域名的CNAME记录指向一个你可控的服务（如失效的云存储、CDN）。如果存在，你可以接管这个子域名，从而进入白名单。
利用解析重定向：让白名单域名下的某个路径（如api.trusted.com/redirect?url=internal-ip）返回一个302重定向，指向内网地址。如果服务器跟随重定向，就能达成攻击。
利用服务端请求的“跟随”特性：有些服务端请求库在遇到3xx状态码时会自动跟随重定向。你可以构造一个白名单域名的URL，该URL的响应头中包含Location: http://169.254.169.254/latest/meta-data/。
XSS与SSRF结合：如果白名单域名下的应用存在XSS漏洞，你可以通过XSS动态修改页面内容或发起请求，但这种方式通常受同源策略限制，较难利用。

4.3 利用链构造实例：从SSRF到Redis未授权访问

假设我们通过一个图片上传的SSRF，发现内网192.168.2.10的6379端口开放，且是Redis未授权访问。如何利用？

确认漏洞：首先，通过SSRF探测dict://192.168.2.10:6379/info，如果返回Redis版本信息，则确认存在未授权访问。
写入WebShell（如果Redis所在服务器同时运行Web服务）：
- 我们需要将Redis命令转换成可被HTTP协议发送的格式。可以使用Gopher协议，但很多现代库不支持。更通用的方法是，如果SSRF点支持发送POST数据，我们可以尝试构造HTTP请求包，其Body部分就是Redis命令。
- 例如，我们可以让服务器向http://192.168.2.10:6379发起一个POST请求，Body为：
```
flushall set shell "<?php @eval($_POST['cmd']);?>" config set dir /var/www/html config set dbfilename shell.php save
```
- 但这需要Redis能够解析HTTP请求并将其误认为Redis协议，这通常不行。更可靠的方法是，如果存在一个能向Redis发送原始TCP数据的服务端漏洞（比如某些CRLF注入点），可以结合使用。否则，这个利用链可能中断。
写入SSH公钥：
- 如果知道目标服务器运行了SSH服务，并且Redis运行用户有写~/.ssh/authorized_keys的权限，可以通过Redis写入SSH公钥。
- 利用SSRF执行Redis命令的难点同上。一种可行的思路是，如果SSRF点允许使用file://协议，并且可以控制请求的部分内容，或许能构造出攻击载荷，但这非常依赖具体环境。
主从复制RCE：这是近年来更流行的利用方式。攻击者在自己控制的服务器上运行一个恶意的Redis实例（作为从机），然后通过SSRF，让目标Redis（作为主机）执行SLAVEOF命令指向攻击者的服务器。攻击者的恶意Redis会发送一个包含恶意模块的备份文件，最终在目标Redis上加载并执行任意代码。这需要SSRF能够发送完整的Redis命令，同样面临协议转换的难题。

关键在于：单纯的SSRF可能只能读取Redis的info信息。要实现RCE，往往需要结合其他漏洞，或者SSRF点对协议和请求的控制粒度非常细。在实际渗透中，读取敏感信息（如Redis中的缓存会话、用户数据）已经是重大危害。

5. 防御体系构建：从代码到架构的纵深防护

防御SSRF需要一个多层次、纵深防御的体系，单一措施很容易被绕过。

5.1 输入校验与过滤（网络层）

这是第一道，也是必须要有的一道防线，但绝不能是唯一一道。

建立严格的白名单：如果业务只允许访问少数几个固定的外部服务，那么建立域名或IP白名单是最有效的方法。校验时，使用权威的URL解析库（如Python的urllib.parse， Java的java.net.URI）提取主机名或IP，并与白名单比对。
禁用不必要的URL协议：只允许http://和https://，明确禁用file://，gopher://，dict://，ftp://等危险协议。
解析并校验IP地址：
- 将主机名解析为IP地址（注意DNS重绑定风险，需要在解析后立即校验）。
- 检查解析出的IP是否属于内网地址段或回环地址。需要屏蔽的段包括：
  - IPv4:127.0.0.0/8，10.0.0.0/8，172.16.0.0/12，192.168.0.0/16，169.254.0.0/16(链路本地)，0.0.0.0/8。
  - IPv6:::1/128(localhost)，fc00::/7(唯一本地地址)，fe80::/10(链路本地地址)。
- 注意，还要屏蔽云厂商的元数据服务IP（如169.254.169.254）。
小心处理重定向：配置HTTP客户端不自动跟随重定向，或者至少在白名单校验后再跟随一次重定向（即对重定向后的目标URL再次进行白名单校验）。

5.2 应用层与网络层隔离

使用独立的出站代理或网关：所有需要出站请求的服务，不直接发起请求，而是统一发送到一个受控的代理服务或API网关。这个代理服务负责实施严格的URL校验策略、速率限制、日志记录和审计。即使业务代码有疏漏，代理层也能提供保护。
为后端服务设置独立的网络策略：在云环境或容器编排平台（如Kubernetes）中，通过安全组、网络策略（Network Policies）或服务网格（如Istio）的规则，严格限制应用Pod或虚拟机实例的出站流量。例如，只允许其访问必要的数据库、缓存和少数几个外部API的特定端口，明确拒绝访问元数据服务地址和内网其他网段。
使用虚拟私有云（VPC）端点：对于AWS等云服务，使用VPC端点访问云服务（如S3， DynamoDB），避免流量经过公网，也减少了攻击面。

5.3 代码安全实践

使用安全的网络库并正确配置：避免使用低层级的、功能过于强大的网络库。使用高级别的、有良好安全默认值的HTTP客户端（如Python的requestswithallow_redirects=Falseinitially）。对于curl命令，避免使用-L（跟随重定向）和-k（忽略SSL证书验证）等危险参数。
实施最小权限原则：运行应用程序的操作系统用户应具有尽可能少的权限。避免以root身份运行，这样即使攻击者通过SSRF执行了命令，危害也相对有限。
对返回内容进行安全处理：即使请求了外部资源，对返回的内容也要视为不可信的。例如，从URL获取的图片，应该进行重采样、格式转换等处理，而不是直接存储或展示，以防图片中包含恶意代码（如图片隐写Webshell）。

5.4 运营与监控

详细的日志记录：记录所有出站请求的详细信息，包括源IP、目标URL、时间戳、响应状态码和大小。这些日志是事后调查和攻击检测的关键。
部署网络入侵检测系统（NIDS）：在内网边界部署如Suricata、Zeek等工具，设置规则检测从服务器区域发往元数据服务或扫描内网的大量异常请求。
定期安全测试：将SSRF作为渗透测试和代码审计的必查项。使用自动化工具（如静态代码分析工具SAST）扫描代码中是否存在不安全的URL获取和请求模式。

6. 常见问题排查与疑难场景处置

在实际开发和渗透测试中，你会遇到各种奇怪的现象。这里记录一些我踩过的坑和解决方法。

问题1：测试时，我的Burp Collaborator收到了DNS查询，但没有收到HTTP请求，这是SSRF吗？

这很可能是一个盲SSRF。服务器发起了DNS解析，但在建立TCP连接或发送HTTP请求时失败了。可能的原因有：

目标服务器防火墙或安全组阻止了出站流量到你的Collaborator端口。
应用程序的网络库在解析DNS后，进行了IP黑名单校验，发现你的Collaborator IP不在白名单内，中断了请求。
请求使用了非HTTP协议，而Collaborator只记录HTTP/HTTPS。
排查技巧：尝试使用不同的端口（如53-DNS， 80-HTTP， 443-HTTPS）。同时，检查应用程序的错误响应，有时超时或连接拒绝的错误信息会略有不同。对于盲SSRF，重点转向如何将数据“带出来”，例如尝试让服务器访问一个会返回长延迟或特定错误页面的URL，通过响应时间的差异来判断后端行为（时间盲注）。

问题2：我确认存在SSRF，可以访问http://169.254.169.254，但返回403 Forbidden或404 Not Found。

这并不意味着漏洞不存在或无法利用。云元数据服务通常有多级路径，并且访问某些路径可能需要特定的HTTP头（如X-aws-ec2-metadata-token， AWS IMDSv2）。你需要系统地枚举路径。

方法：使用目录爆破工具（如ffuf，gobuster）搭配常见的元数据路径字典进行扫描。字典应包含如/latest/meta-data/，/latest/user-data，/1.0/meta-data/等路径。同时，尝试添加或修改HTTP头，例如Metadata: true或X-Forwarded-For: 169.254.169.254。

问题3：在测试内网端口时，如何区分端口开放、关闭和被防火墙过滤？

这是内网探测的精髓，主要依靠响应差异：

连接超时（Timeout）：很可能端口被防火墙过滤，或者主机不存在。
连接被拒绝（Connection Refused）：通常意味着端口是关闭的，没有服务监听。
成功连接并收到数据：端口开放，并且服务有响应。响应内容（Banner）能告诉你是什么服务。
成功连接但立即断开：端口可能开放，但服务可能因为协议不匹配（比如你发HTTP请求到SSH端口）而断开连接。
实操技巧：编写脚本时，不仅要检查是否收到响应，还要记录TCP握手时间。被过滤的端口超时时间通常很长（如数秒），而“连接被拒绝”的响应非常快（毫秒级）。

问题4：防御代码中，我已经校验了IP不是内网，为什么还能被绕过？

最常见的原因是校验与请求执行环节不一致。

场景：应用代码用正则检查URL中是否包含192.168，但后端使用的ImageMagick在读取图片时，支持http://some-domain.com/red.png?foo=192.168.1.1这样的格式，它可能会将整个URL作为文件名处理，或者其网络库的解析逻辑不同。
场景：应用代码解析了URL的主机名，但攻击者使用http://127.0.0.1:80@evil.com/这样的格式，某些旧版库可能会将127.0.0.1:80视为认证信息，实际连接evil.com。
解决方案：确保校验逻辑在请求发起的最底层、最权威的环节执行。最好使用一个统一的、经过安全审计的网络请求工具类，所有出站请求都必须通过它，并在该类中实施最终的校验。

问题5：在Kubernetes环境中，除了云元数据，还有什么特别的SSRF风险点？

Kubernetes环境引入了新的攻击面：

Kubernetes API Server：默认情况下，Pod内的应用可以通过https://kubernetes.default.svc访问API Server，并且带有一个默认的Service Account Token。如果应用存在SSRF，攻击者可能利用这个Token来操作集群资源（如列出Secret、创建Pod）。防御方法是使用最小权限原则，为Pod配置automountServiceAccountToken: false或绑定权限更低的Role。
Pod Service：同一集群内的Pod可以通过Service域名互访。SSRF可能用于攻击集群内其他脆弱的服务。
节点网络：某些Pod配置了hostNetwork: true，它们共享节点的网络命名空间，可以直接访问节点的服务（包括元数据服务）。需要避免不必要的hostNetwork配置。

7. 工具链与资源推荐

工欲善其事，必先利其器。以下是我在挖掘和防御SSRF时常用的工具和资源，它们能极大提升效率。

探测与利用工具：

Burp Suite Professional：核心工具。Collaborator功能无可替代，Intruder用于端口爆破，Scanner也能检测一些简单的SSRF。
ffuf / gobuster：用于目录/路径爆破，在枚举元数据服务路径时非常高效。
SSRFmap：一个自动化的SSRF测试与利用工具，内置了很多Payload和利用链，适合在确认漏洞后进行深度利用测试。
Gopherus：专门生成用于攻击Redis、MySQL等服务的Gopher协议Payload的工具。
DNSBin/Interact.sh：类似于Burp Collaborator的公共服务，用于接收带外数据，适合没有Burp专业版时使用。

防御与检测资源：

OWASP SSRF Cheat Sheet：防御指南的权威参考。
各云厂商关于元数据服务安全的官方文档：了解如何禁用或加固元数据服务访问（如AWS IMDSv2）。
Semgrep/CodeQL：用于在代码中搜索不安全的URL获取模式（如requests.get(user_input)）的SAST工具。

练习靶场：

PortSwigger Web Security Academy (Labs)：提供从基础到高级的SSRF实验场景，非常适合入门和巩固。
HackTheBox/TryHackMe：某些机器或房间以SSRF为核心攻击链，提供了真实的演练环境。
Vulnhub：一些虚拟机镜像也包含了SSRF的挑战。

最后，我想强调的是，SSRF的攻防是一场关于“信任边界”的博弈。作为开发者，必须时刻牢记“服务器发起的请求也是不可信的输入源”；作为安全人员，则需要深刻理解应用架构、网络协议和各类解析器的微妙差异。这个漏洞不会消失，只会随着技术架构的演进，以新的形式出现。保持好奇心，持续学习各种绕过技巧和防御方案，是应对它的唯一方法。在我自己的渗透测试项目中，每当看到一个服务器端请求功能，都会条件反射般地思考：它的校验到底有多严？我能不能骗过它？这种思维习惯，或许就是安全从业者最重要的资产之一。

查看全文

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