浅析不同语言框架对HTTP请求头的处理差异&利用思路

在Web 应用开发中，HTTP 请求头是客户端和服务器之间交换元数据的关键部分。不同的编程语言和框架在解析 HTTP 请求头时，采用了各自不同的处理方式，这些差异不仅会影响系统的功能表现，也可能为攻击者提供绕过安全机制的途径。

本文将从 PHP、Python（Flask）和 Node.js（Express）三种主流技术对 HTTP 请求头处理的差异入手，分析其底层机制，并结合一个实际场景，探讨如何通过这些差异进行安全利用和防御。

一、HTTP 请求头及其规范

HTTP 请求头（HTTP Headers）包含了客户端请求中附加的信息，比如用户代理、缓存控制、语言偏好等。头部字段的格式为 key: value，且遵循 RFC 7230 的规范。RFC 允许请求头通过在行首添加空格 (SP) 或水平制表符 (HT) 来扩展多行，这被称为头折叠。
https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2

虽然这种折叠行为在早期 HTTP 版本中被允许，但随着现代 Web 技术的发展，这种做法逐渐被弃用，因为它可能会引发解析不一致的问题，进而导致安全风险。

二、PHP、Flask 和 Express 的处理差异

不同的语言和框架对请求头的解析方式各不相同。理解这些差异对于 Web 安全至关重要，因为不规范的请求头处理可能会导致攻击者找到利用漏洞的机会。

1. PHP 对请求头的处理

PHP 中常用的 getallheaders() 函数用于解析 HTTP 请求头。它直接读取原始请求头并将其解析为键值对。PHP 保留了 HTTP 请求头的原始格式，不会对字段名进行规范化处理，即使键值对前后有空格，它也会将其视为独立字段。
给一段lab代码：

<?php

// 获取请求的所有 headers
$headers = getallheaders();

// 设置响应头为 JSON 格式
header('Content-Type: application/json');

// 返回请求的 headers 作为 JSON 响应
echo json_encode($headers);

?>

例如，假设我们发送以下 HTTP 请求头：

GET / HTTP/1.1
Host: example.com
admin: x
 true: y

这些头字段将被解析为：

{
  "Host": "example.com",
  "admin": "x",
  " true": "y"
}

即使 true 的键名前有空格，PHP 仍然会将其视为独立的键值对。PHP 的这种处理方式可以保持请求头的原始格式，但同时也对开发者提出了更高的要求，确保他们正确地过滤和处理这些输入。

2. Flask 对请求头的处理

Flask 使用 werkzeug 库处理 HTTP 请求头。在请求头解析过程中，werkzeug 会自动对字段名进行规范化处理。它会将字段名转换为首字母大写的格式，并且忽略某些不符合规范的空格，从而合并这些字段。
给一段lab代码：

from flask import Flask, request, jsonify

app = Flask(__name__)

# 创建一个 GET 路由，处理 '/headers' 路径的请求
@app.route('/headers', methods=['GET'])
def headers():
    # 打印请求头信息到控制台
    print('请求头信息:', request.headers)

    # 返回请求头信息给客户端
    return jsonify(dict(request.headers))

# 监听端口 3000
if __name__ == '__main__':
    app.run(host='0.0.0.0', port=3000)

例如，针对同样的请求头：

GET /headers HTTP/1.1
Host: example.com
admin: x
 true: y

Flask 将返回如下结果：

{
  "Host": "example.com",
  "Admin": "x true: y"
}

在这种情况下，admin 和 true 被合并为同一个键，字段名被自动规范化为 Admin，并且 true 前的空格被忽略。这种行为虽然提高了一致性，但也引入了信息混淆的风险。

3. Express 对请求头的处理

Node.js 中的 Express 框架类似于 Flask，也会对请求头进行自动规范化。Express 会将所有字段名转换为小写，并且忽略不规范的输入。
给一段lab代码：

const express = require('express');

const app = express();

// 创建一个GET路由，处理对 '/headers' 路径的请求
app.get('/headers', (req, res) => {
    // 打印请求头信息到控制台
    console.log('请求头信息:', req.headers);

    // 返回请求头信息给客户端
    res.json(req.headers);
});

// 监听端口3000
app.listen({ port: 3000 , host: '0.0.0.0'});

例如，针对同样的请求头，Express 的解析结果为：

{
  "host": "example.com",
  "admin": "x true: y"
}

Express 将 admin 和 true 合并为同一个键，字段名被规范为小写。这种处理方式会隐藏掉潜在的不规范输入，导致开发者无法区分出原始请求中的细节。

三、RFC7230 的头折叠规范及其影响

根据 RFC7230，HTTP 请求头字段可以通过添加空格或水平制表符来扩展到多行。这一特性曾经用于处理较长的头字段，但在现代应用中，逐渐被视为不安全的行为。

在不支持严格规范的框架中，攻击者可以通过利用这一特性，伪造头字段绕过验证。例如，如果一个应用不正确处理头折叠，攻击者可以构造如下头字段：

admin: x
 true: y

在 PHP 中，这会被解析为两个独立字段，而在 Flask 或 Express 中，这可能被合并为一个字段，导致请求的实际含义发生改变。攻击者可以利用这种差异，绕过某些基于头部验证的安全机制。

四、利用思路：基于不同框架的头字段处理

我们通过一个实际的例子来分析如何利用这些差异进行攻击。

场景描述
假设我们有一个前端使用 PHP，后端使用 Node.js 的系统。前端 PHP 对请求头进行部分过滤，而后端 Node.js 根据请求头的内容来返回敏感信息（如 flag）。它们的代码如下：

PHP 代码：

<?php

// 获取请求的所有 headers
$headers = getallheaders();

// 检查 admin 字段是否存在，且值中包含 'true'
if (isset($headers['admin']) && strpos(strtolower($headers['admin']), 'true') !== false) {
    // 设置响应头为 JSON 格式
    header('Content-Type: application/json');
    // 返回错误信息
    echo json_encode(['error' => 'Unauthorized access']);
    exit; // 停止脚本执行
}

//如果通过检测，则带着headers向后端js代码发请求

Node.js 代码：

if(req.headers.admin.includes('true')){
    res.send(flag);
}else{
    res.send('try hard');
}

在nodejs的逻辑判断中，只要 admin 的值包含 true 即可。
根据上面的lab，不难想到，请求头用如下即可成功利用不同语言框架的解析差异绕过

admin: x
 true: y

五、结论

在 Web 应用开发中，不同语言和框架对 HTTP 请求头的处理方式存在差异。PHP、Flask 和 Express 在处理请求头时各自有其优缺点。通过理解这些差异，攻击者可以利用这些不同点进行绕过和攻击。

为了确保系统安全，开发者应统一前后端的请求头处理逻辑，并采取严格的验证方式，确保不同框架在处理请求头时不会产生不一致的行为。同时，合理应对 RFC7230 中头折叠的特性，避免因请求头解析不一致而带来的安全隐患。