in reply to CGI Security

Hidden fields are very, _VERY_, insecure, people can (and do) modify them. All they have to do is to save the form, edit it with their favorite text or HTML editor, load them in their browser et voila! They can now use the modified form with a field of their own. You really can't use this for any security related purpose. The only thing you can do is use a hidden field to store a session ID (random enough so people can't guess it), but even this can be intercepted and used to highjack a session.

Basic HTTP passwords are nearly as insecure, they are exchanged in an ecoded (but not encrypted) form, that's so close to clear text that it might as well be (something like BASE 64 encoded or something equally easy to decode). You can't rely on this either, unless you don't care much about what you are giving access too.

Of course if you are behind a firewall you can decide to trust your users, as they can be fired if they misbehave. If you really want the system to be secure you will have to use a secure protocol, usually HTTPS. You will just have to setup an HTTPS server.

Replies are listed 'Best First'.
Re: Re: CGI Security
by ant (Scribe) on Jun 22, 2001 at 17:41 UTC
    Hi,
    Thanks for your reply(and to everyone else who replied)
    In the last paragraph you mentioned secure servers.
    Does all data that's sent through a secure server have a higher
    level of encryption? Is it still possible for people to edit
    the hidden variables in a form and send it back to the server.
    And one final question whats is an ecoded form? And whats the
    difference between a ecoded form and an encrypted form.
    Thanks again for your help in advance.

    Anthony
[reply]

      "ecoded" is a typo, and I am surprised chipmunk did not notice it ;--( When I (tried to!) use "encoded" on the other hand I meant that although the data is not transmitted in clear text anybody can decode it without needing a secret password. I would use "encrypted" for data that, even if intercepted by evil creatures, could not be made sense of without additional information (a private password).

      In your case, if you don't trust your users the "hidden field holding the user name" trick will still be dangerous as a "legal" user could then guess another usrs login, change the form and act as if it were the other user. But regular authentication using a .htaccess file would work just fine I think.

[reply]
        Hi Mirod
        Thanks for the brief explanation. It's cleared up a misty
        point or two. Just a thought on the last paragraph really
        if a legal user came in to the directory through .htaccess,
        then they could enter someone elses username into the web page
        and submit that file, which makes .htaccess a little useless
        against legal users playing around with user names.
        Unfortunately user names are very easy to pick up through
        our organisation, as they are the same as the individual email name.
        I think the one way forward is to create a timestamp/username
        variable and enter that into a table/file when the user enters the
        system and to remove it after the person has left. Then
        when a person enters a web page, we take the user variable
        and check it against the user variable in the table/file.
        That seems like a more workable solution to me
        Many thanks for the info.
        Anthony
[reply]

In Section Seekers of Perl Wisdom