PortSwigger学院——Web学习路线

原创已于 2025-11-12 23:11:32 修改 · 344 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#学习 #安全 #网络安全 #web安全

于 2025-11-08 22:48:12 首次发布

文章是一点点学习心得，大部分是我整理PortSwigger学院和网上资料得来，如果有理解不到位的地方，欢迎指正和学习交流~

目录遍历

目录遍历：这些漏洞使攻击者能够读取运行应用程序的服务器上的任意文件。这可能包括：

应用程序代码和数据。
后端系统凭证。
敏感的操作系统文件。

在某些情况下，攻击者可能能够写入服务器上的任意文件，从而修改应用程序数据或行为，并最终完全控制服务器。

以下示例当中，应用程序未实现任何针对路径遍历攻击的防御措施

一个购物应用会显示待售商品的图片。它可能使用以下 HTML 代码加载图片：

<img src="/loadImage?filename=218.png">

图像存储在磁盘上的指定位置/var/www/images/。为了返回图像，应用程序会将请求的文件名附加到此基本目录，并使用文件系统 API 读取文件内容。换句话说，应用程序从以下文件路径读取数据：

/var/www/images/218.png

因此，攻击者可以请求以下 URL/etc/passwd，从服务器文件系统中检索文件：

https://insecure-website.com/loadImage?filename=../../../etc/passwd

该序列../在文件路径内有效，表示在目录结构中向上移动一级。这是三个连续的../序列，因此实际读取的文件是：/etc/passwd

在基于 Unix 的操作系统中，这是一个包含服务器上注册用户详细信息的标准文件，但攻击者可以使用相同的技术检索其他任意文件。

在 Windows 系统中，../和..\都是有效的目录遍历序列。以下是一个针对 Windows 服务器的等效攻击示例：

https://insecure-website.com/loadImage?filename=..\..\..\windows\win.ini

1.绝对路径

有些应用程序会绕过../等关键字。可以使用各种技术绕过这种防御

比如：

filename=/etc/passwd

2.双写../绕过

有些应用程序，会将../取消掉，就可以使用嵌套遍历，双写../就可以

filename=....//....//....///etc/passwd

3.URL编码绕过

可以采用URL编码来绕过服务器对 . 或者 / 的检测：

比如对/的URL编码绕过：

filename=..%252f..%252f..%252fetc/passwd

4.绝对路径

有些filename文件的路径是绝对路径，

filename=/var/www/images/

直接在后面跟上etc/passwd,即可

5. 截断文件后缀

有些对文件后缀进行了限制，只有当后缀为图片的时候才解析

比如，限制文件后缀为.png，那么对应的输入为：

filename=../../../etc/passwd%00.png

6.漏洞防御

防止文件路径遍历漏洞的最有效方法是避免将用户提供的输入完全传递给文件系统API

如果认为不可避免的是将用户提供的输入传递给文件系统API，则应同时使用两层防御，以防止受到攻击：

·应用程序应在处理之前验证用户输入。理想情况下，验证应与允许值的白名单进行比较。如果所需的功能无法做到这一点，则验证应验证输入内容仅包含允许的内容，例如纯字母数字字符。
·验证提供的输入后，应用程序应将输入附加到基本目录，并使用平台文件系统API规范化路径。验证规范化路径以预期的基本目录开头。

文件上传

文件上传漏洞：网络服务器允许用户在未充分验证文件名称、类型、内容或大小等信息的情况下，将文件上传到其文件系统。可能被用于上传任意且潜在危险的文件，甚至可能包括能够执行远程代码的服务器端脚本文件。

如果文件名验证不当，攻击者只需上传一个同名文件即可覆盖关键文件

上传漏洞产生的原因

一些web应用程序中允许上传图片，文本或者其他资源到指定的位置，文件上传漏洞就是利用这些可以上传的地方将恶意代码植入到服务器中，再通过url去访问以执行代码.

造成文件上传漏洞的原因是:

1.服务器配置不当

2.开源编辑器上传漏洞

3.本地文件上传限制被绕过

4.过滤不严或被绕过

5.文件解析漏洞导致文件执行

6.文件路径截断

更常见的情况是，开发者会实施他们认为可靠的验证机制，但这些机制要么本身存在缺陷，要么很容易被绕过。

Web shell

Web Shell 是一种恶意脚本，攻击者只需向正确的端点发送 HTTP 请求，即可在远程 Web 服务器上执行任意命令

如果成功上传 Web Shell，您实际上就拥有了对服务器的完全控制权。这意味着您可以读写任意文件、窃取敏感数据，甚至可以利用服务器对内部基础设施和网络外部的其他服务器发起攻击

例如，可以使用以下 PHP 单行代码从服务器的文件系统中读取任意文件：

<?php echo file_get_contents('/path/to/target/file'); ?>

一旦上传，发送对该恶意文件的请求将在响应中返回目标文件的内容。

一个功能更全面的 Web 外壳可能看起来像这样：

<?php echo system($_GET['command']); ?>

此脚本允许通过查询参数传递任意系统命令，如下所示：

GET /example/exploit.php?command=id HTTP/1.1

