in reply to How many security holes can you find?

Here is a brief list
  1. line 1 - no -T and no -w
  2. line 2 - no "use strict;" (and no "use warnings;")
  3. line x - variable scoping issues (very bad)
  4. line x - no style (perltidy should be run)
  5. line x - comments are either incomplete or useless (see line 142-146 for example, the comment is "# Clean up" followed by $sth->finish();)
  6. line 42 - he prints $name, no entities escaping is done -- he does this EVERYWHERE
  7. line x - no cleaning of any param values is done -- hello spam relay
  8. line 97 - use of `date '+%D'` -- what's next, he's gonna shell out for sort?
  9. line 125 - like with the spam relay, his database is open to corruption (this makes me think DBI ought to protect idiots from themselves like java does with executeQuery/executeUpdate)
  10. line 189 - needless repetition - if he doesn't know my can take a list, he doesn't know many other things
  • Comment on Re: How many security holes can you find?

Replies are listed 'Best First'.
Re: Re: How many security holes can you find?
by hossman (Prior) on Sep 15, 2003 at 00:13 UTC
    7. line x - no cleaning of any param values is done -- hello spam relay

    While I agree that cleansing input is important, it seems unfair to label this script as a "spam relay".

    I haven't read every line of this script, but from what i can see the emailing functionality is used in 3 places. 2 of these are messages sent to hard coded email address, (yeah for common sense). THe third is in fact sent to an address specified via the form input -- but since the point of the script is to send an email confirming that the address is valid for registration, there's not a lot of ways arround that.

    The email sent will definitely contain information about where it came from, including why it was sent, and how to "Opt Out" -- including a phone number (which I have to applaud the inclusion of). In fact, the only means a malicious user has to infuence the body of this message is via "$name ... and that's not even a value they are allowed to submit directly, it must be the "username" portion of the email they want to send.

    This script may have a lot of issues, but being an open relay doesn't seem to be one of them.

[reply]
[d/l]
Re: Re: How many security holes can you find?
by Anonymous Monk on Sep 14, 2003 at 21:43 UTC
    I almost forgot, he also does "use Socket;" (line 29), but doesn't directly use anything Socket exports.
[reply]
      I get the impression the coder assumed checking HTTP_REFERER made the email address, et. al, safe, since they must have come from the right form.

      Learning to string together working Perl is one thing. In fact, it's pretty easy. Learning the ins and outs of HTTP and how to prevent easy exploitation is another thing.

[reply]
        Learning the ins and outs of HTTP and how to prevent easy exploitation is another thing.
        dragonchild asked how many security holes can you find?. He then goes on to mention bugs -- not using strict/warnings/tainting are all bugs/security holes.
[reply]

In Section Meditations