Re: [PHP] Stopping stolen / spoofed / linked sessions
Hi Rasmus, nice to see you still watching over us on the lists. I feel like I've been ticked off by my dad though... :) Rasmus Lerdorf [EMAIL PROTECTED] said: I want to use PHP4 sessions for authentication, Ok, stop right there. Sessions and authentication have nothing to do with each other. To create a secure authenticated site you should be using HTTP-based authentication over SSL. Sessions are simply for maintaining state across http requests and have nothing to do with authentication. Ah, have a little more faith in one of your older users Rasmus. I'm not talking about the be-all and end-all of authentication here - if I was doing that, I would set up a PKI. I'm talking about regular authentication on websites, like thousands - tens of thousands - of sites use every day. Sites like Hotmail, Yahoo!, even Zend.com, which uses PHP sessions for tracking a users session after they been authenticated (which is really a follow-on type of authentication). It also uses the users IP address, which seems a bit icky for the reasons stated in my previous email, but maybe they've figured a way around the problem. What I'm asking is basically What's the best and easiest way to go about this? I have come up with a solution of sorts though, and I'd be interested in your opinion. I set up a user with a PHP session, and of course a timeout. If they have cookies turned on, I set another cookie with a hash of the username and password, or somthing else. But my final line of defense for users that don't have cookies is a URL and HTTP_REFERER comparison check. That is, on every request I log the URL requested as a session variable. On every subsequent request I compare the HTTP_REFERER with the logged URL, and if they match there's a pretty good chance it's not someone spoofing. Granted, it's not foolproof, but it'd be pretty hard to spoof, right? Anyway, I'd be interested in your opinion, and I'd also be interested in whether you're coming to Dublin for ApacheCon Europe? I hope to meet you there if you are. adam -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Stopping stolen / spoofed / linked sessions
Hi Richard, Richard Lynch [EMAIL PROTECTED] said: I want to use PHP4 sessions for authentication, but I'm having difficulty If it's as important as all that, go with SSL. Ah, I'll be using SSL for the original authentication anyway. But the users will be browsing using regular HTTP, which means I need a session to *keep* them authenticated. I could use HTTP-AUTH of course, but I don't particularly want to - some users don't seem to be able to understand it (I kid you not). Otherwise, live with the risk and just use HTTP Basic Authentication, perhaps via PHP sending the headers. See above. Unsolicited (and only slightly related) Tip: I recently figured out that RaQ servers I am on a RaQ(4) right now, gods love me, but this is an across the board thing. I'm developing this for my customers use, but I'll be releasing it as open source later. So it needs to be as compatible as possible, and cater for all possible eventualities - including users who don't use cookies and don't understand HTTP-AUTH. It's a wee bit ironic you mentioned it too, because I'll be using it to create a server management interface, so I can dump the RaQ altogether. They're great little machines, but they're about as secure as my tummy after 10 pints of Heineken. (Too graphic? :) have some funky-ass httpd.conf settings already in them Very funky actually. They use Perl Sections (mod_perl) to configure the SSL VirtualHosts on the fly when httpd is started. I'm experimenting with it meself at the moment, but I'm going to use PHP instead of Perl, because mod_perl makes for very fat httpd processes, which is pretty annoying when you don't even use it on the server. Unfortunately, PHP can't be embedded in httpd.conf (add that to the wish list lads), so I'm building a custom apachectl to read configuration data from a MySQL database and build a httpd.conf, and then start Apache with that confid file. It's really quite cool, even if I do say so myself. :) doing HTTP Basic Authentication already, so trying to do HTTP Basic Authentication via .htaccess just plain won't work. (Or, rather, it will only work for users already defined in their goofy interface...) Kind of, but not really. Actually a RaQ has two httpd's running, one listening on ports 80 and 443, and one listening on 81. The regular httpd uses mod_rewrite to listen for requests for secured areas (/admin, /siteadmin, /personal and /stats on boxes that use Webalizer), and redirects to the port 81 server, which then authenticates using the users and groups defined on the machine. So you can use HTTP-AUTH as normal on the regular httpd, as long you define your AuthUserFile/AuthGroupFile's correctly, and the HTTP-AUTH protected areas don't clash with the RaQ secured areas. The server is configured with 'AllowOverride none' by default though, but you just need to change it to 'AuthConfig' to fix that. PHP sending the headers, however, works just fine and dandy. :-) Yip. I have decided I don't really like RaQ servers. They don't totally suck, especially if you're in a hurry, but if you can do it a little later and way better, don't go RaQ. YMMV. Well, it the same old problem, isn't it? Convenience V security. The RaQ's are *very* convenient for a small but reasonably busy webdev/hosting company that doesn't have their own interface. When it comes to security though, it's not the best solution in the world by any manner of means. But if we were to be 100% secure all the time, everyone would use SSH and SC. If only life were that simple... :) Like I said above though, I'll be losing the RaQ as soon as I get the chance. I'd prefer to write and use my own code, I'd prefer to take the responsibility myself. And I'd just like to point out that I'm on this box now for conveniences sake, because it's closer to home than my prefered box (Red Hat, sorry :). Anyway, thanks Richard, adam -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Stopping stolen / spoofed / linked sessions
Hi again Rasmus, thanks for your reply. Rasmus Lerdorf [EMAIL PROTECTED] said: I wasn't trying to be overly critical, I just worry that new users are reading these posts and see these insecure solutions to this problem and don't realize that they are inherently insecure. I understand Rasmus, and don't worry, I wasn't being overly-sensitive. However as I said, I'm not looking for the ultimate authentication solution here, I'm looking for the best I can possibly do - without making it too awkward - in a forms- and sessions- based situation. What I have difficulty with is understanding how the thousands of websites I mentioned manage it without being overly concerned about security. Or is that the problem - they're not concerned enough, and we should all be using PKI's? For regular websites though, I think that might be overkill, especially when a huge majority of people don't understand even the fundamentals of security and encryption. (I tried to explain it to my Dad last night, it was painful but productive. :) Well, pretty hard to spoof is very relative. It is basically security through obscurity. From the description you just provided it is trivial to spoof it. Remember that the HTTP_REFERER comes from the client and can very easily be spoofed. I know security through obscurity is a bad thing (or at least it's *seen* as a bad thing. I don't necessarily subscribe to it being inherently bad, just something that should be used with care) but in this case I have to clench my teeth, put my hands over my head and say I think you're missing my point, or that you're not following me fully. I realise that the HTTP_REFERER can be spoofed - quite easily in fact, I could spoof it myself in a few lines of PHP code - but the chances of Eve guessing the right HTTP_REFERER to send are pretty remote, don't you think? Unless they're standing behind Alice and looking over her shoulder - in which case Alice's security is compromised anyway - Eve isn't going to know which page Alice last visited. So the only way Eve could take over Alice's session is to visit every page on the site using Alice's session ID. And if Alice is still browsing the site, it makes it even harder, because Alice will be moving the target around. Yes, it's security through obscurity, but isn't is so obscure that It Just Might Work? Please, I'm not saying your wrong here, I'm genuinely interested in your opinion. If you think I'm wrong, tell me, I'd prefer to know. And if you have a better solution for the problem I'm facing, I'd love to hear about it. I just have a blank wall in front of me and I can't find my sledge. :) adam -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Stopping stolen / spoofed / linked sessions
David Price [EMAIL PROTECTED] said: They way I got around this was to create a session key using a MD5 hash of the session id and the user's IP address. SNIP I know that the IP address can be spoofed, but I'm not sending the session id in the url, so no one knows what it is and without the session id the session key can not be spoofed. IP spoofing is only a side issue - some users IP address changes from request to request. WebTV is an example, and users behind proxies is another. I guess I'm looking for the perfect solution here, which just doesn't appear to be possible with HTTP. Maybe a better question is: What is the ideal model for a PHP4 sessions authentication scheme? Thanks anyway, adam -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] Stopping stolen / spoofed / linked sessions
[Please copy replies off-list.] I want to use PHP4 sessions for authentication, but I'm having difficulty understanding how to get around users spoofing, stealing or linking sessions. Here's an example: Alice sends Bob a link from a site she's logged into. Alice has cookies turned off in her browser, so the session id will be in the URL she sends Bob. Eve intercepts the message, follows the link and now she can take over Alice's session, and any data that is associated with that session. For that matter, Bob can do the same thing. I can think of lots of ways around this, but most of them are kludges that don't really cut it. I can store a second authentication value in a cookie, but that would require cookies, which isn't acceptable. I could propogate a second authentication variable in the URL, but that's a lot of hassle and defeats the purpose of PHP sessions. I can check the HTTP_REFERER to see if the user came from my own site, but that can be spoofed. I can log and check the users IP address, but that can't be relied upon. Is there any reliable way around this? Am I missing something obvious? Cheers, adam -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
