glickjd has asked for the wisdom of the Perl Monks concerning the following question:
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Secure Session Management
by valdez (Monsignor) on Sep 06, 2002 at 18:10 UTC | |
If you can use mod_perl, then try with Apache::AuthCookie; module's documentation is very clear about its benefits, it says: I found it quite interesting :) But this solves only half of your problem: you need also session management, right? Apache::Session could be an answer, but you may need to put some glue between these two modules. Ciao, Valerio | [reply] [Watch: Dir/Any] |
by BrowserUk (Patriarch) on Sep 06, 2002 at 19:14 UTC | |
I'm not sure I understand this bit When you determine that the client should stop using the credentials/session key, the server can tell the client to delete the cookie. Letting users "log out" is a notoriously impossible-to-solve problem of AuthBasic. Isn't the usual reason a server decides to 'log a client off' because of session timout after 20 mins or so? This normally occurs when they have simply moved on to another site or disconnected without informing the server they are doing so... in which case, there is not client to send the instruction to delete the cookie. Also, how does the server 'tell the client'? I know there is such a thing as 'server push', but I didn't think this had ever made much of an impact. Besides... The other way the timeout can occur is if the user is reading something long. If I was doing this and the server suddenly decided to 'send' me a 'your logged off' page, I don't think I would use that site again in a hurry. I think anything that relies on cookies is gonna limit your audience severely, and more so as new users become aware of the potential for misuse of cookies. The latest browsers that allow cookie control on a site-by-site basis mitigate this problem somewhat, but that requires users knowledgable to distinguish between sites they can trust and those they cannot. Unfortunately, things like the Trust-E symbol aren't worth the band-width that it takes to transmit them, as very little verification is done. ANd what verification is done, is done against the site "privacy policy", which invariably can be paraphrased as: <rant> {20k omitted}...of course, we won't use your private details for anything bad, but if we can find a way of screwing some commercial gain by using them to promote some aspect our, or our partners (Read:anyone who will pay us) businesses to you, we will! And by having said this here, hidden on another page linked from every page, in totally oblique, long-winded, legal terminology and frustratingly tiny print, we've effectively covered our arses should you ever discover what we are doing. </rant>
Well It's better than the Abottoire, but Yorkshire! | [reply] [Watch: Dir/Any] |
by valdez (Monsignor) on Sep 06, 2002 at 20:32 UTC | |
Your worries about compatibility can be solved using different solutions to the same problem. If you don't want cookies, then just use something like Apache::SessionManager, which can handle sessions inside URIs. Of course, this doesn't resolve privacy issues, as you can imagine, because it is still possible to track a user even without cookies. On the other hand, it would be quite impossible to put something in a basket on Amazon or build something like PMonks, without something holding a state. So there is no escape, except honesty. BTW, it is possible to expire AuthBasic accounts. Using cookies, just send an empty cookie (delete it) and the user will not enter your site without re-authentication. Under AuthBasic, just disable an account inside your htpasswd file. But you will need some more glue :-)) Ciao, Valerio | [reply] [Watch: Dir/Any] |
by BrowserUk (Patriarch) on Sep 06, 2002 at 22:17 UTC | |
by valdez (Monsignor) on Sep 06, 2002 at 22:48 UTC | |
by dws (Chancellor) on Sep 06, 2002 at 19:55 UTC | |
The server "tells" the client (to delete the session cookie) in response to a request from the client. In the timeout case, the server can also refuse to handle the request. Push isn't needed. If a web application really, really needs to know on a minute-by-minute basis whether the server thinks the client is logged in, use a hidden frame that refreshes on a periodic basis, and expire the session cookie on refresh. You can also include a javascript snippet to communicate "I've been logged out" to some non-hidden frame element.
| [reply] [Watch: Dir/Any] |
Re: Secure Session Management
by barrd (Canon) on Sep 06, 2002 at 18:15 UTC | |
The most secure system I have used for this type of scenario is a piece of OS software by the name of Interchange. It is touted as predominately an eCommerce solution but is actually a very good 'content management' system with eComm facilities built in. Supports either flat file or SQL Db management for the backend and utilises session management by creating a flat file filehandle for storing any arbitrary data that is desired. It may be a little OTT for your application but I would advise a quick look anyway as you may find some of the features to your liking. My main reason for suggesting this S/W is that is incredibly secure and written in Perl... YMMV. Update: typos fixed. | [reply] [Watch: Dir/Any] |
Re: Secure Session Management
by hacker (Priest) on Sep 07, 2002 at 13:13 UTC | |
Before you jump on and flame me, here's why: Hidden Fields do not leave "droppings" on the user's computer in any location (well ok, in their browser cache, but it expires once the page is reached anyway, if built properly). It also does not leave any bits in the URI for someone parsing their referer logs to go back into. I've actually managed to parse my own weblogs, caught an ugly referer, followed it back, and was into someone else's online mailbox. Not cool. Putting the session_id into the URI may fail in a lot of situations, such as with users behind a caching proxy. In many countries this mode of operation is essential due to saturation of international network connections. In my case, my users are very specific about what they will and will not allow on their systems. It tends to be more of a pain than the other methods, but I gain more happy users (most of them are in Europe, which tends to take a very suspiscious tack with US websites and methods lately), and I get the benefit of their input on things like reporting bugs in the bugtracker, using the cvs, and so on. A couple of basic rules apply to any session management you build: Now the catch, Hidden Fields have their own set of flaws: Further reading: There is no "wrong" way to do session management, but there are "strong" ways to do it. Don't just take the easy path of using cookies or storing the session_id in the URI, without considering the outcomes, and the other possibilities. | [reply] [Watch: Dir/Any] [d/l] |
by perrin (Chancellor) on Sep 15, 2002 at 15:40 UTC | |
By "fail" do you mean that the pages will not be cacheable by the proxy? In that case, hidden form fields have exactly the same problem, since the content of the page has to be different for every user. Proxy servers don't cache POST requests and GET requests coming from a form submission look identical to URIs with query args on the end. Hidden fields also have the problem of making every single link a form submission, which is a real pain and means replacing text links with images and buttons. Also, your use of the remote IP as part of your session ID does not prevent people from hijacking a session, it just makes it harder to guess a valid one, and it is possible to create duplicate IDs when using this in a cluster. It would be safer to use mod_unique_id for generating the ID and then use a MAC to verify it when it gets sent back, as described here. | [reply] [Watch: Dir/Any] |
by valdez (Monsignor) on Sep 08, 2002 at 21:37 UTC | |
Great explanation, hacker! I would like to add few considerations to what you said. Ciao, Valerio | [reply] [Watch: Dir/Any] [d/l] |
Re: Secure Session Management
by glickjd (Novice) on Sep 06, 2002 at 23:19 UTC | |
Each user will have a record in a database. When the user initially logs in, it will verify that they entered the correct username and password by comparing to the values in the database. After it verifies the username and password are correct, it will assign a random string of text (session ID) and it will write this session ID along with the current time, to the record in the database. It will also write this session ID along with the username to a cookie. Now when the user loads another page, it will pull the session ID and username from the cookie. After it finds the matching session ID and username in the database, it will check the time in the database (time session ID was assigned). If that time is over a certain limit, it will timeout and display the login screen...otherwise it will allow the user to continue and will assign a new session ID and time to the databse and the new session ID and username to the cookie. I figure since all these pages are encrypted with SSL, it's not a having the session ID intercepted is not a concern. Plus, the session ID is changed each time, so even if someone got a hold of it, it will have probably changed or timed out by the time they can use it. Any comments or suggestions? Do you see any problems here? Do you think this would hold up and perform well with a large amount of users? Thanks again, Jeremy | [reply] [Watch: Dir/Any] |
by Ryszard (Priest) on Sep 07, 2002 at 08:00 UTC | |
So: | [reply] [Watch: Dir/Any] |