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

okay, be gentle with me... I VI'd my first Perl script one whole week ago :D.

I'm tryin' to brew my own web based e-mail, more for the satisfaction and learning than the necessity (so i'm tryin to steer clear of too many CPAN modules and such, except for cgi.pm).

And since I would like it to actually be usable on, say, a public computer (gee... web based e-mail on a public computer?), I get the feeling that passing the username/pass as plaintext additions to the URL is probably not such a good idea :D.

So the question is this: how can I avoid doing that? I tried using POST to send the info, but that only works on the initial form. Since I display the headers first, with links to the 'meat' of the message, I need to know how to use POST with regular links.

However, if thats not do-able, how might I encrypt the data? Would I have to use Javascript or something? I'm not looking for 30 line snippits here (see above). Just some pointers as to where I should look.

Replies are listed 'Best First'.
Re: POST in anchor tags?
by erikharrison (Deacon) on May 14, 2002 at 17:14 UTC

    Yes you can imbed a POST in a link, using JavaScript. Don't.

    A POST is no more secure than a GET. You're still passing everything in plain text. The only difference is that POST is allowed to have side effects (changing data on a machine) and GET is not (getting a webpage). What you need is https, using SSL. Merlyn's Web Techniques column should be useful (especially the one on cookies) as well as Ovid's CGI course is very thorough in his treatment of security.

    And, as always, study prior art. Sourceforge has several similar projects, see what they are doing about security, and do more.

    Good luck

    Cheers,
    Erik
      The only difference is that POST is allowed to have side effects (changing data on a machine) and GET is not (getting a webpage).

      This is actually a little bit misleading. The difference between a GET an a POST is actually how the data is passed to the server, not how that data is interperated/used on the server. GET requests pass data along in the form of a query string appended to the uri. POST requests pass data along inline (can't think of a better word) with the HTTP request.

      GET requests have limitations to the size of the query string (varying from browser to browser and server to server), with the http 1.1 spec warning servers about handling uris longer than 255 bytes.

      I'm not aware of any limitation in size for POST requests.

      Any cgi script with sufficient system access can change data on the machine it runs on regardles the request type.

      That said, yours was a resourceful post with great links.

      Dug

        You are correct, of course. However, my point was to the reason for the different methods.

        Cheers,
        Erik
      You're right about the security issues and side-effects, I've written a small introduction to server-side programming that also explains this at: the difference between GET and POST

      -- Joost downtime n. The period during which a system is error-free and immune from user input.
      Hey, thanks guys.

      My security concerns at the MOMENT are simply that as i've got it now, the password is plainly visible to anyone who looks at the browser history, or even walks by the machine while its logged in.

      I'll definitely take a look at those links though. If for no other reason than to see that little padlock in the status bar :D.

      And thanks for clearin up the whole "POST/GET" thing, thats been confusing me.

      thanks again for your help

      -William

        One of the basic principles of Web Security is "don't trust the browser". For example, don't trust that the browser won't cache a POST request. In fact, major browsers DO cache POST requests - note that if you press the BACK button to a POSTed page, they give you the option of reposting form data.

        Cheers,
        Erik
Re: POST in anchor tags?
by Mr. Muskrat (Canon) on May 14, 2002 at 18:38 UTC

    Okay, you're writing a CGI script in perl and you want security.
    Have perl check for tainted data. (the -T command line option).
    Some advice that's not security related but good anyway, tell perl to show you warnings ( -w ) and errors (use strict).
    Something like:

    #!/usr/bin/perl -T use strict; use warnings;
    or:
    #!/usr/bin/perl -wT use strict;
    Update:Reworded the part about warnings and strict

    Who says that programmers can't work in the Marketing Department?
    Or is that who says that Marketing people can't program?