(Ovid) Re: CGI OO 'param' vs. hash

legLess wrote:

(I did a quick search/replace on the file and it nailed 115 instances (in ~700 lines) of $prm{'x'}, replacing them with $q->param('x').)

Are all 115 instances going to be called every time? For a 700 line script, I suspect not. Usually, when I get a script that size, it's a variety of different modes and not all are used on any particular invocation. I'm in tadman's camp on this one. Using the CGI object is cleaner because you'll probably use it anyway and why pass the data twice?

I am, however, concerned about something that I am seeing:

    my $q   = CGI->new();
...
    if ($q->param('action') eq 'Login') {
        if ($q->param('mid')) {    ############# <---- What's this?
            $q->param('warning') = 'Already logged in, bonehead.';
            show_member($q);
        } else {
            do_login($q);
        }
    }
[download]

What that seems to suggest is that I should take your form, save it to my box, make sure that it's pointing at your server, and insert a hidden field with the name 'mid' and with a value that evaluates as true. If I do that, your script thinks I'm logged in. At least, that's what the code snippet suggests. How does authentication occur here?

Cheers,
Ovid

Vote for paco!

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Comment on (Ovid) Re: CGI OO 'param' vs. hash Download Code

Replies are listed 'Best First'.
Re: (Ovid) Re: CGI OO 'param' vs. hash by legLess (Hermit) on Jul 10, 2001 at 00:02 UTC
Good eye, Ovid, and thanks for the reply. The `mid` is a member ID number that's returned from the `get_member` sub. It does it's work where the "`...`" snip is. Right now the `mid` comes right out of a cookie, so yes, you could edit your cookie and be logged in as whoever you chose. But this is nowhere near production yet; here are my plans: First, I may use session cookies, which will help a little. Second, I've got a `member_info` table, then a `logged_in_members` table with 3 columns: member id, login time, and hash. The hash is some sort of one-way random-looking collection of garbage characters (MD5, maybe), and it's what I'm going to store in the cookie. You login via SSL, then the cookie is set with said hash (different for every login). That'll be checked at each page request against the `logged_in_members` table to authenticate, then blown away from that table when (a) the user logs out, or (b) x time has passed. Regardless of what parameters are passed to the script, `mid` is set every time by the script itself - either a member id or 0 - it's never accepted as a CGI param. Potential problems: I'm not likely to run the entire site under SSL, so someone could sniff the hash value as it's being sent over HTTP to the server. This would allow them access to the member's info (no CC #s, ever), and allow them to request a password and/or email address change. Password and email changes will have to be authenticated by replying to an email sent from the server (or something similar, e.g. navigating to a link in that email which contains a "?verify=<hash>"). So the attacker would not only have to sniff the hash and setup their own cookie, but intercept the email coming from the server and reply to it. I know this is possible, but I consider it unlikely enough that the risk is acceptable. I don't know if this is the best possible method, but it's one I've seen recommended by people who seem to know what they're doing. I'm not a security expert, but it seems pretty good to me. What do you think? -- man with no legs, inc.	[reply]

Replies are listed 'Best First'.

Re: (Ovid) Re: CGI OO 'param' vs. hash
by legLess (Hermit) on Jul 10, 2001 at 00:02 UTC

mid

get_member

...

Right now the mid comes right out of a cookie, so yes, you could edit your cookie and be logged in as whoever you chose. But this is nowhere near production yet; here are my plans:

First, I may use session cookies, which will help a little.

Second, I've got a member_info table, then a logged_in_members table with 3 columns: member id, login time, and hash. The hash is some sort of one-way random-looking collection of garbage characters (MD5, maybe), and it's what I'm going to store in the cookie. You login via SSL, then the cookie is set with said hash (different for every login). That'll be checked at each page request against the logged_in_members table to authenticate, then blown away from that table when (a) the user logs out, or (b) x time has passed.

Regardless of what parameters are passed to the script, mid is set every time by the script itself - either a member id or 0 - it's never accepted as a CGI param.

Potential problems: I'm not likely to run the entire site under SSL, so someone could sniff the hash value as it's being sent over HTTP to the server. This would allow them access to the member's info (no CC #s, ever), and allow them to request a password and/or email address change. Password and email changes will have to be authenticated by replying to an email sent from the server (or something similar, e.g. navigating to a link in that email which contains a "?verify=<hash>"). So the attacker would not only have to sniff the hash and setup their own cookie, but intercept the email coming from the server and reply to it. I know this is possible, but I consider it unlikely enough that the risk is acceptable.

I don't know if this is the best possible method, but it's one I've seen recommended by people who seem to know what they're doing. I'm not a security expert, but it seems pretty good to me. What do you think?
--
man with no legs, inc.

[reply]