Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

CGI Security

by ant (Scribe)
on Jun 22, 2001 at 16:19 UTC ( #90687=perlquestion: print w/replies, xml ) Need Help??

ant has asked for the wisdom of the Perl Monks concerning the following question:

Hi I've been asked to investigate security problems with web pages that I've been working on.
One set of pages uses the .htaccess file in the directory,
thus the user is asked for a user name and password before accessing
any web pages in that directory or sub directory. How secure
is .htaccess. Is the user name and password encrypted when
it sent to the server and how safe/good is the encryption.
The server is sitting behind the firewall, which means people outside
of the organisation cannot access/view it, which must be a good thing.

The second set of pages takes a username from a main login screen
and inserts it in to a hidden field, which I know is not hidden because
it can be seen in the source code.
This username is then passed as a variable to a new screen via
POST method, and is checked against a database. Is it possible for
for a user to access a web page with out going through the main login
screen, and inserting a username in the parameters???
Many thanks in advance.


ps I know the Perl faq on security tips
Q41: Can people see or change the values in "hidden" form variables?
does answer part of the second problem, but I do not know,
or understand how a user can replace variables that are posted.

Replies are listed 'Best First'.
Re: CGI Security
by mirod (Canon) on Jun 22, 2001 at 16:46 UTC

    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.

      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.


        "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.

Re: CGI Security
by Sifmole (Chaplain) on Jun 22, 2001 at 16:36 UTC
    Q41: Can people see or change the values in "hidden" form variables? does answer part of the second problem, but I do not know, or understand how a user can replace variables that are posted.

    If the FORM uses the GET method, then the variables will be visible in the Location bar of the browser; A user could then simply edit them.

    If the FORM uses the POST method, the user can save the page to their hard drive, edit the source to change the values, then submit from that edited version of the page.

    Short answer -- Yes people can see and change values in "hidden" form variables.

Re: CGI Security
by BigJoe (Curate) on Jun 22, 2001 at 16:40 UTC
    About your question about the hidden variables: They can be changed. If a user goes into their cache in IE they can actually change the page and go "back" to it. Then they can submit it with any info they want. A very good replacement for this is to use session variables. This stores the information on the server (away from the user) for the scripts.

    If you don't want to do this I suggest when someone logs on to the website have it generate a key and use that in the hidden feild. Log this key into the DB then use that for authentication. Also add a Timestamp into the DB to allow for login timeouts.


    Learn patience, you must.
    Young PerlMonk, craves Not these things.
    Use the source Luke.
(arturo) Re: CGI Security
by arturo (Vicar) on Jun 22, 2001 at 17:06 UTC

    Just to add a strategy you might employ to deal with the fact that hidden form fields aren't really a form of security (they're more for the convenience of the user and the programmer than anything else).

    If you know in advance which fields are going to be hidden, you can generate an MD5 hash (see Digest::MD5) of that data which will serve as a 'fingerprint' of the values in those fields. You should generate this fingerprint by concatenating all the strings that end up in those fields with a value the user never sees, so it's not so easy for the user to fake your program out by generating their own hash.

    Save that value away when you generate the form, and compare it to the MD5 fingerprint of the data that actually gets submitted. Of course, you'd need to be able to link the submitted values with the form that was generated. That would require generating a (random as possible) ID for the form: e.g. the form gets the ID (stored as another hidden field, purely for convenience) '120897af987dfaf6kl3h4987', and you can store that key in some sort of database (a flat file will do for simple setups), along with the data fingerprint. By the way, MD5 is good for generating these IDs, too!

    This is a variant on the session ID strategy that mirod mentioned; it has a *slight* advantage over the session strategy in that the sessions are *so* short (really, they last for just two HTTP requests) that the possibility of hijacking virtually disappears.

    Hmm, that's a lot of stuff there. If I confused you (I confused myself a bit!), feel free to /msg me in the chatterbox.

    perl -e 'print "How sweet does a rose smell? "; chomp ($n = <STDIN>); +$rose = "smells sweet to degree $n"; *other_name = *rose; print "$oth +er_name\n"'
Re: CGI Security
by Beatnik (Parson) on Jun 22, 2001 at 20:38 UTC
    HTTP never was designed to be secure, since they never expected it to boom like it did. IIRC older HTTP version had commands like DELETE and PUT. Web Client Programming with Perl is outdated, but a good resource on how things used to be

    ... Quidquid perl dictum sit, altum viditur.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://90687]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (3)
As of 2023-09-30 22:07 GMT
Find Nodes?
    Voting Booth?

    No recent polls found