Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re: Unwanted parameter when executing CGI scripts

by sundialsvc4 (Abbot)
on Jan 04, 2013 at 16:12 UTC ( #1011666=note: print w/replies, xml ) Need Help??

in reply to [SOLVED] Unwanted parameter when executing CGI scripts

It also occurs to me to wonder, and with considerable alarm, “exactly what is it about your present algorithm which makes you care that an ‘extra’ parameter value is appearing in the data?”   Of particular concern to me is that perhaps the software is iterating through the parameters given and attempting to do something with them “no matter what they are,” on the very na´ve and very dangerous assumption that only the “expected” parameter-names could actually be there.   (PHP was most-notorious for this in its earliest days, when it would “helpfully” introduce every POST/GET variable that it saw, right into the variable pool.   “Helpful” indeed it was, if one is not thinking of malice, and of course it didn’t last long.   But there are still probably some vulnerable web-sites out there that are still being hacked because of it.)   Your application should know exactly what variable-names it might consider.   It should look only for submitted variables under those names, at the exclusion of any and all others.   It should, furthermore, validate each of these, using a regular-expression (say), before accepting any of them.   Never allow the user (which could well actually be a malicious “bot!”) to “stuff” anything into your application’s brain.

(Edit:   Parameter validation should always occur in two places.   First, the user interface should filter out typographic errors before attempting to submit anything to the host.   But second, the host should validate everything it receives, both syntactically then semantically.   I am of the opinion that, if anything is found to be wrong in second-stage verification, the host perhaps should throw-out all of it, and perhaps using 400 Bad Request.   Ditto the presence of “unexpected” parameters in the input, on the rationale that it is “a bug, at best” for them to be present.   The client-side validation is for user convenience (and to reduce network bandwidth); the second is for the server’s own protection and to facilitate the detection of legitimate errors “somewhere” in the software.   (Even in 100%-innocuous scenarios, the hardest thing about troubleshooting any problem is knowing that a problem exists.)

  • Comment on Re: Unwanted parameter when executing CGI scripts

Replies are listed 'Best First'.
Re^2: Unwanted parameter when executing CGI scripts
by Nocturnus (Beadle) on Jan 04, 2013 at 19:07 UTC

    Of course, you are right, and I have already implemented such checks at different levels of the application architecture.

    Nevertheless, there is one situation where script A just should "pass" all parameters to another script B. To be precise, A generates HTML code with <a href> to B, where the href's URI contains all parameters which had been included in the call of A. Generating this link is done by generic code which is in a module which is used by several of the scripts; thus, when generating the link, the parameters are not checked. This is no security problem since B will check it's parameters for correctness when called.

    In nearly all browsers, when moving the mouse to the generated link, the complete destination URI of the link, including the parameters, is visible (e.g. in the status bar). Now, if script A is called WITHOUT parameters (which is perfectly acceptable), the generated link to script B contained a query string ("?keywords=") where no query string should be.

    This worries users, makes debugging more complicated, and is ugly, so I would like to change that.

    I will do it the way which has been proposed above, but I was hoping that we could "configure" somehow to disable that behavour, or that there is another more elegant way.



Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1011666]
[shmem]: Discipulus: war/peace is a question of fuel gauge position...
[Discipulus]: yes i saw your cell brother..
[Discipulus]: but now fuel is cheap and they still make some war.
[Discipulus]: capitalism is able to go to war by cycle, even.
[shmem]: some? are you jokin' ?
[shmem]: fuel is only one fuel that fuels the fools... it is all about power and control - which NOBODY will have.

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (10)
As of 2017-04-29 22:02 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (534 votes). Check out past polls.