正文

目录遍历漏洞在数据库查询中的真实危害及修复方案

/0 浏览量
0725

说到“目录遍历”（Directory Traversal），很多人的第一反应是黑客通过 ../ 这种手段，偷偷溜进服务器后台，把 password.txt 或者 /etc/passwd 给扒出来。这确实是经典场景，通常发生在文件上传或下载接口上。

但你有没有想过，如果这个漏洞不是出现在文件读取，而是出现在数据库查询里呢？

听起来有点反直觉对吧？毕竟数据库里没有“文件夹”，只有表、行和列。但实际上，当应用程序将用户输入直接拼接到 SQL 语句中，且该语句意在访问特定路径下的配置文件、备份数据，或者更常见的是——利用数据库的文件系统扩展功能（如 MySQL 的 LOAD_FILE）时，目录遍历的危害会呈现出一种更加隐蔽且致命的形态。

今天，我们不讲那些枯燥的定义，而是像老朋友聊天一样，深入剖析这个被忽视的角落，看看它如何从一个小疏忽演变成数据泄露的黑洞，以及我们该如何用代码和逻辑把它堵死。

一、 为什么数据库里会有“目录”？

要理解这个漏洞，首先得打破一个迷思：SQL 本身并不管理文件系统。但是，许多数据库管理系统（DBMS）提供了与操作系统交互的能力。

以 MySQL 为例，它有一个名为 LOAD_FILE() 的函数。这个函数的作用很简单：读取服务器上的文本文件，并将内容作为字符串返回。

  • 语法：LOAD_FILE(file_name)
  • 要求：文件必须位于服务器主机上，全名必须指定，文件大小小于 max_allowed_packet，且运行 MySQL 服务器的用户对该文件具有读取权限。

想象一下，你的应用有一个功能：“查看配置日志”。后端代码可能长这样：

# 伪代码示例：危险的实现方式
def get_log_content(user_input):
    # 假设 user_input 是用户提供的文件名，比如 "app.log"
    sql = f"SELECT LOAD_FILE('{user_input}') AS content;"
    result = db.execute(sql)
    return result

如果用户输入 ../../../etc/passwd，SQL 就变成了： SELECT LOAD_FILE('../../../etc/passwd') AS content;

此时，数据库不再是在查“表”，而是在执行一个文件系统操作。这就是数据库层面的目录遍历。它利用的是数据库引擎对底层 OS 文件系统的访问权限。

除了 LOAD_FILE，PostgreSQL 有 pg_read_file()，SQL Server 有 xp_cmdshell 结合批处理脚本读取文件，Oracle 有 UTL_FILE 包。这些功能虽然强大，但如果缺乏严格的输入验证，就会成为黑客的跳板。

二、 真实世界中的危害：不只是读个密码文件

很多人觉得，“不就是读个文件吗？我能读到什么？”

这里需要纠正一个观念：危害不在于“能读”，而在于“能读什么”以及“怎么读”。

1. 敏感信息泄露的连锁反应

在早期的 Web 应用中，开发者喜欢把数据库连接字符串、API 密钥甚至硬编码的密码放在配置文件里，比如 config.ini、db.conf 或者 .env 文件。 如果攻击者通过目录遍历读到了 /var/www/html/config/db.conf，里面可能写着：

[database]
host=localhost
user=root
password=SuperSecret123!

一旦拿到这些凭据，攻击者就不再需要折腾你的 Web 应用了，他们可以直接连接数据库，进行增删改查，甚至提权。

2. 内部网络结构的侦察

通过遍历目录，攻击者可以探测服务器的目录结构。例如，尝试读取 /proc/self/environ（在 Linux 上），可能会暴露环境变量，进而揭示内部服务的主机名、端口、其他微服务的地址等。这些信息对于后续的内网渗透至关重要。

3. 逻辑绕过与二次注入

有些应用虽然对文件名做了过滤，但可能只过滤了 ../。然而，在某些操作系统或数据库配置下，使用符号链接（Symbolic Link）或绝对路径的不同表示法（如 /./ 或 %2e%2e%2f URL 编码）可能绕过简单的黑名单检查。

更危险的是，如果读取的文件内容是动态生成的，或者包含特殊字符，可能会导致后续的解析错误，进而引发 SQL 注入或其他逻辑漏洞。

4. 拒绝服务（DoS）

