Re: [PHP] Stopping stolen / spoofed / linked sessions
Rasmus, et.al., OK, I'm still confused. What does SSL have to do with any of this? If I'm running a site using SSL, all that does is encrypt the transmitted info right? It doesn't have anything to do directly with the sessions though? The problem I'm wrestling with is: Person A logs in to my SSL website and provides a username/password which I verify. I then start a session for them. I have a ten minute timeout period which gets reset with every page they visit during this session. I pass the session id using either a cookie that expires at the end of the session or a URL. Using the cookie seems quite secure. Using the session ID as part of the URL seems less secure because... If person B happens to look over person A's shoulder and records the URL (it is long and obscure with the session id but for sake of argument) and then goes and visits the same web site he's in right? And using SSL doesn't affect this at all unless I'm totally confused (quite possible). If A and B are both behind the same firewall their IPs might not be distinguishable. The HTTP_REFERER stuff doesn't do anything for me because they are already within my site? Is this just an insoluble problem using the URL approach and the only thing to do is require cookies be enabled? Bill -- Bill Rausch, Software Development, Unix, Mac, Windows Numerical Applications, Inc. 509-943-0861 [EMAIL PROTECTED] -- 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
Bill Rausch pressed the little lettered thingies in this order... Rasmus, et.al., OK, I'm still confused. What does SSL have to do with any of this? SSL makes it impossible (well, improbable anyway) to sniff the session ID from the network. Without SSL, anyone on the network between the origin (client) and the destination (server) can get the session ID in plain text by installing a packet sniffer on the network. If you're relying on the URL to send session IDs, you'll never conquer the person looking over the shoulder problem (assuming that you believe that it's reasonable that someone can look over another's shoulder and write down a 20 character string without the first person noticing). Christopher Ostmo a.k.a. [EMAIL PROTECTED] AppIdeas.com Meeting cutting edge dynamic web site needs For a good time, http://www.AppIdeas.com/ -- 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
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. -Rasmus So setting a 'loggedin' session variable once a person has authenticated, and checking for that session variable each request before proceeding is not ok? jason -- 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 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
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. 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? 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. -Rasmus -- 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
Depends on what you want to do, first you have to define what are valid sessions, So think of things like this - One Session can only come from one IP address - A session ID that was created n minutes ago is no longer valid - A user using Netscape x can't be using IExplorer y After a user connects to you with a session ID you could check all those things yourself in your PHP script and respond appropriately. In this case, store the session in a Database with the remote IP address, expire the Session and check the referer. That should block a lot of script kiddies but of course slows down the site. Also, it's not that hard to create cookies by hand so that won't stop people who realy want to enter your site :-( and remember sessions are not meant to be secure, that is why we have SSL :-) Robert Klinkenberg -Oorspronkelijk bericht- Van: Bill Rausch [SMTP:[EMAIL PROTECTED]] Verzonden:Saturday, June 30, 2001 12:43 AM Aan: [EMAIL PROTECTED] Onderwerp:AW: [PHP] Stopping stolen / spoofed / linked sessions Sebastian Stadtlich said: there is an option in php ini : session.referer_check = which should fit your needs not sure how to use it, but probably one of the php-developers on this list can assist... I looked at this thing and can't figure out that it does very much. If someone makes a web page that contains a link to my site that contains the PHPSESSID=... then that session id will be invalid. However, if they just type the same string into their browser by hand, it is accepted? It seems that there is no stopping session spoofing if using the URL method. The only work around is to expire sessions quickly or to require that cookies be used? -- 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
keep the current user's IP address or timestamp in a database with the session ID. if the session is requested by someone with a different IP or too-late timestamp, give the requesting user a new session. -Original Message- From: adam (dahamsta) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 27, 2001 1:39 PM To: [EMAIL PROTECTED] Subject: [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] -- 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
Adam, 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. The username, session id and session key are then stored in a MySQL table. Every time the user loads a page I want secure, it re-creates the session key and checks to make sure it matches the information stored in the database. If that works, then it checks another table to determine if the user has access to the page or not. 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. Hope this helps, David Price -Original Message- From: adam (dahamsta) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 27, 2001 10:39 AM To: [EMAIL PROTECTED] Subject: [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] -- 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]
Re: [PHP] Stopping stolen / spoofed / linked sessions
Hi When you start a session for the first time store remote host info and validate it on subsequent accesses. Tom At 10:48 PM 28/06/01, [EMAIL PROTECTED] wrote: Hi adam! On Wed, 27 Jun 2001, adam (dahamsta) wrote: [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? there was a long and interesting thread on bugtraq @ securityfocus.com recently regarding this (it started w/ uploading images, I don't recall what was the subject, but you can figure some keywords to search for ;) Among proposed solutions was to send a ticket and validate it for each operation. Worth a searchread if you're a web developer. -- teodor -- 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 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
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. -Rasmus -- 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
: 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? On the server where you are storing the session ID, also include her User-Agent and remote IP. Remote IP has some flaws when a proxy cache is involved. User-Agent stays the same fairly much through an entire session. Hopefully they aren't using *exactly* the same browser and IP. Or use one time session tokens that get reissued after each request and then invalidated. Breaks reloads and back functionality. Turu. -- Stephen Cope - http://sdc.org.nz/ -- 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 adam! On Wed, 27 Jun 2001, adam (dahamsta) wrote: [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? there was a long and interesting thread on bugtraq @ securityfocus.com recently regarding this (it started w/ uploading images, I don't recall what was the subject, but you can figure some keywords to search for ;) Among proposed solutions was to send a ticket and validate it for each operation. Worth a searchread if you're a web developer. -- teodor -- 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]
