Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Login and CGI security ("open cookie jar") problem.

( #11246=categorized question: print w/ replies, xml ) Need Help??
Contributed by Novician on May 12, 2000 at 09:34 UTC
Q&A  > CGI programming


Description:

Let's say I login on the browser, and click a few times here and there on the web-server to do stuff. Then, I get distracted and go to a webmail site to retrieve and read my mail without closing the current browser. One of the messages has a link to an "evil" website, having malicious scripts, etc. When I click on the link, information about which websites I had visited before, my IP, etc., will be sent to the "evil" website. Using that data it's able to do malicious stuff on the server I visited last, since I had already logged on before. The "evil" website will be able to send commands to the server as me!

So, my question is.... How do you, webmasters, solve or prevent this problem? Is there a better way than prompting the user for their login ID and password everytime they go to restricted area on the web server, or webpage?

Answer: Login and CGI security problem.
contributed by httptech

It sounds like you're talking about the IE "open cookie jar" bug. If you're using IE, this could happen to you I suppose. It's definitely not a good thing to store usernames and passwords in cookies, but a lot of sites do it anyway.

The way I handle this problem is by using Apache's built in authentication modules. There's no information a hostile site could get from your browser (well, I don't know, IE seems to like to save passwords).

Anyway, the nice thing about letting Apache do the authentication step for you is that your scripts can just concentrate on the task at hand, instead of worrying about any holes you might have left in your authentication method. All you have to do is retrieve the $ENV{'REMOTE_USER'} variable and you can be pretty sure that's who you're dealing with.

Answer: Login and CGI security problem.
contributed by Anonymous Monk

You could also just dump the password and login id to the cookie jar, but encrypt them with a private key.

Answer: Login and CGI security problem.
contributed by turnstep

When I click on the link, information about which websites I had visited before, my IP, etc., will be sent to the "evil" website. Using that data it's able to do malicious stuff on the server I visited last, since I had already logged on before.

The only compromising data is the referrer, or the URL to which you had been to before. It cannot tell which "websites" you had visited before, only the previous page. Yes, your IP is known, but it is known anyway, to every site you visit, and to everyone you email. Furthermore, most (if not all) browsers only send the referring information if you click on a a link, not if the browser is invoked by an external program. So this is only an issue with web-based email readers.

In summary, there is nothing to worry about. Just don't put information like passwords into URLs when writing scripts (a bad idea for more than the reason mentioned here) and everything will be fine. I really doubt that any major web mail services do such a thing anyway. Such holes were patched a long time ago.

As to how to avoid them while writing scripts (which almost makes this a perl question, but not quite), just store password information on the server (best) and/or use cookies and/or use HIDDEN input tags.

Answer: Login and CGI security problem.
contributed by chromatic

Another option is to use a timestamp on the server. For every action the user attempts to take, check the last timestamp for that account. If it's been more than 10 minutes, require re-authorization. Otherwise, update the timestamp to the current time and perform the action.

Sure, there is a window of time where some tricky malicious scripting could redirect the client to do something unintended, but it's minimized somewhat here.

Answer: Login and CGI security problem.
contributed by DarkSniper

i hacked a quick perlscript that generates a certain value under one hour. This is all controlled by cookies. :)

my @time = localtime(); my $time_algo = 0; $time_algo = += $_ for @time[2..5]; my $salt = 'salty'; my $cipher = crypt($time_algo,$salt); if ($cipher ne $current_cipher){ #force to reidentify; }
good luck :)
Answer: Login and CGI security problem.
contributed by orkysoft

Remember the user's IP address for this session, and if requests from that user come from another IP address, re-request authorization.

Please (register and) log in if you wish to add an answer



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others pondering the Monastery: (7)
    As of 2014-09-02 20:51 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      My favorite cookbook is:










      Results (29 votes), past polls