curl `--proto` 选项全解：精确限制传输协议、防御重定向攻击的实战指南

curl--proto选项全解精确限制传输协议、防御重定向攻击的实战指南【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl--proto是 curl 命令行工具中用于限定传输协议白名单/黑名单的核心安全选项它允许你在发起请求前显式声明本次传输允许使用哪些协议、禁止使用哪些协议。本指南以 curl 仓库中 tests/data/data1705-3.md 的官方文档为主线结合 src/tool_getparam.c、src/tool_paramhlp.c 等源码实现与 tests/data/test1474、tests/data/test322 等测试用例系统讲解--proto的语法、三种修饰符语义、与--proto-redir/--proto-default的配合方式以及用-all一键禁用的安全实战方案。一、--proto是什么一次传输的协议准入清单--proto自 curl 7.20.2 起提供属于 connection curl 类别其作用是限制一次传输中允许使用的协议集合。它的核心语义可以概括为协议列表从左到右依次求值逗号分隔每一项是一个协议名或关键字all每一项可以带零个或多个修饰符前缀、-、不带修饰符时等价于默认追加许可。官方文档给出的定义是 Limit what protocols to allow for transfers即它控制的是这次 curl 调用允许碰哪些协议。它不会改变 curl 对 URL 中 scheme 的解析结果而是决定解析出来的协议是否被放行被禁止的协议即使写在 URL 里也会被拒绝。二、三种修饰符、-、修饰符是--proto的语法核心必须准确理解三者差异修饰符语义对既有许可集合的影响或省略许可该协议在已许可的集合上追加-拒绝该协议从已许可的集合中移除只许可该协议清空已有集合仅保留本次指定的可被后续项再修改官方文档中的示例--proto -ftps 使用默认协议集合但禁用 ftps --proto -all,https,http 只启用 http 和 https --proto http,https 也只启用 http 和 https第一条示例中-ftps表示沿用默认许可集合但把 ftps 剔除。默认许可集合由 curl 构建时启用的全部协议构成详见下文源码分析。第二、三条示例虽然写法不同一个用-all清空再添加一个用清空再指定但最终效果一致都只放行 http 和 https。三、all关键字与未知协议的宽容策略3.1all的含义all不是某个具体协议名而是当前 curl 二进制中构建进的所有协议的集合别名。它同样可以搭配修饰符使用-all清空许可集合即什么都不允许all/all重新填满全部协议。3.2 对未知/禁用协议的处理警告而非报错官方文档明确指出Unknown and disabled protocols produce a warning.即当你用--proto -xxx禁用一个当前 curl 并未构建的协议例如一个没有编译 FTP 支持的 curl 里写--proto -ftp时curl 不会报错退出而是给出警告并继续执行。这一设计非常关键——它让脚本可以安全地一刀切禁用潜在危险协议而不必关心当前二进制到底编译了哪些协议。如果 curl 对不存在的协议直接报错那么同一套禁用脚本在不同构建环境的 curl 上行为就会不一致甚至无法运行。3.3 与未知协议报错的边界需要区分--proto列表里写了一个不存在的协议名例如--proto -http这种修饰符误用或写了--proto httpss此时proto2num()会输出unrecognized protocol错误并返回PARAM_BAD_USEcurl 以退出码 2 失败。这一点被 tests/data/test322 精确锁定curl: unrecognized protocol -http curl: option --proto: is badly used here也就是说禁用未构建协议走警告路径而写了一个根本不存在的协议名走硬错误路径——两者不能混为一谈。四、重复使用与等价合并官方文档说明--proto可以多次出现多次使用的效果等价于把所有协议项按顺序拼接进同一次选项curl --proto -ftp --proto -smb http://example.com # 等价于 curl --proto -ftp,-smb http://example.com这在脚本生成命令时很实用可以按模块逐步累积协议策略而不必在单个参数里手工维护一长串列表。五、源码级实现--proto是如何被解析的5.1 参数入口在 src/tool_getparam.c 中--proto的解析入口如下case C_PROTO: /* --proto */ config-proto_present TRUE; err proto2num(built_in_protos, config-proto_str, nextarg);它调用 src/tool_paramhlp.c 中的proto2num()将用户的协议表达式转换成最终的协议字符串并存入config-proto_str随后由--libcurl生成逻辑映射为 libcurl 的CURLOPT_PROTOCOLS_STR见 src/config2setopts.c。5.2 默认协议集合来自运行时信息built_in_protos并非硬编码常量而是 curl 启动时通过curl_version_info()获取的运行时协议列表。在 src/tool_libinfo.c 的get_libcurl_info()中curlinfo curl_version_info(CURLVERSION_NOW); ... built_in_protos curlinfo-protocols; ... proto_count builtin - built_in_protos;也就是说all到底包含哪些协议取决于当前 curl 二进制实际编译进了哪些协议支持——这正是上文禁用未构建协议只给警告这一宽容策略能成立的前提。5.3 从左到右求值的具体实现proto2num()维护一个临时的protoset协议集合数组逐项扫描逗号分隔的输入src/tool_paramhlp.cswitch(*str) { case : action set; /* 清空后仅保留 */ break; case -: action deny; /* 从集合移除 */ break; case : action allow; /* 追加许可 */ break; default: /* 无修饰符等价于 allow */ break; }对应all的处理src/tool_paramhlp.cdeny时清空protoset[0] NULLallow/set时把全部内置协议复制进集合。单个协议名则经proto_token()校验后执行对应动作最后结果按字母序排序并拼接成最终字符串src/tool_paramhlp.c。5.4 测试用例佐证tests/data/test1474 验证--proto -all会禁用全部协议命令--proto -all http://...直接以退出码 2PARAM_BAD_USE失败——因为许可集合为空任何请求都无法发起tests/data/test322 验证修饰符与协议名之间不能有歧义--proto -http被解析为未知协议-http并报错退出tests/data/test1245 验证--proto的拒绝优先级高于--proto-redir的许可--proto all,-ftp --proto-redir -all,ftp组合下--proto中已禁用的 ftp 不会被--proto-redir重新放行tests/data/test1401 展示了--proto http,ftp,file在--libcurl代码生成场景下的合法写法。六、安全实战重定向场景下的协议白名单6.1 问题的由来--location-L会让 curl 跟随服务器返回的 3xx 重定向详见 docs/cmdline-opts/location.md。攻击者可以构造一个初始是 http重定向到 file:// 或 ftp://的响应链诱导 curl 去访问本不该访问的资源。重定向目标协议必须受到比普通传输更严格的限制。6.2--proto-redir单独约束重定向协议curl 为此提供--proto-redir7.21.0 起它只约束重定向跳转时允许的协议语法与--proto完全一致。官方示例curl --proto-redir -all,http,https --follow http://example.com该命令表示重定向时只允许 http 和 https其余一律拒绝。其默认策略是重定向仅允许 HTTP、HTTPS、FTP、FTPS自 7.65.2 起收紧而--proto-redir all或all会放开全部协议官方文档明确警告这对安全不利。6.3--proto与--proto-redir的优先级优先级规则是--proto中拒绝的协议--proto-redir无权放行。也就是说--proto是全局限定--proto-redir是在其基础上对重定向场景再收紧一层。这也解释了为何默认的重定向白名单http/https/ftp/ftps会比普通传输的默认集合更窄。6.4 推荐组合一个稳妥的仅 HTTP(S) 传输 安全重定向组合可以写成curl --proto http,https --proto-redir http,https -L https://example.com--proto http,https本次传输只允许 http/httpsfile、ftp、smb 等一律拒绝--proto-redir http,https重定向同样只允许 http/https封死协议降级攻击。配合 docs/cmdline-opts/follow.md 中的--max-redirs还可以进一步限制重定向跳数。七、无 scheme URL 与--proto-default--proto只管协议是否被允许而当 URL缺少 scheme如直接写ftp.example.com时由--proto-default7.45.0 起决定 curl 默认按什么协议猜测。相关要点见 docs/cmdline-opts/proto-default.md协议名不区分大小写且不带://后缀指定了未知或不支持的协议会触发CURLE_UNSUPPORTED_PROTOCOL错误它不改变代理的默认协议代理默认仍是 http未设置时curl 按--url的规则根据主机名猜测协议默认协议不能设为ipfs或ipns这两个 scheme 必须显式写在 URL 中。典型用法curl --proto-default https ftp.example.com等价于请求https://ftp.example.com。--proto的许可集合对该默认协议同样生效二者可配合使用。八、设计意图总结为什么--proto对脚本如此友好综合官方文档与源码实现--proto的设计有三个值得称道之处宽容的禁用语义--proto -xxx禁用未构建协议只警告不报错见 3.2 节保证跨构建环境脚本行为一致这正是文档中 This allows scripts to safely rely on being able to disable potentially dangerous protocols 的含义声明式集合运算/-/三种修饰符与all关键字组成了一套完整的集合加减语义可在命令行上精确表达默认全开、减去若干或只保留若干两种策略重定向独立管控--proto-redir与--proto分层配合tests/data/test1245 验证了拒绝优先让正常传输放开、重定向收紧的安全基线成为可能。九、附--proto速查表表达式效果--proto http或--proto http在默认集合上追加许可 http--proto -http从默认集合中移除 http--proto http只允许 http--proto -all禁止一切协议请求必然失败退出码 2--proto -all,https,http只允许 http 和 https--proto http,https同上等价写法--proto -ftp,-smb默认集合减去 ftp 和 smb多次使用--proto a --proto b等价于--proto a,b结合 docs/cmdline-opts/proto.md、docs/cmdline-opts/proto-redir.md 与 docs/cmdline-opts/proto-default.md 三份官方选项文档以及上文引用的源码与测试用例你可以在自己的脚本和自动化流程中稳定地实现协议最小化策略将传输面收敛到真正需要的协议上。【免费下载链接】curlA command line tool and library for transferring data with URL syntax, supporting DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, MQTTS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET, TFTP, WS and WSS. libcurl offers a myriad of powerful features项目地址: https://gitcode.com/GitHub_Trending/cu/curl创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考