url解码遇到%的问题

yinqin728

想实现的功能：如果用户输入中匹配到 <%，则阻断。

测试发现，curl访问http://localhost/test?a=<%时，只匹配到<，%丢失

spacewanderlzx

这跟百分号编码的规则相关。
参见 wikipedia 上的定义：
https://en.wikipedia.org/wiki/Percent-encoding#Percent-encoding_the_percent_character

在 2017年7月3日星期一 UTC+8下午3:49:24，yinq...@gmail.com写道：

想实现的功能：如果用户输入中匹配到 <%，则阻断。
测试发现，curl访问http://localhost/test?a=<%时，只匹配到<，%丢失

zchao1995

正如 Zexuan Luo 所说；如果还有疑问可以看看 nginx 的实现（ngx_http_process_request_uri）

On Monday, July 3, 2017 at 3:49:24 PM UTC+8, yinq...@gmail.com wrote:

想实现的功能：如果用户输入中匹配到 <%，则阻断。
测试发现，curl访问http://localhost/test?a=<%时，只匹配到<，%丢失

yinqin728

谢谢，大概查了下，%号后面如果不是两位16进制数会导致异常NGX_HTTP_PARSE_INVALID_REQUEST，所以%丢失。

假设想在openresty这块对内容包含<%xxx的请求参数进行拦截，比如a=<%mmm，而用户在浏览器中输入index.php?a=<%mmm（特意不输index.php?a=<%25mmm），由于%号丢失，所以参数a的值变为<mmm，导致拦截规则被绕过。

（对比PHP中，输入的参数是<%或者<%25，接受到的都是<%）

在 2017年7月3日星期一 UTC+8下午5:46:19，tokers写道：

正如 Zexuan Luo 所说；如果还有疑问可以看看 nginx 的实现（ngx_http_process_request_uri）
On Monday, July 3, 2017 at 3:49:24 PM UTC+8, yinq...@gmail.com wrote:
想实现的功能：如果用户输入中匹配到 <%，则阻断。
测试发现，curl访问http://localhost/test?a=<%时，只匹配到<，%丢失

zchao1995

$request_uri 这个变量指向了原始的 HTTP 请求行里的 URI，或许你可以使用这个变量来达到你的需求。

On Monday, July 3, 2017 at 8:56:58 PM UTC+8, yinq...@gmail.com wrote:

谢谢，大概查了下，%号后面如果不是两位16进制数会导致异常NGX_HTTP_PARSE_INVALID_REQUEST，所以%丢失。
假设想在openresty这块对内容包含<%xxx的请求参数进行拦截，比如a=<%mmm，而用户在浏览器中输入index.php?a=<%mmm（特意不输index.php?a=<%25mmm），由于%号丢失，所以参数a的值变为<mmm，导致拦截规则被绕过。

（对比PHP中，输入的参数是<%或者<%25，接受到的都是<%）

在 2017年7月3日星期一 UTC+8下午5:46:19，tokers写道：
正如 Zexuan Luo 所说；如果还有疑问可以看看 nginx 的实现（ngx_http_process_request_uri）
On Monday, July 3, 2017 at 3:49:24 PM UTC+8, yinq...@gmail.com wrote:
想实现的功能：如果用户输入中匹配到 <%，则阻断。
测试发现，curl访问http://localhost/test?a=<%时，只匹配到<，%丢失

agentzh

Hello!

2017-07-03 0:49 GMT-07:00  <yinq...@gmail.com>:
> 想实现的功能：如果用户输入中匹配到 <%，则阻断。
> 测试发现，curl访问http://localhost/test?a=<%时，只匹配到<，%丢失
>

RFC 要求所有字面 % 值都必须编码成 %25，否则就是非法的 urlencoded 序列。不同的实现对非法序列的处理方式不一样，因为
RFC 并没有定义遇到非法序列时的标准行为。比如很多 web browser 的 JS 实现会直接抛 JS 异常，而 nginx
则选择把孤儿 % 字符给直接吃掉，以避免注入攻击的风险。ngx_lua 模块在这里的处理方式和官方 nginx
核心是完全一样的。我不觉得这里有任何问题，因为是完全符合 RFC 标准的。

-agentzh

yinqin728

嗯，把孤儿%当成当成非法序列给吃掉这种方式本身没问题。

其实我现在碰到的一个场景是在ngx_lua这块对http请求参数做过滤，从而保护upstream模块指定的上游服务器，虽然ngx lua模块获取的参数值是剔除了孤儿%的，但是传送给upstream上游服务器其实还是把参数中的%带过去的。

如tokers所说，可以获取整个query_string后做处理，不过感觉两块如果一致的话处理起来会方便许多，也不会导致对上游服务器造成注入攻击。

在 2017年7月4日星期二 UTC+8上午1:04:09，agentzh写道：

Hello!

2017-07-03 0:49 GMT-07:00 <yinq...@gmail.com>:
> 想实现的功能：如果用户输入中匹配到 <%，则阻断。
> 测试发现，curl访问http://localhost/test?a=<%时，只匹配到<，%丢失
>

RFC 要求所有字面 % 值都必须编码成 %25，否则就是非法的 urlencoded 序列。不同的实现对非法序列的处理方式不一样，因为
RFC 并没有定义遇到非法序列时的标准行为。比如很多 web browser 的 JS 实现会直接抛 JS 异常，而 nginx
则选择把孤儿 % 字符给直接吃掉，以避免注入攻击的风险。ngx_lua 模块在这里的处理方式和官方 nginx
核心是完全一样的。我不觉得这里有任何问题，因为是完全符合 RFC 标准的。

-agentzh

agentzh

Hello!

2017-07-03 19:03 GMT-07:00  <yinq...@gmail.com>:
> 嗯，把孤儿%当成当成非法序列给吃掉这种方式本身没问题。
> 其实我现在碰到的一个场景是在ngx_lua这块对http请求参数做过滤，从而保护upstream模块指定的上游服务器，虽然ngx
> lua模块获取的参数值是剔除了孤儿%的，但是传送给upstream上游服务器其实还是把参数中的%带过去的。
> 如tokers所说，可以获取整个query_string后做处理，不过感觉两块如果一致的话处理起来会方便许多，也不会导致对上游服务器造成注入攻击。
>

自动把原始 url 带给后端应该是 ngx_proxy 模块的行为，和 ngx_lua 没有任何关系。如果你想强制 uri
的归一化，你应该使用 ngx.req.set_uri() 这样的 Lua API 来改写当前请求的 URI。

-agentzh