nic-6443 opened a new pull request, #13787: URL: https://github.com/apache/apisix/pull/13787
### Description `ngx.var.uri` is percent-decoded, so `%0d%0a` in a client URI becomes raw CR/LF in it. The nginx template proxies with `proxy_pass $upstream_scheme://apisix_backend$upstream_uri;`, and nginx writes a Lua-set `$upstream_uri` into the upstream request line verbatim (no re-escaping). Two paths reach `$upstream_uri` with unescaped bytes: - `proxy-rewrite` `uri_safe_encode()`s only the path portion of the rewritten URI and concatenates the query portion (after `?`) raw. A CR/LF reflected from `$uri` / `$request_uri` / a regex capture therefore lands in the upstream request line — a header-injection / request-smuggling primitive against the upstream. - The `normalize_uri_like_servlet` path assigns the raw decoded URI to `upstream_uri` with no encoding at all. This adds `core.utils.escape_uri_control_chars`, which percent-encodes control characters (`0x00-0x1F`, `0x7F`, including CR and LF) while leaving `?`, `=`, `&` intact, and applies it to the query portion in `proxy-rewrite` and to the servlet `upstream_uri`. ### Checklist - [x] I have explained the need for this PR and the problem it solves - [x] I have explained the changes or the new features added to this PR - [x] I have added tests corresponding to this change - [x] I have updated the documentation to reflect this change (internal encoding change; no config/behavior change for well-formed URIs) - [x] I have verified that this change is backward compatible (only control characters, which are invalid in a request line, are now encoded) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
