-
Bug
-
Resolution: Done
-
Major
-
1.2.9.Final
-
None
In the case of the http connector, the path is decoded without the encoded slash / anti-slash being interpreted. The HttpRequestParser component actually uses the ALLOW_ENCODED_SLASH option of the Undertow server to determine whether or not to decode them. By default the option is set to false. A CVE of type traversal path is also referenced in the source code to explain the presence of the option and its positioning to false (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE -2007 to 0450).
public HttpRequestParser(OptionMap options) { maxParameters = options.get(UndertowOptions.MAX_PARAMETERS, 1000); maxHeaders = options.get(UndertowOptions.MAX_HEADERS, 200); allowEncodedSlash = options.get(UndertowOptions.ALLOW_ENCODED_SLASH, false); decode = options.get(UndertowOptions.DECODE_URL, true); charset = options.get(UndertowOptions.URL_CHARSET, StandardCharsets.UTF_8.name()); } … private String decode(final String value, boolean urlDecodeRequired, ParseState state, final boolean allowEncodedSlash) { if (urlDecodeRequired) { return URLUtils.decode(value, charset, allowEncodedSlash, state.decodeBuffer); } else { return value; } }
In the case of the Ajp connector, we do not have the same preconceptions when decoding the url. The connector does not use the ALLOW_ENCODED_SLASH option. The AjpRequestParser used to build the exchange object (HttpServerExchange) will use a java.net.UrlDecoder to decode the url. The latter will interpret the slash / anti-slash characters encoded in the url.
io.undertow.server.protocol.ajp.AjpRequestParser
private String decode(String url, final boolean containsUrlCharacters) throws UnsupportedEncodingException {
if (doDecode && containsUrlCharacters) {
return URLDecoder.decode(url, encoding);
}
return url;
}
