in reply to Re: Re: Insecure dependency message ?
in thread Insecure dependency message ?

So there is your problem Read up on the man page, it's far more comprehensive compared to what I'll cut-paste for you....

From the man page

The only way to bypass the tainting mechanism is by referencing subpatterns from a regular expres- sion match. Perl presumes that if you reference a substring using $1, $2, etc., that you knew what you were doing when you wrote the pattern. That means using a bit of thought--don't just blindly untaint anything, or you defeat the entire mechanism. It's better to verify that the variable has only good characters (for certain values of "good") rather than checking whether it has any bad characters. That's because it's far too easy to miss bad characters that you never thought of.
If $input is 12345, and 12345 comes from $cgi->param(....), then a simple regexp pattern of... 
if($input=~/(\d+)/) { $input = $1; }
else{ $input = undef }

[download]
Your regexp should test and assign out the various ()'s. You can do 3 ()'s at a time, or just one... but only assign $1... $9 ONLY if your regexp matches. doing $input=~/(...)/ and then $input = $1 without an if statement might screw things up BIG time. $1 gets assigned on a successful match. It doesn't get undef'd if a match is unsuccessful.

You don't have to copy $1 back to $input either. I only did it to create less variables. You can do $verifiedInput = $1 too. But remember to program around the cases when the regexp matches or doesn't.


Play that funky music white boy..

Replies are listed 'Best First'.
Re: Re: Re: Re: Insecure dependency message ?
by peterr (Scribe) on Jan 06, 2004 at 04:52 UTC
    Hi sporty,

    So there is your problem Read up on the man page, it's far more comprehensive compared to what I'll cut-paste for you....

    Looks like I'll have to read up on regexp as well as taint. Also, "what to do" when error messages appear. At present, the user sees some strange message, but I don't see a thing. Maybe a quick email to me, or some (quick) data into MySQL. The problem in this case is we lost an order, because the user can only get _that_ far by pressing "Confirm order". We have no details anywhere of who the person was, not even the email address, let alone the order details. :(

    Thanks,

    Peter

[reply]
      Welll, all I can tell you is to have your code rigerously tested. have it tested. QA people would test it under various types of load, various types of input and what not. It's prolly a really silly bug somewhere that, w/o the entire script and a lot of time, we can't easily help you with. It's one of those cases where you find out how the error wsa brought around, try and reproduce it and the likes.

      Play that funky music white boy..
[reply]
        Hi Sporty,

        Yes, if I can reproduce the error , that will help a lot. Also I don't like the code where errors just spit out a msg to the user (browser), as it doesn't help the user, and I never know about it. The user probably goes to another site. For a Perl beginner like me, it's a large script, I've added a few extra modules, but as I inherited it, there are things I don't like about it. Sometimes hard to test someone elses code, because their objectives were different then. That said, I need to write down what I don't like with it (like what happens if the user closes the browser window before ALL the processing is done , ... yikes ??), and set about to rigoursly test it.

        Peter

[reply]

In Section Seekers of Perl Wisdom