Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Mod_Perl Handlers And Getting Rid Of Sessions In The URL

by Revelation (Deacon)
on Sep 15, 2002 at 02:51 UTC ( [id://197980]=perlquestion: print w/replies, xml ) Need Help??

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

I've been working on maintaining state in mod_perl, and converting parts of my mod_perl script into a mod_perl handler to do the bulk of the maintenance; however, a problem has come up. While working on the mod_perl handlers, I began reading the book "Writing Apache Modules With Perl And C." - This gave me some incite on Session ids via an added parameter to the URL, which I had implemented in my old scripts, by just parsing the state parameters in the URL. (My reason for this was to preserve utmost flexibility in the type of users and browsers I would be able to take, as not all people are in love with the infamous cookie.)

'A more serious potential problem with URI-based session IDs is that under some circumstances it is possible for the session ID to "leak" to other sites via the HTTP referrer header (which, for historical reasons, is spelled "Referer").'

Being a mod_perl novice (one who doesn't use the inherent power of the Apache module(s)), I was stuck. I resolved to study a little bit more of mod_perl in the hope of finding some way to change the URL on the user's browser from what it was previously, while still keeping the user's session id, usable to the real script. I went on to read about Redirecting While Maintaining Environment Variables', which used the internal_redirect(), and subprocess_env() functions to change the URI, but allow me to keep the pertinent environmental variables.

I was doomed to keep looking, when I realized that internal means that it won't show externally (how sad). My current line of thought is using a perltranshandler to strip the session information from the site, and then somehow use an ub3r-uri() to change the URI to the user's browser (which from my understanding uri() does not do), while maintaining the session id. Any advice for a poor mod_perl novice, who can't figure out the answer to his seemingly simple problem? I can only hope that the solution is simple, and that I just haven't read enough to find it.

PS: I have heeded merlyn's advice, and made sure that all important functions can only be used five minutes from the last cache hit, but I still feel that it's better to be safe than sorry...
Gyan Kapur
gyan.kapur@rhhllp.com

Replies are listed 'Best First'.
Re: Mod_Perl Handlers And Getting Rid Of Sessions In The URL
by perrin (Chancellor) on Sep 15, 2002 at 05:50 UTC
    This actually has nothing to do with mod_perl -- CGI, Java servlets, C modules, etc. all have the same problem when putting sensitive information in the URL. There is no perfect solution for it, only hacks that work for some browsers. You could make every user go to a special "exit" page when following any off-site link. This page would contain a link to the URL they want to go to and the URL for the page would not contain the private information. You can put a META REFRESH tag in it to get the browser to go to the URL right away. However, some browsers won't support that and will leave your users looking at this exit page. If you do the redirect from the exit URL on the server side with a Location header, some browsers will send the previous URL (with the session ID) as the referer. There is some discussion of this here.
Re: Mod_Perl Handlers And Getting Rid Of Sessions In The URL
by blssu (Pilgrim) on Sep 15, 2002 at 13:14 UTC

    It sounds like you aren't authenticating requests that send a valid session id. Isn't that your root problem? Are you building obscurity instead of security?

    You can't keep URLs private. They'll show up in HTTP headers, log files, browser histories, bookmarks, cut and paste buffers, plain text e-mails, etc.

    Session IDs should only identify session state stored on your server; they should not grant access or leak the contents of your server. Ideally the client authenticates using digest mode or some other challenge response system. (Modern browsers even do this correctly.) If you have lots of CPU, basic authentication over HTTPS is also good. If your data isn't sensitive, you could "trust" an IP address for a limited time.

    At the very least, add an authentication step to your code. It will make your security solution easy to understand. And big red flags will wave if you see:

    sub authenticate_user { return 1 }

Re: Mod_Perl Handlers And Getting Rid Of Sessions In The URL
by barrd (Canon) on Sep 15, 2002 at 11:23 UTC
    Hi Revelation,
    There has been a fair amount of discussion surrounding this and related topics, hacker has written a great node that is well written and thought out. It could give you more ideas to play with, as they say TIMTOWTDT.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2024-03-29 00:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found