Review UriCompliance.LEGACY and its omission of SUSPICIOUS_PATH_CHARACTERS
#12809
Comments
joakime
changed the title
UriCompliance.LEGACY and its omission of SUSPICIOUS_PATH_CHARACTERS
joakime
added
the
Sponsored
|
@joakime I think the issue might be that the public static final UriCompliance LEGACY = new UriCompliance("LEGACY",
of(Violation.AMBIGUOUS_PATH_SEGMENT,
Violation.AMBIGUOUS_PATH_SEPARATOR,
Violation.AMBIGUOUS_PATH_ENCODING,
Violation.BAD_UTF8_ENCODING,
Violation.SUSPICIOUS_PATH_CHARACTERS,
Violation.UTF16_ENCODINGS,
Violation.USER_INFO));Then the following test passes in EE9 and EE10 in jetty-12.0.x: static Stream<Arguments> suspiciousCharactersLegacy()
{
return Stream.of(
Arguments.of(UriCompliance.DEFAULT, "o", "o"),
Arguments.of(UriCompliance.DEFAULT, "%5C", "400"),
Arguments.of(UriCompliance.DEFAULT, "%0A", "400"),
Arguments.of(UriCompliance.DEFAULT, "%00", "400"),
Arguments.of(UriCompliance.DEFAULT, "%01", "400"),
Arguments.of(UriCompliance.DEFAULT, "%5F", "_"),
Arguments.of(UriCompliance.DEFAULT, "%2F", "400"),
Arguments.of(UriCompliance.DEFAULT, "%252F", "400"),
Arguments.of(UriCompliance.DEFAULT, "//", "400"),
// these results are from jetty-11 DEFAULT
Arguments.of(UriCompliance.LEGACY, "o", "o"),
Arguments.of(UriCompliance.LEGACY, "%5C", "\\"),
Arguments.of(UriCompliance.LEGACY, "%0A", "\n"),
Arguments.of(UriCompliance.LEGACY, "%00", "400"),
Arguments.of(UriCompliance.LEGACY, "%01", "\u0001"),
Arguments.of(UriCompliance.LEGACY, "%5F", "_"),
Arguments.of(UriCompliance.LEGACY, "%2F", "/"),
Arguments.of(UriCompliance.LEGACY, "%252F", "%2F"),
Arguments.of(UriCompliance.LEGACY, "//", "400")
);
}
@ParameterizedTest
@MethodSource("suspiciousCharactersLegacy")
public void testSuspiciousCharactersLegacy(UriCompliance compliance, String suspect, String expected) throws Exception
{
startServer(new HttpServlet()
{
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
{
if (expected.length() != 3 || !Character.isDigit(expected.charAt(0)))
assertThat(request.getPathInfo(), is("/test/fo" + expected + "bar"));
}
});
_connector.getBean(HttpConnectionFactory.class).getHttpConfiguration().setUriCompliance(compliance);
if (compliance == UriCompliance.LEGACY)
_server.getBean(ServletContextHandler.class).getServletHandler().setDecodeAmbiguousURIs(true);
String request = "GET /test/fo" + suspect + "bar HTTP/1.0\r\n" +
"Host: whatever\r\n" +
"\r\n";
String response = _connector.getResponse(request);
if (expected.length() == 3 && Character.isDigit(expected.charAt(0)))
{
assertThat(response, startsWith("HTTP/1.1 " + expected + " "));
}
else
{
assertThat(response, startsWith("HTTP/1.1 200 OK"));
}
} |
|
I see. Seems like adding But what about the other behavior discovered with jetty-start? Doing that seemingly undid the other violations declared for LEGACY. Look for those 2 lines in the original issue text at the top of this issue, and read the actions before/after those lines to see the behavior I'm talking about. |
|
@joakime my test is not seeing those issues. It correctly continues to allow AMBIGUOUS_PATH_SEPARATOR and AMBIGUOUS_PATH_ENCODING in legacy mode. |
Jetty version(s)
12.0.16
Jetty Environment
Any
Java version/vendor
Any
OS type/version
Any
Description
The current
UriCompliance.LEGACYis missing behavior that is similar to theSUSPICIOUS_PATH_CHARACTERS(but not quite exactly that violation).Take for example, the following behavior on Jetty 11.0.24 ...
Configure a new jetty.base ...
Run that jetty.base ...
In a different console test a few suspicious character scenarios.
Now lets do the same thing on Jetty 12.0.16
Setup and Run ...
Do some initial testing ...
The suspicious path characters are being rejected due to existing LEGACY behavior.
So lets add it via configuration.
It is now allowing suspicious path characters, but rejecting the other violations???
So we have a few things to look into.
SUSPICIOUS_PATH_CHARACTERStoLEGACY(even though it doesn't decode like Jetty 9/10/11)SUSPICIOUS_PATH_CHARACTERS_WITH_AUTODECODE(or some similar name) to have the behavior be the same as Jetty 9/10/11 ?jetty.httpConfig.uriCompliance=LEGACY,SUSPICIOUS_PATH_CHARACTERSresetting the other prior LEGACY violations?The text was updated successfully, but these errors were encountered: