Well I got back from my little holiday thingy yesterday. Managed to do lots of driving. Clocked up a few hours so that’s good. Haven’t really driven for like 6months :p
Anyway. I purchased a mysql/php/apache book yesterday and it had about half a page on php sessions. Very basic stuff. It talked about passing sessions within a url. So I was looking into that and found out that my current news script admin panel thingy wasn’t all that securer. All it did was check if auth=true in the session. Now that is fine but if I forgot to logout and someone got that session id (or they got the session id by other means) they could use it on any computer. You don’t even need to setup the script to accept a session id, it already does it! So you can’t stop the user from entering a session id from the url. So for example:
http://www.dalegroup.net?file=admin&sessionname=sessionid
sessionname = whatever you’ve called the session (defaults to PHPSESSID)
sessionid= whatever the session id is (randomly generated).
So that means if someone got the session id they could log in from anywhere without a username or password.
My new authentication is oh so much better. It has three points of checking: the session id, the database and the cookies stored on the users side. It checks for many things now. So if you wanted to hack my admin panel you’d need to do the following:
*Get a valid active session id
*Get all 3 cookies off the users computer who logged in (this includes lots encrypted info)
*Spoof the user’s ip address
heh not all that easy to do. This also protects me if the admin panel was stored on a shared server. If for some reason other people could view the sessions (stored in /tmp) they still wouldn’t be able to login. The sessions on the server are encrypted too (plus you need the user’s cookies and ip address). So it’s all good.
You aren’t getting into my admin panel ;)
Copyright © Michael Dale 2004.
Page generated in 0.0100 seconds FreeBSD Powered
Background on style 5 is used from squidfingers How are we going? 3 queries
Hmmmm…
Your post was kind of technically flawed, a lot… the implementation is possibly good, but your reasons for thinking that it is aren't.
1) If you can avoid it, DON'T pass session ID's in a URL! The URI string is the thing which is probably most likely to be intercepted between client and your server - even if the actual content passed (e.g. the HTML content itself) isn't. Web servers and proxies, for example, will LOG the URI requested, but not the page transmitted. So use cookie-based sessions wherever possible.
2) You're correct about the sessions hijacking thing, hence the need to use cookies rather than GET strings wherever possible. For this reason, I agree with your reasons for verifying a users IP address.
That said, IP spoofing really isn't that complicated - if I wanted to "hack your admin panel" I've already got points one and three down pat, assuming you're still using GET encoded strings.
3) And the three cookies on the users computer? What are they? What is encrypted, and how is it encrypted?
I think social hacking in this case is the simplest method - but then, it usually is. Alternatively, if there is an employee at some ISP watching the packets flow by, then you're also a little compromised… unless you enable mod_ssl and tie your admin sessions into that… something which is proposed in the user comments on the PHP sessions functions.
So that was my 3c (because 3 rounds to something of worth, unlike 2, and that had to be worth something ;) )
1: Comment by Josh - Fri, 09 Jul 2004 11:11:47 EST
1) I don't pass session ID's in the url. I was saying that it is possible to do so and thus causing a problem. The session ID is stored in a cookie. What I am saying is even though I don't pass the session ID it is still possible to pass a session id to a script. session_start() checks &sessionname=sessionid you can't stop this. Thus the need for using cookies.
Although I've made it so that the user MUST have cookies enabled and therefore any session id they try to pass is over written by the cookie on their system.
If you want to see session id passing in action, disable cookies and logon to the forums.
2) Thus the use for more than just checking the user's ip address.
3) Three cookies on the computer are the session id, the username and the password. Everytime the user runs a script the password in the cookie it checked wit the database. The encryption used is md5.
Another thing the session id is still passed in plain text even if you do use cookies. So that is why I encryted everything else. Although SSL is still needed for a secure connection. The password and username are passed in clear text when you click the submit button.
2: Comment by dale - Fri, 09 Jul 2004 11:29:53 EST
Oh another thing. My cookies are set to expire after 1hr so a user can't stay logged on. When the user logs out, the cookies are deleted, the variables are unregistered and the session is destroyed.
3: Comment by dale - Fri, 09 Jul 2004 11:33:11 EST
urls become clickable
[b]place text in bold[/b]
[i]place text in italics[/i]
[quote]place text in a quote[/quote]