cURL（Client for URLs）是一个强大的开源命令行工具和库，用于通过URL传输数据。它支持多种协议，包括HTTP、HTTPS、FTP等。在HTTP协议中，请求头是客户端向服务器发送的关键元数据，以键值对形式存在。
HTTP请求头在现代Web开发中扮演着至关重要的角色，它们不仅用于简单的网页抓取，还广泛应用于API交互、身份验证、内容协商等场景。理解如何正确使用cURL发送自定义HTTP请求头对于开发人员、系统管理员和安全专业人员来说至关重要。
虽然基本的请求头发送语法简单直观，但要正确处理特殊字符、非ASCII数据以及潜在的恶意输入，需要深入理解底层机制。本报告将揭示cURL及其底层库libcurl的强大功能，同时也强调了用户或应用程序开发者在输入清理方面的全部责任。
cURL中发送自定义HTTP请求头的核心机制是使用
请求头名称和对应的值被包含在一个字符串中，由冒号（
服务器通常会记录User-Agent头，此命令允许指定自定义的用户代理字符串。
当向期望JSON数据的API发送数据时，设置Content-Type和Authorization头是标准做法。
要在单个请求中发送多个请求头，只需重复使用
当请求头值包含对命令行shell具有特殊含义的字符（如空格、引号或&符号）时，必须正确处理这些字符，以确保命令按预期解释。
使用双引号是最常见的方法，但需要对值中的任何字面双引号字符进行转义。标准转义方法是在字符前添加反斜杠（\）。
使用单引号可以简化命令，因为像Bash这样的shell不会解释单引号内的大多数特殊字符。这可以避免转义双引号的需求。
区分shell级别的字符转义（用于请求头）和URL编码（也称为百分号编码，用于URL组件）至关重要。URL编码是一种表示URL路径或查询字符串中特殊字符的机制，例如将空格替换为%20或将斜杠替换为%2F。
重要提示：
cURL提供
历史上，RFC 7230定义的HTTP/1.1限制请求头字段值为US-ASCII字符的子集。直接使用其他编码（如ISO-8859-1或UTF-8）是不鼓励的，并且支持不一致。
为了解决这一限制，引入了新的标准：
注意：filename*参数使用RFC 5987编码非ASCII字符
搜索结果未提供确凿证据表明cURL自动根据RFC 5987/8187或其他百分号编码方案对HTTP请求头值中的非ASCII字符进行编码。
虽然cURL可以通过百分号编码处理URL中的非ASCII字符，但此行为未明确记录适用于请求头值。
开发者不应假设cURL会自动对非ASCII请求头值进行编码。为确保最大兼容性和符合现代标准，如果已知接收服务器支持相关RFC，应手动按照相关RFC对包含非ASCII字符的请求头值进行编码。
依赖隐式行为可能导致跨不同系统出现不可预测的结果。
动态构建HTTP请求头时最严重的安全风险是CRLF注入，也称为HTTP请求头分裂或HTTP响应分裂。
HTTP协议使用回车（CR，\r）和换行（LF，\n）的序列——统称为CRLF——来终止每个请求头行。如果攻击者可以将原始CRLF序列注入到用作构造请求头的值中，他们可以有效地终止预期的请求头并开始注入新的、恶意的请求头。
注意：\r\n序列导致请求头提前终止，从而注入新的恶意头
本研究的关键发现是：libcurl库不对用户提供的自定义请求头执行任何清理。当使用libcurl中的
这一设计决策将完全责任放在应用程序开发者身上，要求他们对用户输入的请求头字符串进行清理。允许任何未经清理的用户输入成为传递给cURL或libcurl的请求头字符串，会直接创建CRLF注入攻击的向量。
通过Wireshark和其他外部工具观察到的行为确认：
CRLF注入漏洞被评为高风险，影响范围广泛
除了客户端清理外，服务器端也应实施额外的安全措施：
手动测试
自动化测试
使用cURL发送自定义HTTP请求头表面上是一项简单的任务，由直观的
本报告已确立，虽然cURL是一个强大的工具，但它基于用户责任的原则运行。它将传输它接收到的数据，包括可能危险的控制字符。
对于任何使用cURL动态生成请求的开发人员或管理员来说，清理输入以防止CRLF注入漏洞的负担完全在于他们自己。未能严格剥离任何用户影响数据的目标请求头中的控制字符（如CR和LF）可能会使应用程序面临严重的安全风险。
严格输入验证和清理不仅是最佳实践——它是安全使用cURL的任何自动化或交互系统的强制性要求。
引言：cURL与HTTP请求头
HTTP请求头的主要功能
Accept: application/json）Authorization: Bearer <token>）User-Agent: MyCustomApp/1.0）
为什么需要深入理解请求头处理？
基础语法：发送HTTP请求头
核心机制：-H选项
-H或--header命令行选项。这种语法结构在所有已记录的用例中保持一致。
基本语法结构
curl -H "Header-Name: Header-Value" [URL]:）后跟一个空格分隔。
实际应用示例
设置自定义User-Agent
curl -H "User-Agent: MyCustomUserAgent/1.0" http://httpbin.org/headers
与JSON API交互
curl -H "Content-Type: application/json" -H "Authorization: Bearer <your_api_token>" https://api.example.com/resource
发送多个请求头
-H或--header选项即可。cURL将解析每个实例，并将所有指定的请求头包含在传出的请求中。
多请求头示例
curl -H "Referer: https://www.example-origin.com" -H "X-Custom-ID: 12345" http://httpbin.org/headers
命令执行流程
-H选项-H选项创建单独的HTTP头字段
特殊字符处理
引号与转义
双引号处理
双引号示例
curl -H "X-Data: {\"message\": \"Hello, \\\"world\\\"!\"}" http://httpbin.org/post -d ''
单引号处理
单引号示例
curl -H 'X-Data: {"message": "This value contains double quotes"}' http://httpbin.org/post -d ''
URL编码与请求头编码的区别
字符编码对比
编码类型
用途
示例
cURL支持
Shell转义
命令行参数处理
\" \'
✓
URL编码
URL路径/查询参数
%20 %2F
✓ (使用--data-urlencode)
RFC 5987/8187
非ASCII字符编码
UTF-8编码
✗ (需手动处理)
--data-urlencode选项自动编码POST请求的数据，但这不适用于HTTP请求头本身的内容。
非ASCII字符处理
RFC标准与字符编码
新标准的引入
编码格式示例
Content-Type: text/plain; charset=UTF-8
Content-Disposition: attachment; filename*=UTF-8''%E6%96%87%E4%BB%B6.txt
cURL对非ASCII字符的处理
关键发现
开发者责任
编码实现建议
filename*=UTF-8''encoded_filename格式
安全风险：CRLF注入
漏洞原理
HTTP协议中的CRLF序列
攻击场景
CRLF序列示例
GET /page HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
\r\n
X-Malicious-Header: Content-Type: text/javascript
\r\n
Cookie: session_id=evil_session
libcurl的安全立场
CURLOPT_HTTPHEADER选项（与命令行工具中的-H标志相对应）时，库会"按原样"发送提供的字符串，而不进行过滤或转义控制字符。
设计决策的影响
libcurl行为验证
安全影响评估
缓解措施
最佳实践
清理代码示例（Python）
import re
def clean_header_value(value):
# 移除所有控制字符
return re.sub(r'[\x00-\x1F\x7F]', '', value)
# 使用清理后的值构建请求头
user_input = "Some data with CR\r\nand LF\ncharacters"
safe_value = clean_header_value(user_input)
curl_command = f'curl -H "X-Data: {safe_value}" https://api.example.com'
服务器端防御
安全测试建议
结论
核心发现总结
-H标志支持。然而，这种简单性掩盖了与字符编码和最重要的安全相关的潜在复杂性。
安全责任声明
安全第一的方法
关键行动项
"cURL提供了强大的功能，但安全责任完全落在开发者肩上。在处理用户输入时，永远不要假设工具会自动处理安全问题。"
深入理解cURL与HTTP请求头的安全性与编码
作者：zvvq博客网
低风险高风险
免责声明：本文来源于网络，如有侵权请联系我们！