2

I have a form that takes multiple input fields and makes an API request via GET.

The fields are not properly sanitizing input and I am able to add arbitrary parameters to the query string by submitting input such as test&color=red.

Instead of some sort of encoding, the resulting API query looks like api.com/search?field=search&color=red

I cannot think of any malicious use to this, as anybody could just hit this endpoint directly or use a proxy to bypass any client side validation.

If you were performing an application review, is this something that might be worth calling out?

Improve this question
1
  • I'm wondering how you even submit that form: Upon native form submission, every modern browser urlencodes its form input values, so the HTTP request would end up as /search?field=test%26color%3Dred. Even in case that you use javascript to construct an XHR or similar, modern libraries would urlencode your values (see stackoverflow.com/questions/9713058/… for example)
    – lab9
    Jun 13, 2020 at 18:17

4 Answers 4

Reset to default
1

No. Client-side validation can be useful for performance or UX reasons, but it is not a security feature and its lack has no security impact whatsoever. Indeed, client-side validation can provide a false sense of security, so purely from a security perspective, I prefer to not see it.

Now, if the server is not processing the requests correctly - if adding new or malformed parameters can cause unexpected behavior, edit content that isn't escaped correctly in the response, or otherwise potentially have a security impact - that's of course something I would call out. The attack vector and mitigation wouldn't have anything to do with that client-side form though; the repro steps would simply be a URL to paste into the address bar of the browser, or perhaps use tools like curl or Burp Suite.

Improve this answer
0
1

This is typically classified as client side HTTP parameter pollution, https://portswigger.net/kb/issues/00501400_client-side-http-parameter-pollution-reflected. However it may not be exploitable through an API due to how the browser interacts with the endpoint.

It may be possible to leverage the additional parameters for other attacks such as cross site scripting as there is unlikely to exist meaningful server side validation for randomly named parameters, but again APIs don't fit the traditional browser/webpage model and exploitation may not be possible.

Improve this answer
1

If you were performing an application review, is this something that might be worth calling out?

From a security point-of-view, as you ("anybody could just hit this endpoint directly") and other answers state, this is not something the client can protect against. However, if you're not certain it is already addressed, it may be worth raising with the back-end/API developers to make sure that they are correctly "policing" the URLs sent to them.

From a functional point-of-view, there is almost certainly an issue that needs raising, as by not properly escaping user input, it is extremely likely that the search function will not be working correctly. While it's unlikely someone would really want to search for test&color=red, searching for M&S (Marks and Spencer's... a UK high-street chain of shops) or M&M (multi-coloured sweets) and so on is quite possible.

Improve this answer
1

It is not a threat (low, medium, high) unless you can exploit it. To determine threat severity you would need to take into account event likelihood and impact.

However, it could still be a recommendation to have input validation in place according to OWASP or any other methodology.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .