Hello,
There is a pentest result showing that a malformed login request can return detailed internal error information in the HTTP response.
This question is about the guidance in this forum thread:
https://forums.smartclient.com/forum...error-messages
That thread says that to cover both normal DSRequest exceptions and more unusual cases, these two settings should be added to `server.properties`:
Testing was done with Burp Suite by capturing a normal login POST request, sending it to Repeater, and then modifying the request query to deliberately malform the `isc_rpc` value.
Case 1
In one application, these two flags were present, and this malformed login request was sent through Burp Suite Repeater:
The response was a verbose `400` page, containing internal details such as the request URI, servlet name, exception class names, and stack trace.
Case 2
A standalone minimal test case was created as a Spring Boot + embedded Jetty showcase app with the same two flags set to `false`.
A valid baseline login request was first captured in Burp Suite, then the request line was changed in Repeater to:
The response was:
[HTML]
HTTP/1.1 400 Bad Request
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 5897
Connection: close
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
<title>Error 400 Unable to parse URI query</title>
</head>
<body><h2>HTTP ERROR 400 Unable to parse URI query</h2>
<table>
<tr><th>URI:</th><td>/CustomerLogin</td></tr>
<tr><th>STATUS:</th><td>400</td></tr>
<tr><th>MESSAGE:</th><td>Unable to parse URI query</td></tr>
<tr><th>SERVLET:</th><td>customerLoginServlet</td></tr>
<tr><th>CAUSED BY:</th><td>org.eclipse.jetty.http.BadMessageException: 400: Unable to parse URI query</td></tr>
<tr><th>CAUSED BY:</th><td>org.eclipse.jetty.util.Utf8Appendable$NotUtf8Exception: Not valid UTF8! byte Bf in state 0</td></tr>
</table>
<h3>Caused by:</h3><pre>
org.eclipse.jetty.server.Request.getParameters(Request.java:467)
org.eclipse.jetty.server.Request.getParameterMap(Request.java:1078)
com.ricoh.test.showcase.CustomerLoginServlet.doPost(CustomerLoginServlet.java:18)
...
</pre>
</body>
</html>
Case 3
In the earlier working application from below thread
https://forums.smartclient.com/forum/smart-gwt-technical-q-a/242077-disabling-verbose-error-messages
The same type of malformed login-style request was sent through Burp Suite Repeater:
That application returned only a minimal 400 response, and after removing these two flags, the same malformed request still returned the same minimal response.
Could you please clarify:
Thanks.
There is a pentest result showing that a malformed login request can return detailed internal error information in the HTTP response.
This question is about the guidance in this forum thread:
https://forums.smartclient.com/forum...error-messages
That thread says that to cover both normal DSRequest exceptions and more unusual cases, these two settings should be added to `server.properties`:
Code:
servlet.sendStackTraceToClient: false exception.returns.stacktrace: false
Case 1
In one application, these two flags were present, and this malformed login request was sent through Burp Suite Repeater:
Code:
POST /CustomerLogin?isc_rpc=12345""");|]%00{%0d%0a<%00>%bf%27&isc_v=v12.1p_2022-07-19&isc_xhr=1 HTTP/1.1
Case 2
A standalone minimal test case was created as a Spring Boot + embedded Jetty showcase app with the same two flags set to `false`.
A valid baseline login request was first captured in Burp Suite, then the request line was changed in Repeater to:
Code:
POST /CustomerLogin?isc_rpc=12345""");|]%00{%0d%0a<%00>%bf%27&isc_v=v12.1p_2022-07-19&isc_xhr=1 HTTP/1.1
Host: localhost:8082
Content-Length: 36
Content-Type: application/x-www-form-urlencoded
username=admin&password=Password1%3F
[HTML]
HTTP/1.1 400 Bad Request
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 5897
Connection: close
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
<title>Error 400 Unable to parse URI query</title>
</head>
<body><h2>HTTP ERROR 400 Unable to parse URI query</h2>
<table>
<tr><th>URI:</th><td>/CustomerLogin</td></tr>
<tr><th>STATUS:</th><td>400</td></tr>
<tr><th>MESSAGE:</th><td>Unable to parse URI query</td></tr>
<tr><th>SERVLET:</th><td>customerLoginServlet</td></tr>
<tr><th>CAUSED BY:</th><td>org.eclipse.jetty.http.BadMessageException: 400: Unable to parse URI query</td></tr>
<tr><th>CAUSED BY:</th><td>org.eclipse.jetty.util.Utf8Appendable$NotUtf8Exception: Not valid UTF8! byte Bf in state 0</td></tr>
</table>
<h3>Caused by:</h3><pre>
org.eclipse.jetty.server.Request.getParameters(Request.java:467)
org.eclipse.jetty.server.Request.getParameterMap(Request.java:1078)
com.ricoh.test.showcase.CustomerLoginServlet.doPost(CustomerLoginServlet.java:18)
...
</pre>
</body>
</html>
Case 3
In the earlier working application from below thread
https://forums.smartclient.com/forum/smart-gwt-technical-q-a/242077-disabling-verbose-error-messages
The same type of malformed login-style request was sent through Burp Suite Repeater:
Code:
POST /login?isc_rpc=12345""");|]%00{%0d%0a<%00>%bf%27&isc_v=v12.1p_2022-07-19&isc_xhr=1 HTTP/1.1
Could you please clarify:
- Should these two settings be expected to affect malformed login requests where the query string itself is invalid?
- Is there any known change since that guidance was posted that would explain why these settings now seem not to affect this type of malformed request in some applications?
- If the earlier working application still behaves safely even after these two settings are removed, is there some additional mechanism or layer that would explain the difference?
Thanks.
Comment