虽然少见，但如果攻击者构造大量深层嵌套的路径请求，或者读取巨大的系统日志文件，可能导致数据库服务器资源耗尽，CPU 飙升，内存溢出，最终导致服务不可用。

三、 一个完整的案例分析：从漏洞到修复

为了让大家看得更明白，我们构建一个真实的场景。

背景： 某电商网站有一个“下载发票 PDF”的功能。发票存储在服务器的 /invoices/ 目录下，按年份和月份组织，例如 /invoices/2023/10/invoice_12345.pdf。 用户点击“下载”，前端发送请求：GET /download?file=invoice_12345.pdf

漏洞代码（Python + Flask + MySQL）：

from flask import Flask, request, send_file
import mysql.connector
import os

app = Flask(__name__)

@app.route('/download')
def download_invoice():
    filename = request.args.get('file')
    
    # 【高危点】：直接拼接用户输入到 SQL 中
    # 意图是从数据库中获取发票文件的完整路径，然后读取并发送
    conn = mysql.connector.connect(
        host="localhost",
        user="root",
        password="password",
        database="shop_db"
    )
    cursor = conn.cursor()
    
    # 假设数据库中有一张表 invoices，存储了文件名和对应的磁盘路径
    # 恶意用户输入: ../../../etc/passwd
    query = f"SELECT file_path FROM invoices WHERE filename = '{filename}'"
    
    try:
        cursor.execute(query)
        row = cursor.fetchone()
        
        if row:
            file_path = row[0]
            # 【高危点2】：直接使用路径，未做校验
            if os.path.exists(file_path):
                return send_file(file_path, as_attachment=True)
            else:
                return "File not found", 404
        else:
            return "Invoice not found", 404
    except Exception as e:
        return str(e), 500
    finally:
        cursor.close()
        conn.close()

if __name__ == '__main__':
    app.run(debug=True)

攻击过程：

  1. 攻击者发现 filename 参数未经验证。
  2. 输入 ../../../etc/passwd。
  3. SQL 变为：SELECT file_path FROM invoices WHERE filename = '../../../etc/passwd'。
  4. 如果数据库中恰好有一条记录的 filename 字段是 ../../../etc/passwd（或者攻击者通过其他手段注入了这条记录），那么 file_path 可能就是 /etc/passwd。
  5. 即使数据库中没有这条记录，如果攻击者能控制 file_path 的生成逻辑，或者应用直接从文件系统读取而非查库，漏洞依然存在。
  6. 更常见的情况是，应用直接根据用户输入构建路径：base_dir = '/var/www/invoices'; full_path = os.path.join(base_dir, filename)。
  7. 此时 full_path 变成 /var/www/invoices/../../../etc/passwd，解析后即为 /etc/passwd。
  8. 服务器返回 /etc/passwd 的内容，攻击者获得用户列表。

注意： 在这个例子中，真正的漏洞其实更多体现在文件路径拼接上，但通过数据库查询来映射文件名是一种常见模式。如果数据库本身提供了 LOAD_FILE 这样的接口，而用户输入直接控制了文件名参数，那就是纯粹的数据库目录遍历。

四、 如何彻底修复？

修复这类漏洞的核心原则只有一个：永远不要信任用户输入，并且采用白名单机制。

以下是几种经过实战检验的修复方案，按推荐程度排序。

方案一：使用白名单限制文件范围（最推荐）

不要让用户决定文件名，而是让用户选择一个 ID，然后在服务端映射到具体的文件。

# 修复后的代码
@app.route('/download-safe')
def download_invoice_safe():
    invoice_id = request.args.get('id')
    
    if not invoice_id or not invoice_id.isdigit():
        return "Invalid ID", 400
    
    # 1. 从数据库安全地获取文件路径（使用参数化查询防止 SQL 注入）
    conn = mysql.connector.connect(...)
    cursor = conn.cursor()
    query = "SELECT file_path FROM invoices WHERE id = %s"
    cursor.execute(query, (invoice_id,))  # 使用 %s 占位符，自动转义
    row = cursor.fetchone()
    conn.close()
    
    if not row:
        return "Invoice not found", 404
        
    base_dir = '/var/www/invoices'
    file_path = row[0]
    
    # 2. 规范化路径，防止 ../ 穿越
    # os.path.realpath 会解析所有符号链接和相对路径，返回绝对路径
    real_path = os.path.realpath(os.path.join(base_dir, file_path))
    
    # 3. 严格校验：确保解析后的路径仍然在允许的基目录下
    if not real_path.startswith(base_dir):
        # 如果路径超出了 base_dir，说明存在目录遍历攻击
        return "Access denied", 403
        
    # 4. 检查文件是否存在且可读
    if os.path.isfile(real_path) and os.access(real_path, os.R_OK):
        return send_file(real_path, as_attachment=True)
    else:
        return "File not found", 404

关键点解析：

  • 参数化查询：防止了 SQL 注入，确保 invoice_id 不会破坏 SQL 结构。
  • os.path.realpath：这是防御目录遍历的神器。它会将 a/../b 转换为 b，消除所有相对路径引用。
  • 前缀校验：startswith(base_dir) 确保了最终访问的文件一定在我们的白名单目录内。

方案二：如果必须使用文件名，进行严格的字符过滤

如果业务场景确实允许用户输入文件名（比如搜索功能），那么必须进行严格的白名单过滤。

import re

def sanitize_filename(filename):
    # 只允许字母、数字、下划线、连字符和点号
    # 禁止任何特殊字符，包括 ../ 中的 / 和 .
    if not re.match(r'^[a-zA-Z0-9_.\-]+$', filename):
        raise ValueError("Invalid filename")
    return filename

@app.route('/search-file')
def search_file():
    filename = request.args.get('file', '')
    try:
        safe_name = sanitize_filename(filename)
        # 继续处理...
    except ValueError:
        return "Invalid filename format", 400

缺点： 这种方式比较脆弱，因为不同操作系统对文件名的支持不同，且容易误杀合法的特殊字符文件名。因此，优先推荐使用方案一。

方案三：禁用数据库的文件系统访问功能

如果你根本不需要通过数据库读取外部文件，那么最安全的做法就是禁用相关功能。

  • MySQL: 确保 secure_file_priv 系统变量设置正确。 “`sql – 查看当前设置 SHOW VARIABLES LIKE ‘secure_file_priv’;

– 在 my.cnf 或 my.ini 中设置 [mysqld] secure_file_priv=/path/to/allowed/dir # 或者完全禁用 secure_file_priv=

  设置为空字符串表示禁止导入导出；设置为特定目录，则只能读取该目录下的文件。这可以从数据库层面切断攻击者利用 `LOAD_FILE` 的可能性。

- **PostgreSQL**: 避免使用 `pg_read_file`，除非必要，并限制执行该函数的用户权限。

- **SQL Server**: 禁用 `xp_cmdshell`，除非有绝对必要的理由。
  ```sql
  sp_configure 'show advanced options', 1;
  RECONFIGURE;
  sp_configure 'xp_cmdshell', 0;
  RECONFIGURE;

五、 给开发者的贴心建议

我知道，写代码很累，尤其是还要考虑各种边界情况。但安全不是负担，它是你产品的护城河。

  1. 最小权限原则：运行数据库服务的用户，不应该有读取 /etc 或用户主目录的权限。Linux 上，你可以为 MySQL 创建一个专用的低权限用户，而不是用 root 运行。
  2. 日志监控：定期审查数据库日志和应用日志。如果发现大量的 LOAD_FILE 调用或异常的文件路径访问，立即报警。
  3. 自动化测试：在你的 CI/CD 流程中加入静态代码分析工具（如 SonarQube、Bandit 等），它们能帮你捕捉到明显的 SQL 注入和路径遍历风险。
  4. 教育团队：让新入职的开发者明白，../ 不仅仅是一个字符串，它是一个指向服务器深处的箭头。每一次用户输入，都是一次潜在的试探。

结语

目录遍历漏洞在数据库查询中的表现，往往比传统的文件读取更隐蔽，因为它披着“数据查询”的外衣。但它带来的危害却毫不逊色：从敏感信息泄露到内网穿透，每一步都可能让你的心血毁于一旦。

记住，防御的关键不在于复杂的算法，而在于敬畏之心——对用户输入保持怀疑，对系统资源保持节制。用白名单代替黑名单，用参数化查询代替字符串拼接，用路径规范化代替盲目信任。

当你下次看到 ../ 时，希望你能意识到，那不是一个普通的字符序列，而是一个需要被严肃对待的安全信号。希望这篇文章能帮你建立起一道坚固的防线，让你的应用既强大又安全。如果有具体的代码场景需要分析，随时欢迎交流，我们一起探讨。

-- 展开阅读全文 --