URI不规范编码解决方案

RFC 7230
与 RFC 3986
定义了 HTTP/1.1 标准并对 URI 的编解码问题作出了规范。但是,文本形式的规范和最终落地的标准之间总是存在着差距。标准中共 82 个字符无需编码。

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789:/?#@!$&'()*+,;_-.~

对于需要编码的字符,百分号编码方案要求 ASCII 字符表示成两个 16 进制值并添加前缀 %
;对于非 ASCII 字符, 需要转换为 UTF-8 字节序, 然后每个字节按照上述方式表示成两个 16 进制值并添加前缀 %
。比如 |
将被表示为 %7C
%7c
(大小写无关);
将被表示为 %E5%95%8A

最近因为 Tomcat 版本升级,遭遇了非标到标准实现的过渡,新版本 Tomcat 严格执行 RFC 规范直接将非标准的 URI 请求强制拒绝。

2020-07-15 16:02:12,931  INFO 1 --- [http-nio-8080-exec-7] o.a.c.h.Http11Processor                  : Error parsing HTTP request header
 Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
        at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:468) ~[tomcat-embed-core-9.0.22.jar!/:9.0.22]
        at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:294) [tomcat-embed-core-9.0.22.jar!/:9.0.22]
        at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) [tomcat-embed-core-9.0.22.jar!/:9.0.22]
        at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:853) [tomcat-embed-core-9.0.22.jar!/:9.0.22]
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1587) [tomcat-embed-core-9.0.22.jar!/:9.0.22]
        at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-9.0.22.jar!/:9.0.22]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_161]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_161]
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-9.0.22.jar!/:9.0.22]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_161]

Tomcat 侧解决方案

由于是 Tomcat 升级带来的问题,回退版本是最简单但无奈的选择。但这不是理想的解决方案。

Tomcat 为了兼容非标准实现的浏览器请求编码,额外释出了两个配置选项 RelaxedPathChars
/ relaxedQueryChars
分别用于对 URI Paths 和 URI Query 放松限制。通过配置 server.xml
Connector
允许自定义放过 " < > [ / ] ^ /
{ | }` 中的一种或多种字符。

<Connector 
    connectionTimeout="20000" 
    port="8080" 
    protocol="HTTP/1.1" 
    redirectPort="8443" 
    relaxedQueryChars='^{}[]|' 
    relaxedPathChars='{}'
/>

至于 Spring Boot 内嵌的 Tomcat 容器,可以通过主动声明 Web 服务器工厂实例来配置

@Bean
public ConfigurableServletWebServerFactory webServerFactory() {
    TomcatServletWebServerFactory factory = new TomcatServletWebServerFactory();
    factory.addConnectorCustomizers(connector -> {
        connector.setProperty("relaxedPathChars", "[]|");       // 添加需要的特殊符号
        connector.setProperty("relaxedQueryChars", "|{}[]");    // 添加需要的特殊符号
    });
    return factory;
}

反向代理服务器 NGINX 侧解决方案

Tomcat 在新版本中限制部分未编码字符的使用,是为了解决 HTTP 请求走私漏洞。放松对此类字符的限制无疑是主动交出大门钥匙。

浏览器的非标准实现方案无法规避。但对于我们现有的部署架构,NGINX 作为最外侧的服务,提供反向代理。在 NGINX 侧可以将非标 HTTP 请求标准化。

由于 NGINX rewrite 模块对特定字符全量替换支持度不足,引入了 Lua 模块来实现对特定字符 |
的编码处理,其他字符也可采用类似的方式来解决。

location / {
    rewrite_by_lua_block {
        local escape_args = string.gsub(ngx.var.args, "|", "%%7C")
        ngx.req.set_uri_args(escape_args)
    }

    proxy_pass http://k8s;
}

原文 

https://www.ffutop.com/posts/2020-07-25-non-standard-uri/

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » URI不规范编码解决方案

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址