4

I received a failure on a vulnerability assessment because a heuristic determined I was probably processing query string parameters as form values (they used the words 'body parameters').

I think this is a false positive because MVC (the technology), similarly to other frameworks, routes GET and POST based on rules. The method which gets executed on GET is fundamentally detached from the form.

Also, AppScan seems to indicate that it determined this failure based on the "test response" being similar to the "original response". I can't find any information online to understand or address this issue.

  • Would you be able to show the scan information? – iZodiac Aug 17 '16 at 8:46
  • @iZodiac sadly, no. But there isn't much information. Here's the text: "Do not accept body parameters that are sent in the query string", suggestion: "Re-program the application to disallow handing of POST parameters that were listed in the Query". Short of registering some kind of dictionary of parameters, I'm not sure how I'm supposed to do that... – Sprague Aug 17 '16 at 8:50
  • Does this post here help? – iZodiac Aug 17 '16 at 8:52
  • @iZodiac No, but thanks. I could answer that question, though ;) – Sprague Aug 17 '16 at 8:54
  • The issue is that something can only be called a "body parameter" in the context of a single POST, but they want me to prevent GET methods from allowing parameters which are defined on the form for a POST method which is correlated somehow. In a Web forms page, they are intrinsically connected, in MVC they are only connected by convention. – Sprague Aug 17 '16 at 8:56
2

This vulnerability is considered "low" and has a CVSS score of 5.0. The pen test takes an existing page and simply changes the verb in the submit, passing the form payload in the query string. If the web site raises an error, or displays a page that is different from normal, it is a PASS. If the web site returns a page that is substantively similar to the normal page, it is a FAIL.

Handlers for POST requests often have different mitigations; for example, CSRF is often implemented for POST and not for GET. By changing the verb, an attacker could potentially bypass the check. An example can be found in the common vulnerability database, here, if you are curious if this is ever an issue.

You could actually have a vulnerability if you have used the ActionName attribute to map the GET and POST to different methods and the methods have different filters (e.g. POST has the AuthorizeAttribute and GET does not). That would be a pretty serious oversight and would need to be corrected before closing this issue.

On the other hand, this sort of test is likely to produce false positives, especially on pages where the posted content doesn't have an immediate effect on the user experience.

If I came across this report for an MVC site, I would just check to ensure there is a verb restriction on the action method, and then mark the item as "false positive" and move on, without thinking about it too much, for reasons that the OP has explained.

If there isn't a verb restriction, you will either need to add it (with an HttpPostAttribute), or come up with a justification as to why the page/handler is not sensitive or is not less vulnerable when accessed via GET.

0

"body parameters" is at least uncommon terminology. It may be not entirely wrong, if it is the terminology of the specific framework. In the common web development, there is no such thing.

The security flaw is here that an attacker can give here an sql query embedded in the form. For example, imagine a query like

SELECT 1 FROM users WHERE user='$_GET[user]';

If the attacker gives a string

anything'; UPDATE users SET password='cr4ck';

to the user field, by a scripted GET or POST request, he can change all of the passwords to 'cr4ck'.

The protection is quite easy, everything which is coming from the browser and goes to the db, should be sql-quoted. It is not so trivial if the framework you are using doesn't really likes this, for example it plays fifty times with the variables everywhere in the code until they will be made to a real sql query.

0

This vulnerability is considered "low" and has a CVSS score of 5.0. The pen test takes an existing page and simply changes the verb in the submit, passing the form payload in the query string. If the web site raises an error, or displays a page that is different from normal, it is a PASS. If the web site returns a page that is substantively similar to the normal page, it is a FAIL.

If you are using MVC you can add Attribute [HttpGet] or [HttpPost] for each method you are safe I mean this method will not respond if is requested as GET and you tag the method as HttpPost.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.