I know how to use sessions etc, however I don't really know how the work. I have a simple register/login/logout system that I wrote awhile ago. Looking back on it I noticed that I stored the user's password in the session. And on each secure page I checked that password against the password stored in the database for that username.
I realised that I could eliminate database connections altogether on a lot of my pages if I didn't do that.
So my question is, is that necessary? I didn't know if the user could somehow forge a session with the server and thus login without being registered.
Thanks, JohnnabnI have never see it. but not saying it isn't impossible.
sesions are pretty secure. sessions are unique pertaining to the user running the browser.thanksUnderstanding the threat
In the 1960's, it required the brilliance of Frank Abagnale Jr. (of "Catch Me If You Can" fame) to deceptively build a bank balance of colossal magnitude. Today, all one needs is a prying teenager with access to the Internet - a hair raising reality!
Consider the following analogy:
Scenario One:
Simple Sam (a legitimate user) goes to the local bank (web server farm) to access his safety deposit box (database). He is served by the first available teller (web application), who takes him to the vault.
Scenario Two:
Evil Edward (a malicious user) goes to the same local bank office and enters through the front door as well (port 80) just like any other customer. Even though his intent is vile he does not break into the bank through the windows (other ports). Thus, to the security guards (firewall) at the front door he appears to be innocuous. He too is served by the next available teller (web application). However, he tricks the teller into believing (session management) that he is not Evil Edward but is Simple Sam and gains access to Sam's security deposit box.
Scenario two describes a successful impersonation attack that goes undetected by the security guards (firewall).
The best way to avoid session impersonation is to do a check on each page hit against a subsequent ip matching your session key. If they mismatch (ie, same key, diff ip), you know to lock out and destroy the sessions, forcing the user to login again with their own auth information, generating a new session id/ip key pair.
-flI think I understand what you're saying. On my site, there are users and there are admins. The session stores the username they're logged in as, their password, and whether or not they have admin priveledges.
Now, after a normal user signs in, would it possible for them to edit their session and change it so that they had admin priveledges? If it is possible I would want to check the database to see if the username stored in the session was supposed to have Admin priveledges. But, since the admin's usernames are common knowledge, and they could also edit their session username, and I would have to check the password stored in their session against the database.
But if you can't edit sessions, they're would be no real need.
But what forlamp says, it would stop someone else from "taking over" another users session, but would ensure that a user did not edit their own session? Or did I misunderstand what you meant?
Thanks Johnnabnhow would you take over another session of you don't know what the session id is? I would go by the IP address instead of the session variable.
I realised that I could eliminate database connections altogether on a lot of my pages if I didn't do that.
So my question is, is that necessary? I didn't know if the user could somehow forge a session with the server and thus login without being registered.
Thanks, JohnnabnI have never see it. but not saying it isn't impossible.
sesions are pretty secure. sessions are unique pertaining to the user running the browser.thanksUnderstanding the threat
In the 1960's, it required the brilliance of Frank Abagnale Jr. (of "Catch Me If You Can" fame) to deceptively build a bank balance of colossal magnitude. Today, all one needs is a prying teenager with access to the Internet - a hair raising reality!
Consider the following analogy:
Scenario One:
Simple Sam (a legitimate user) goes to the local bank (web server farm) to access his safety deposit box (database). He is served by the first available teller (web application), who takes him to the vault.
Scenario Two:
Evil Edward (a malicious user) goes to the same local bank office and enters through the front door as well (port 80) just like any other customer. Even though his intent is vile he does not break into the bank through the windows (other ports). Thus, to the security guards (firewall) at the front door he appears to be innocuous. He too is served by the next available teller (web application). However, he tricks the teller into believing (session management) that he is not Evil Edward but is Simple Sam and gains access to Sam's security deposit box.
Scenario two describes a successful impersonation attack that goes undetected by the security guards (firewall).
The best way to avoid session impersonation is to do a check on each page hit against a subsequent ip matching your session key. If they mismatch (ie, same key, diff ip), you know to lock out and destroy the sessions, forcing the user to login again with their own auth information, generating a new session id/ip key pair.
-flI think I understand what you're saying. On my site, there are users and there are admins. The session stores the username they're logged in as, their password, and whether or not they have admin priveledges.
Now, after a normal user signs in, would it possible for them to edit their session and change it so that they had admin priveledges? If it is possible I would want to check the database to see if the username stored in the session was supposed to have Admin priveledges. But, since the admin's usernames are common knowledge, and they could also edit their session username, and I would have to check the password stored in their session against the database.
But if you can't edit sessions, they're would be no real need.
But what forlamp says, it would stop someone else from "taking over" another users session, but would ensure that a user did not edit their own session? Or did I misunderstand what you meant?
Thanks Johnnabnhow would you take over another session of you don't know what the session id is? I would go by the IP address instead of the session variable.