So there is an application that accepts some data from the outside. Assuming that it accept only finite number of different POST/GET parameters and the application is correctly handling all the data sent with these parameters, is there a way to exploit an application sending additional parameters.

By this I mean the following: assuming my application accept only one post parameter 'number', is there a way to somehow send other parameters (may be too many parameters, or may be too big parameters) to exploit the application?

The question is not language/server specific.

3 Answers 3


Under normal circumstances, your application should solely only handle the parameters you expect. If you use a framework though, there might be additional security problems such as "Mass Assignment" (good -read on Ruby on Rails' -dated- security problem).

But, as in your example, if the application is only accepting "number" as a POST argument, it should not handle anything else.


There are some cases where this can be exploited. One example I've seen is where the application echoes an entire GET request into the body of the resulting page, for example in a link field or some tracking code.

If this is done and the URL isn't encoded properly there could be an XSS issue from a parameter that your application doesn't use.


Yes, certainly. There's Insecure Object Mapping, which is a more general term for "Mass Assignment" in @m1ke's answer.

In your case it may be possible to exploit the application by including two number parameters.

e.g. https://www.example.com?number=1&number=2 (this is a GET, but the same applies for POST).

it all depends on how the application handles it. Some frameworks may make the first parameter available to the application (1), some may make the second available (2) and some may provide both (1,2). However, the latter is often equivalent of the query string simply being number=1,2.

Where a vulnerability could lie is if the query string is parsed in two different ways at different points. For example an authorisation script may be written using one framework that checks whether the current user has permission to access the number provided. This framework takes the first query string value (1). However, the framework that handles the number for backend processing takes the last number provided (2), giving an attacker a way to bypass the authorisation check.

As you say, it may be possible for an exploit to exist where there is a large single query string value, or that there are many parameters provided. Any vulnerabilities here would likely to be down to the web server and server side technology stack itself and there have been such exploits discovered.

You must log in to answer this question.

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