网站验证文件上传的一种方法是检查输入特定的Content-Type标头是否与预期的 MIME 类型匹配。例如，如果服务器只接受图像文件，则可能只允许 image/jpeg和image/png等类型。

当服务器隐式信任此标头的值时，就会出现问题。如果未进行进一步验证以检查文件内容是否实际与预期的 MIME 类型匹配，则可以使用 Burp Repeater 等工具轻松绕过此防御。

Web 服务器经常使用请求filename中的字段multipart/form-data来确定文件的名称和保存位置。

防止用户上传恶意脚本最直接的方法之一是将一些潜在的危险文件扩展名（例如 .bashrc）列入黑名单。

然而，黑名单机制本身存在缺陷，因为很难完全屏蔽所有可能用于执行代码的文件扩展名。用户有时可以通过使用一些不太常用但仍然可执行的替代文件扩展名（例如 .cashrc、.dashrc.php5等.shtml）来绕过黑名单。

混淆文件扩展名

假设验证代码区分大小写，无法识别出这exploit.pHp是一个.php文件。如果后续将文件扩展名映射到 MIME 类型的代码不区分大小写，那么这种差异就允许你偷偷地将恶意 PHP 文件送入服务器，使其绕过验证并最终被执行

也可以通过这种手段来实现：

请提供多个文件扩展名。根据用于解析文件名的算法，以下文件可能被解释为 PHP 文件或 JPG 图像：exploit.php.jpg
添加尾随字符。某些组件会移除或忽略尾随的空格、句点等：exploit.php.
尝试对点号、正斜杠和反斜杠使用 URL 编码（或双重 URL 编码）。如果在验证文件扩展名时该值未被解码，但稍后在服务器端被解码，则也可能允许您上传原本会被阻止的恶意文件：exploit%2Ephp
在文件扩展名前添加分号或 URL 编码的空字节字符。如果验证代码是用 PHP 或 Java 等高级语言编写的，而服务器使用 C/C++ 等底层函数处理文件，则可能导致对文件名结尾的处理出现差异exploit.asp;.jpg。exploit.asp%00.jpg
尝试使用多字节 Unicode 字符，这些字符在 Unicode 转换或规范化后可能会被转换为空字节和点号。例如xC0 x2E，如果文件名被解析为 UTF-8 字符串，则类似 `\n`xC4 xAE或`\n` 的序列xC0 xAE可能会被转换为 ` x2E\n`，但在用于路径之前会被转换为 ASCII 字符

如果这种转换不是递归应用的，你可以将禁止的字符串放置在特定位置，使得移除该字符串后，文件扩展名仍然有效，比如：

exploit.p.phphp

SQL注入

SQL注入（SQLi）是一种Web安全漏洞，攻击者可以利用它干扰应用程序对其数据库的查询。这可能导致攻击者查看通常无法检索的数据，例如其他用户的数据或应用程序可以访问的任何其他数据。在许多情况下，攻击者可以修改或删除这些数据，从而对应用程序的内容或行为造成永久性更改。

您可以使用针对应用程序中每个入口点的系统性测试集来手动检测 SQL 注入。为此，您通常需要提交：

'检查单引号字符是否存在错误或其他异常情况。
一些 SQL 特有的语法，用于评估入口点的基本（原始）值和不同的值，并查找应用程序响应中的系统性差异。
布尔条件（例如OR 1=1true 和OR 1=2false）以及应用程序响应中的差异。
旨在触发 SQL 查询执行时的时间延迟的有效载荷，并查找响应时间的差异。
OAST 有效载荷旨在当在 SQL 查询中执行时触发带外网络交互，并监控任何由此产生的交互

SQL 注入攻击存在于查询的不同部分

大多数 SQL 注入漏洞都发生在查询WHERE语句的 WHERE 子句中SELECT。大多数经验丰富的测试人员都熟悉这种类型的 SQL 注入。

然而，SQL注入漏洞可能出现在查询中的任何位置，也可能出现在不同类型的查询中。其他一些常见的SQL注入漏洞出现位置包括：

在UPDATE语句中，在更新值或WHERE子句中。
在INSERT语句中，在插入的值中。
在SELECT语句中，在表名或列名内。
在SELECT语句中，在ORDER BY从句内

想象一下，一个购物应用会按不同类别展示商品。当用户点击“礼品”类别时，他们的浏览器会请求以下URL：

https://insecure-website.com/products?category=Gifts

这将导致应用程序发出 SQL 查询，从数据库中检索相关产品的详细信息：

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

此 SQL 查询请求数据库返回：

所有细节（*）
从products表格中
在哪里category是Gifts
并且released是1。

这项限制released = 1被用来隐藏尚未发布的产品。我们可以假设对于未发布的产品，released = 0

注释

该应用程序没有实现任何针对 SQL 注入攻击的防御措施。这意味着攻击者可以构建如下攻击，例如：

https://insecure-website.com/products?category=Gifts'--

这将生成以下 SQL 查询：

SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1

关键在于，请注意 ` --<input type="test">` 是 SQL 中的注释指示符。这意味着查询的其余部分将被解释为注释，从而被移除。在本例中，这意味着查询不再包含 `<input type="test">` AND released = 1。因此，所有产品都会显示出来，包括尚未发布的产品。