Parameter Pollution on 1 page

[sourabhkatti]

Trace UUID: 24TB-QCNL-GRRN-RL60

https://apptwo.contrastsecurity.com/Contrast/static/ng/index.html#/f7ea7169-d4eb-42c4-b32e-5c0ea0ca9733/vulns/24TB-QCNL-GRRN-RL60/overview

Description

We observed 1 page which contained form elements that did not have action set to a specific URL:

/WebGoat/CrossSiteScripting.lesson.lesson

Risk

The application has a <form> tag that doesn't specify an action attribute. In some forms, this won't present a security issue. However, in forms containing sensitive information, this can be a very dangerous pattern that can be exploited by users looking to attack other users.

Consider the following statement from the Java Servlet Specification (Version 3, Section 3.1):

Data from the query string and the post body are aggregated into the request parameter set. Query string data is presented before post body data. For example, if a request is made with a query string of a=hello and a post body of a=goodbye&a=world, the resulting parameter set would be ordered a=(hello, goodbye, world).

The short version of that is this: URL parameters come first in Java EE - and the first URL parameter comes first.

Next, let's talk about <form> actions. If no action is specified, browsers assume that the form should submit to the current URL (the one in the address bar).

Now, let's imagine a site that has a change password form, located at /app/password/change::

<form method="POST">
<input type="password" name="pass1">
<input type="password" name="pass2">
<input type="submit" value="Change Password!">
</form>

An attacker could send a malicious link to this user, e.g.,/app/password/change?pass1=hacked&pass2=hacked. If the user clicks on this link and submits the form, the data will be submitted to the URL supplied by the attacker - with the attacker's chosen parameter values in the querystring.

Now, remember the spec? When the application receives the POST form submission, it will attempt to get the pass1 and pass2 parameters. Because the URL parameters will get preference over the POST parameters, the application will change the victim's password to hacked!

Recommendation to fix this finding

The fix for this issue is easy: make sure every <form> tag has an action attribute specified! If you have a <form> tag that you always want to submit to the current URI, but don't want to be vulnerable, considering using a snippet of JSTL to hardcode the action to the current URI:

<form method="POST" action="<c:out value="${pageContext.request.requestURI}"/>">
<input type="password" name="pass1">
<input type="password" name="pass2">
<input type="submit" value="Change Password!">
</form>