in reply to Re: Bad Practice
in thread Bad Practice

You also say that this code allows to create any variable he wishes. I've looked at the given code a few times, but I can't see what you see. Unless you see a way of the web user being able to manipulate %input, I don't see how he can.

Right after the call to readparse, there is a foreach which loops through %input and creates global variables for every element in the hash. As a contrived example, this could allow the browser to change the process name, by submitting a form containing <input type=hidden name="0" value="HA! HA! GOT YOU!">. If the rest of the code is as insecure as this, you could have a lot of fun with this site.

Replies are listed 'Best First'.
Re: Bad Practice
by Abigail-II (Bishop) on Feb 27, 2003 at 16:11 UTC
    Oh, I've seen that code. But please tell me, how is the web user able to manipulate %input? As far as I can tell. <input type = hidden name = '0' value = 'HA! HA! GOT YOU!'> causes $in {0} to be set to 'HA! HA! GOT YOU!'.

    I don't know which programming language you are using, but any Perl I've used so far uses more than 2 significant letters in indentifiers. %in is not at all the same as %input.

    Abigail

      But please tell me, how is the web user able to manipulate %input?
      Possibly I'm mistaken, but it seems to me that the first line of readparse() aliases the local glob *in to the argument of readparse, which is (in this case) the global *input.

      readparse(*input); sub readparse { local (*in) = @_ if @_; ... }

      So in fact, the variable %in within readparse is the same as the %input that isotope and jasonk are complaining about.



      If God had meant us to fly, he would *never* have given us the railroads.
          --Michael Flanders

      %in is not at all the same as %input.

      Unless they're aliased...

      readparse(*input); ... sub readparse { local (*in) = @_ if @_;

      ihb