POST accepted as GET

[stonebranch2]

Hi Isomorphic,

Do you have anything in place for the IDACall servlet to prevent a POST from being accepted as a GET?

For example, if one were to intercept the POST request,

POST /contextPath/application/sc/IDACall?isc_rpc=1&isc_v=v10.1p_xxxx-xx-xx&isc_xhr=1

and change it to a GET request,

GET /contextPath/application/sc/IDACall?isc_rpc=1&isc_v=v10.1p_xxxx-xx-xx&isc_xhr=1&isc_tnum=10&_transaction=xxx...xxx&protocolVersion=1.0

In this case, the framework appears to accept the GET request, with no distinction between POST and GET parameters.

I have an idea of how one might prevent this from a deployment configuration perspective, however, wanted to get your recommendation on this matter.

Thanks

[Isomorphic]

By design we accept either GET or POST, because GET is needed for APIs like DataSource.getFileDownloadURL(), among other scenarios.

You could simply subclass IDACall and reject GET requests but you would break a few features.. it wouldn't be easy to give you a list of affected features because we have simply assumed this protocol was available for a while.

Why is this a problem for you?

[stonebranch2]

Hi Isomorphic,

A third party assessment flagged the collapsing of the POST and GET parameters into a single collection, which ultimately allowed their modified GET request to manipulate data, no differently than the POST.

Without having to modify code, we can enforce that only POST requests be allowed for URL pattern /applicationName/sc/IDACall/* using a <security-constraint> in the web.xml, or alternatively, implement a code change in our subclass like you mention, however, we had the concern that either of these might break some functionality, which sounds like a possibility. On that note, a quick validation didn't show any breakage yet.

If we knew generally what might break if we restricted anything other than the POST method for the IDACall servlet, that would be helpful.

Thanks

[Isomorphic]

You haven't answered why this is a concern. It sounds as though it may be a concern about the possible effeftiveness of a phishing or similar attack, but several other security mechanisms (such as CSRF tokens) would need to fail before it would matter that requests can be made via GET as well as POST.

If you were concerned about modification requests in particular, you could just block such requests if they originate from a GET.

As far as features that will break, there's getDownloadFileURL(), and some comm modes (hiddenFrame) which are used when xmlHttpRequest is not available. Future features or browser bug workarounds may also require GET requests.

[stonebranch2]

Hi Isomorphic,

I understand that, by itself, the designed behaviour may not be an issue, understanding that protection for other vulnerabilities is in place, however, we are taking a vigilant approach to reviewing the provided recommendation, specifically, the following.

a) The GET request should not modify the data.
b) The GET and POST parameters should not be collapsed into a single collection with no distinction between them.

If you were concerned about modification requests in particular, you could just block such requests if they originate from a GET.

Blocking modification requests originating from a GET would be a reasonable thing to do here, with the understanding certain functionality, or a future workaround, may be impacted.

Thank you for your feedback.

Regards