原生态的意思就是说你不知道对方的源码也不知道对方的具体信息，只有一个上传点在那里测。
你要满足三个条件
①有重命名的东西*（几乎不可能）
②有文件上传
③版本符合
原理：Apache HTTPD 换行解析漏洞（CVE-2017-15715）的产生原理源于 Apache 配置文件中错误的正则表达式匹配逻辑，结合 HTTP 协议和服务器解析机制的特性，具体可拆解为以下技术细节：
一、核心配置：正则表达式的"$"符号误用
在 Apache HTTP Server 2.4.0~2.4.29 版本中，默认配置文件（如 docker-php.conf ）使用了如下正则表达式匹配 PHP 文件：
apache
<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>
-
正则含义： \.php 本意是匹配以 .php 结尾的文件名（ 表示字符串末尾）。
-
漏洞关键：Apache 在处理该正则时，错误地启用了正则表达式的 Multiline 模式（ /m 修饰符）。在 Multiline 模式下， $ 不仅匹配字符串末尾，还会匹配换行符（ \n 或 \r ）。
二、换行符（ %0A ）的绕过逻辑
HTTP 协议中，文件名可以通过 URL 编码包含特殊字符。攻击者利用这一特性构造恶意文件名：
-
构造恶意文件名：将文件名设置为 1.php%0A （ %0A 是换行符 \n 的 URL 编码）。
-
绕过扩展名检查：服务器端的文件上传逻辑通常会检查扩展名是否为 .php ，但 1.php%0A 的扩展名被识别为 .php （因为 %0A 是不可见字符，容易被忽略）。
-
Apache 错误解析：当请求到达 Apache 时， FilesMatch \.php 的正则匹配逻辑会将 1.php%0A 中的 %0A 视为换行符，触发 Multiline 模式下的 匹配。因此， 1.php%0A 会被判定为符合 .php$ 的匹配规则，从而被交给 mod_php 模块解析执行。
三、攻击场景：文件上传漏洞的利用
该漏洞常与文件上传功能结合，形成完整攻击链：
-
上传恶意文件：攻击者通过文件上传接口，上传名为 webshell.php%0A 的文件（实际内容为 PHP 木马，如 GIF89a<?php eval($_POST['pass']);?> ）。
-
绕过前端验证：若服务器端仅检查扩展名是否为 .php ， webshell.php%0A 会被误认为是合法文件（扩展名看似 .php ）。
-
服务器解析执行：Apache 错误地将 webshell.php%0A 解析为 PHP 文件，执行其中的恶意代码，攻击者可通过蚁剑等工具连接控制服务器。
四、漏洞修复原理
Apache 在 2.4.30 版本中修复了该漏洞，核心改进是修正正则表达式的匹配逻辑：
-
禁用 Multiline 模式：确保 $ 仅匹配字符串末尾，不再匹配换行符。
-
严格匹配文件名：将正则表达式改为 \.php\z （ \z 表示绝对末尾，不匹配换行符），或显式禁用 Multiline 模式。
五、防御建议
-
升级 Apache 版本：直接升级到 2.4.30 及以上版本，彻底修复漏洞。
-
过滤危险字符：在文件上传逻辑中，严格过滤文件名中的换行符（ %0A ）、路径穿越符（ ../ ）等。
-
重命名文件：上传文件时自动生成随机文件名（如 md5(uniqid()) ），避免依赖用户提供的文件名。
-
禁用 mod_php ：改用 php-fpm 配合 mod_proxy_fcgi ，减少中间件层的解析漏洞风险。
总结
该漏洞的本质是 Apache 配置中错误的正则表达式匹配规则 与 HTTP 协议特殊字符处理 的结合，导致换行符被错误解析为文件名末尾，最终绕过扩展名验证并执行恶意代码。理解这一原理有助于从协议解析、正则表达式安全配置等角度构建防御体系。
在上传的时候加空格，然后访问的时候加这个东西就可以触发漏洞。
Nginx 文件名逻辑漏洞（CVE-2013-4547）的成因与 Nginx 对请求 URI 的错误解析逻辑 密切相关，具体可拆解为以下技术细节：
一、漏洞核心场景：FastCGI 配置不当
Nginx 常与 FastCGI（如 PHP-FPM）配合运行 PHP 脚本，典型配置如下：
nginx
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name;
include fastcgi_params;
}
-
配置意图：匹配以 .php 结尾的请求，交给 FastCGI 处理。
-
风险点： SCRIPT_FILENAME 参数通过拼接请求路径构造脚本文件路径，但 Nginx 对请求 URI 的解析存在逻辑错误。
二、错误解析逻辑：空字符（ %00 ）与空格的绕过
Nginx 在解析请求 URI 时，会对某些特殊字符（如 URL 编码的空字符 %00 、空格 %20 ）处理不当，导致以下两种绕过场景：
- 空字符（ %00 ）截断绕过
- 攻击构造：上传文件名为 1.gif （实际内容含 PHP 木马），访问时构造 URI：
plaintext
http://your-ip:8080/uploadfiles/1.gif .php
-
Nginx 错误解析：
-
%00 是 URL 编码的空字符，Nginx 在解析 SCRIPT_FILENAME 时，会将 %00 视为字符串结束符，导致路径被截断为：
plaintext
/var/www/html/uploadfiles/1.gif
- 但 FastCGI 会错误地将请求视为 .php 文件（因为 URI 中包含 .php ），从而执行 1.gif 中的 PHP 代码。
- 空格（ %20 ）绕过
- 攻击构造：上传文件名为 1.gif ，访问时构造 URI：
plaintext
http://your-ip:8080/uploadfiles/1.gif .php
-
Nginx 错误解析：
-
Nginx 在匹配 location ~ \.php$ 时，会忽略 URI 中的空格（ %20 ），认为请求以 .php 结尾。
-
FastCGI 执行时，实际文件是 1.gif ，但被当作 PHP 脚本解析执行。
三、系统差异：Windows 与 Unix 的影响
-
Windows 环境：文件系统对文件名中的空格、 %00 等字符限制较宽松，攻击者更容易构造恶意文件名并触发漏洞。
-
Unix 环境：文件系统对文件名的字符限制更严格（如不允许 %00 作为文件名的一部分），但 Nginx 的解析逻辑错误仍然存在，可通过其他编码方式（如 %20 ）绕过。
四、漏洞修复原理
Nginx 在后续版本中修复了该漏洞，核心改进是 严格解析 URI 中的特殊字符，确保 SCRIPT_FILENAME 与实际请求路径一致，避免空字符、空格等被错误截断或忽略。
五、防御建议
-
升级 Nginx 版本：直接升级到 1.4.4 及以上版本，彻底修复漏洞。
-
过滤危险字符：在文件上传逻辑中，严格过滤文件名中的 %00 、 %20 、 ../ 等危险字符。
-
禁用不必要的 FastCGI 配置：避免将非 PHP 请求误解析为 PHP 脚本。
-
文件内容验证：结合文件头签名（如 GIF 头 GIF89a 、JPG 头 FF D8 ）验证文件真实性，防止"图片马"绕过。
总结
该漏洞的本质是 Nginx 对请求 URI 的解析逻辑错误，导致攻击者可通过构造含特殊字符的请求，绕过扩展名验证并执行恶意 PHP 文件。理解这一原理有助于从协议解析、配置加固、内容验证等角度构建防御体系。
随便上传图片写个PHP代码，然后得到文件径。
访问这个图片路径，随便加一个文件名字点PHP。
配置不当导致的，解析配置不当。
编辑器漏洞
通过信息收集可以扫到这个目录，然后直接打开。
远程请求另一个网站的图片地址，并修改它的格式。
如果另一个网站的地址上有恶意代码，后面加这玩意儿就会变成PHP格式。
如果里面有后门的话，就会被执行。
*他是把另一个网站的图片通过远程请求传到这个靶场的地址上。
编辑器是搞文件上传文件处理的，这是第三方的编辑器，但是这个第三方编辑器在文件上传的时候这个代码逻辑有问题，然后就会有漏洞。
Cms漏洞：
文件上传
先查这个架构，实在找不到的时候再测。