After even more reading on sessions, what exactly can a user do if they get the session ID ? It is easy to do in FireBug, but does this mean they can read the session variables ? as far as I can tell the session information is encrypted ? Is there anyway to obtain session variables if someone has the session ID ? Would have thought it would be impossible for that to happen though I am not so sure anymore!
I think if I had a page which uses sessions and a simple example it just had 1 session variable called "count" that each time someone visited that page the count number would go up. So if someone got the session ID, they could in effect make the counter go up aswell ? but as far as I know, that couldn't actually know the variable was called "count" but they could maybe increase the count variable by hijacking session ID's ?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
I read something similar just to that, the session ID needs to be long, I will have to check what the session length is by default... in anycase, if someone did manage to guess a session id, the could not actually obtain any data unless they knew the variable names such as "username" ?
I would presume if they got a ID and knew a variable name, they could just connect to that session and just simply echo the "username".... thinking along how SQL works now I think...
It doesn't quite work like that. All of your session data is stored on the server, and it's accessible while PHP is generating the HTML page. Once PHP finishes and sends the page to the user, there is no way for a user to simply request a variable from the session data (unless you happen to have created a PHP script where the user can type in a variable name, submit the form, and have the PHP script deliver the value back to the user... but that's a pretty bad idea and wouldn't really make sense to do).
Think of a world where each of us wears an ID badge on our shirt. Guessing/stealing a session ID is just like copying someone's ID badge and putting it on your own shirt. There's really nothing special except that you have access to whatever the other person had access to - nothing more.
The most dangerous thing you can do when you steal a session ID is to log into their account without needing to know their username or password (having the session ID of a logged-in user is just like a magical key that lets you right into that user's account).
From there, you can do whatever the REAL owner of that session ID can do - steal some information from their profile page maybe (identity theft?), maybe change the password on the account, or post messages pretending to be that user. That type of thing, but again, there's really no built-in / default way for a user to simply have free access to whatever is in the session data. Some systems store secret information about the user in the session - information that even the logged-in user should not know. Since the user can't just request that information, it can be safe (in a basic sense).
if I stole a ID and did have access to whatever that person did, then thats a really bad thing.... but if thats the case, what exatly do they have access to ?!
Of course they will not know any of the variable names, that was one question.. so if they get the ID, really it would be useless ?
The link in the first posted reply explains a lot, but using cookies, in my case im not actually using cookies, not on the clients pc anyway. My thought there was to just store the timestamp of when the person logged in, then that timestamp will be needed along with a valid session id, which must tally with that session id.
So my thought is there, it has to be secure as any who managed to obtain a ID could not make any valid requests to my server as the timestamps would not match. So in that case can I assume the session ID is useless to anyother users ?
all I really wanted to know if what anyone could do with the session ID is they had it.. as long as they can't read any information then there is no problem, which was really my main question that I was just double checking on...
Well, technically the session ID -is- stored in cookies unless you've specifically disabled that and are forcing all your visitors to use pages where the session ID is passed along in the URL.
Regarding the timestamp - that's fine, but it's pretty hard to randomly guess a session ID. Thus, if someone else has the same session ID, it's probabyl because they stole it, and if they stole it, then they probably have access to the other data, like that timestamp. Still, every additional measure you take can only help and turn away casual hacking attempts. If someone is talented and desperate to steal a specific session, then they'll probably be looking at all the other visible data and trying to mimic stuff like the timestamps.
You should simply ask yourself, if a regular user just decided one day to be as evil as possible and do as much damage as they could, what COULD they do (using just your application) ? I wrote an article a while back on security in web applications - might help you here;
http://www.experts-exchang
A note on the timestamp idea (just to clarify): you just have to think about where you're going to store the timestamp. All data has to be stored somewhere, and if that timestamp value has to "stick" with the user as they go through the application, then where is it stored for that purpose? Is it stored in a cookie? In a session variable? Inside the URL of each link and form action?
If it's in a session variable, then it doesn't really help, since stealing the session ID would basically also "steal" access to that same session data, including the correct timestamp.
Store it in a cookie, and you probably face the problem I mentioned earlier - if they stole the cookie with the session ID, then they probably also stole the cookie with the timestamp value in it.
If it's in the link, well, then you have to rewrite all the links and form actions in your application so the timestamp isn't lost along the way.
It is remote that someone could (or want to) get a ID to hack it, but it only takes 1 person to do it, then google becomes your main evil.
It was why I asked if someone could obtain the session variables, the time stamp would be only issued on a valid login and stored in a SQL DB related to the actual user.
So if the "Fake user" who has the valid session ID wanted to trash someones account (or whatever) , the server would just not accept requests from his "location" as the SQL timestamp would not be there in the faked users session... at least I think so anyway....
That may not work as I think about it, as if I stored the timestamp in a session, then it would be a "Clone" of the user so the timestamp would not actually matter... I guess it would work if I store the timestamp in a local cookie instead of the session ? that way the "cloned user" using the stolen ID will not be able to make requests as they do not have the local cookie which was created during a official login....
this all makes your head spin a lot! thanks for the link, will go read that too!
great link. will take me some time to read it all, though I can see from other articles about SQL injection, I only use POST now, though my SQL lines read such as select password where user=$user , so even if they inject values using POST, it *shouldnt* matter... they could select any username via injection, but the script will not allow them to login unless they input the correct password... bit off topic in this post though! thanks for your input!!
SQL injection isn't about simply changing the username that is sent to the query, or changing from $_GET to a $_POST or something. Changing data (regardless of GET or POST or whatever) is trivial to do.
The whole big deal about SQL injection is about sending data to SQL that also changes the query itself.
Example:
$query = "SELECT * FROM users WHERE username='$user' and password='$password'";
No matter where $user came from, if you don't "clean" the value before you put it into a query, then anyone can change your query. I could go into your login form and instead of using gr8gonzo as my username, and my real password, I use:
$user = administrator
$password = blah' or 1=1
If you don't do any sort of escaping / cleaning on those values, then MySQL would end up with this query:
$query = "SELECT * FROM users WHERE username='administrator' and password='blah' or 1=1";
The result? I would be able to log into the administrator account without knowing the password. Obviously, "blah" probably isn't the right password, so "password='blah'" would be false, but the "or 1=1" would be true, so it would go ahead and return the administrator record (thus logging me in).
That's SQL injection.
I do understand what you are saying there. I am adding your tips from your link into my code as it all helps a lot!
I can't see how anyone could login without knowing the password in my script, as it only gets the password WHERE the username is. the only thing they can change is the username, and if its not a valid username it would never return the password, which wouldn't really help them anyway.
though I guess after reading your article that if they could pass a OR line in the username which could be used to select any username in the list, however, it may return the password of some user, but unless they enter that password the script would never allow them to login anyway.
The POSTED password from the login form has to match the one returned from the SQL line, else it will not allow a login as the passwords do not match. AFAIK, all is ok ?
> and if its not a valid username it would never return the password
That's very true. My example was just showing someone who actually knew a valid username or at least was guessing at a popular username. The point of it all, though, is that someone could change the ENTIRE query to something completely different. A little bit of ingenuity goes a long way in hacking. Someone could even do this:
$user = gr8gonzo'; UPDATE users SET password=''; SELECT * FROM users WHERE '1'='1
$password = whatever
And your script would end up running three queries:
$query = "SELECT * FROM users WHERE username='gr8gonzo'; UPDATE users SET password='newpassword'; SELECT * FROM users WHERE '1'='1' and password='whatever'";
Or they could simply change the query so it pulled back the first record in your users table, regardless of what the username or password were. Often times, the first user is also the top-level administrator user.
Or they could simple try to issue DROP TABLE commands to simply delete all your data.
Having any part of your site vulnerable to SQL injection is almost the same as giving them a big textbox to type their own queries that will be run on your database. The only difference is that they need to write their queries a little differently so they get exceuted properly, and getting the results back isn't quite as easy, but it can be done.
Business Accounts
Answer for Membership
by: 930913Posted on 2009-11-04 at 11:38:15ID: 25743019
This discusses session id security: http://www.securityfocus.c