You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Framework version: 1.0 (and the code in repository as of the time I'm submitting this)
Implementations: Spring
Scenario
If an AwsProxyRequest is submitted which
Is a POST with a Content-Type of application/x-www-form-urlencoded, and
Has its body content Base64-encoded instead of being "in the clear"
then the form parameters are not decoded properly.
AwsProxyHttpServletRequest properly respects base-64 encoding in situations where HttpServletRequest#getInputStream is used, however AwsProxyHttpServletRequest#getFormUrlEncodedParametersMap uses request.getBody() without checking to see if the body is Base64-encoded.
The offending code snippet:
Timer.start("SERVLET_REQUEST_GET_FORM_PARAMS");
String rawBodyContent = request.getBody();
urlEncodedFormParameters = new TreeMap<>(String.CASE_INSENSITIVE_ORDER);
for (String parameter : rawBodyContent.split(FORM_DATA_SEPARATOR)) {
Expected behavior
Before attempting to decode the parameters out of the body, getFormUrlEncodedParametersMap should check to see if the body of the AwsProxyRequest is Base64-encoded and, if it is, decode the body string before attempting to dissect the parameters.
Actual behavior
getFormUrlEncodedParametersMap fails to check for Base64 encoding of the body, and thus attempts to decode the base64-encoded body string. Since it doesn't see anything that looks like "field1=value1&field2=value2", it fails to transfer any of the parameters into the urlEncodedFormParameters member variable.
Steps to reproduce
AwsProxyRequest request = new AwsProxyRequest();
request.setHttpMethod("POST");
request.setPath("/an/appropriate/path");
request.setHeader("Content-Type", "application/x-www-form-urlencoded");
String body = Base64.getEncoder()
.encodeToString("field1=value1&field2=value2".getBytes(StandardCharsets.UTF_8));
request.setBody(body);
request.setIsBase64Encoded(true);
and then submit this request to an endpoint expecting a normal form post.
Full log output
No exception is generated - the parameters just "disappear."
The text was updated successfully, but these errors were encountered:
Scenario
If an
AwsProxyRequest
is submitted whichPOST
with aContent-Type
ofapplication/x-www-form-urlencoded
, andthen the form parameters are not decoded properly.
AwsProxyHttpServletRequest
properly respects base-64 encoding in situations whereHttpServletRequest#getInputStream
is used, howeverAwsProxyHttpServletRequest#getFormUrlEncodedParametersMap
usesrequest.getBody()
without checking to see if the body is Base64-encoded.The offending code snippet:
Expected behavior
Before attempting to decode the parameters out of the body,
getFormUrlEncodedParametersMap
should check to see if the body of theAwsProxyRequest
is Base64-encoded and, if it is, decode the body string before attempting to dissect the parameters.Actual behavior
getFormUrlEncodedParametersMap
fails to check for Base64 encoding of the body, and thus attempts to decode the base64-encoded body string. Since it doesn't see anything that looks like "field1=value1&field2=value2", it fails to transfer any of the parameters into theurlEncodedFormParameters
member variable.Steps to reproduce
and then submit this request to an endpoint expecting a normal form post.
Full log output
No exception is generated - the parameters just "disappear."
The text was updated successfully, but these errors were encountered: