My question is about this summary on session fixation:
Alice has an account at the bank http://unsafe.com/. Unfortunately, Alice
is not very security savvy.
Mallory is out to get Alice's money from the bank.
Alice has a reasonable level of trust in Mallory, and will visit
links Mallory sends her.
Mallory has determined that http://unsafe.com/ accepts any session
identifier, accepts session identifiers from query strings and has
no security validation. http://unsafe.com/ is thus not secure.
Mallory sends Alice an e-mail: "Hey, check this out, there is a cool new
account summary feature on our
bank,http://unsafe.com/?SID=I_WILL_KNOW_THE_SID". Mallory is trying to
fixate the SID to I_WILL_KNOW_THE_SID.
Alice is interested and
visits http://unsafe.com/?SID=I_WILL_KNOW_THE_SID. The usual log-on
screen pops up, and Alice logs on.
Mallory visits http://unsafe.com/?SID=I_WILL_KNOW_THE_SID and now has unlimited access
to Alice's account. (credit: RichieHindle)
Questions:
Q1 - Is there a way to explicitly prevent the site from accepting any
session identifier?
Q2 - I don't use the $_GET variable on my site so is there a way to prevent accepting session identifiers from query strings?
Notes: I'm using php 5.4.3 with SSL and will also use session_regenerate_id..
You could set the options martinstoeckli mentioned in his answer, but this won't prevent session fixation. It makes session fixation a little harder to attack, but it doesn't prevent it.
As ServerBloke mentioned, you prevent session fixation by using session_regenerate_id() immediately after verifying the user's login information and before you show the first page that requires authentication.
Making it harder for the attacker to exploit session fixation does not prevent session fixation. You must generate a new session ID.
More and more, people are using public unsecured untrusted wi-fi hot spots. Sessions can be sniffed from the air. On a physical network, they can be sniffed off the wire. They can also force you to visit any URL by employing a man-in-the-middle attack. So, session fixation is still a problem, even if the attacker can't send you URLs.
Knowing that sessions (and passwords) can be sniffed, there is another step that is required to prevent session hijacking. That is HTTPS (TLS/SSL).
All protected pages that require authentication should be accessed only over HTTPS. So, the login page (the one where the user sends their username and password) should be accessed via HTTPs. In that same script, you must regenerate a new sessionID. All pages for the remainder of the session must then be accessed via HTTPs to protect the new session ID.
Here's an example pseudocode login.php script:
// Force SSL
if($_SERVER["HTTPS"] != "on") {
die('Must login via HTTPS');
}
// Load the current sessionID
session_start();
// Validate the login information, being sure to escape the input
...
if (! $valid) {
die('Invalid login');
}
// Start the new session ID to prevent session fixation
session_regenerate_id();
// Clear the old session
$_SESSION=array();
// Log them in
$_SESSION['user_id'] = $userID;
If you use session_regenerate_id() everytime a user logs in you will prevent session fixation. As the user logs in, their fixated session ID will be regenerated and thus stopping the attack.
Question 1) If your application needs a session, you will have to send some kind of session id. If your application doesn't use sessions, then there is no need to call session_start(), and ids (whether sent by URL or cookie) are simply not used.
Question 2) You can configure PHP, to accept session ids exclusively from cookies, and to ignore ids from the URL (see session.use_only_cookies). If you do that, you should also check, that the option session.use_trans_sid is set to 0 (this is the default).
I don't fully understand, is this a really problem?
Q1. I think you need to check is there are a SID recieved from GET of COOKIE in you Session storage already (for example, in database). If YES - its'okay, if no, create a new one on server side and do http redirect with new SID.
Q2. I don't use a php 5.4 but i think the following code will help:
unset($_GET['sid'])
Update: I think the common fix is than only the backend-server can generate a SID identifiers. No user posibilites for this!
Related
How do you prevent multiple clients from using the same session ID? I'm asking this because I want to add an extra layer of security to prevent session hijacking on my website. If a hacker somehow figures out another user's session ID and makes requests with that SID, how can I detect that there are different clients sharing a single SID on the server and then reject the hijack attempt?
EDIT
I have accepted Gumbo's answer after careful consideration because I've come to the realization that what I'm asking for is impossible due to the restrictions of a stateless HTTP protocol. I forgot about what is perhaps the most fundamental principle of HTTP, and now that I think about this question seems a bit trivial.
Let me elaborate what I mean:
After User A logs in on example.com, he is given some random session ID, for simplicity's sake, let it be 'abc123'. This session ID is stored as a cookie on the client side and is validated with a server-side session to ensure the user who logged in remains logged in as he moves from one webpage to another. This cookie of course would not need to exist if HTTP were not stateless. For that reason, if User B steals User A's SID, and creates a cookie on his computer with the value 'abc123', he would have successfully hijacked User A's session, but there is simply no way for the server to legitimately recognize that User B's request is any different from User A's requests, and therefore the server has no reason to reject any request. Even if we were to list the sessions that were already active on the server and try to see if someone is accessing a session that is already active, how can we determine that it is another user who is accessing the session illegitimately and not the same user who is already logged in with a session ID, but simply trying to make another request with it (ie navigate to a different webpage). We can't. Checking the user agent? Can be spoofed - but good as a Defense in Depth measure nevertheless. IP Address? Can change for legitimate reasons - but instead of not checking for the IP address at all, I suggest checking something like the first two octets of the IP, as even a user on a data plan network who constantly has a changing IP for perfectly legitimate reasons would only usually have the last two octets of their IP change.
In consclusion, it is the stateless HTTP that condemns us to never being able to fully protect our websites from session hijacking, but good practices (like the ones Gumbo has provided) will be good enough to prevent a good majority of session attacks. Trying to protect sessions from hijacking by denying multiple requests of the same SID is therefore simply ludicrous, and would defeat the whole purpose of sessions.
Unfortunately, there is no effective way to unmistakably identify a request that originates from an attacker in opposite to a genuine request. Because most properties that counter measures check like the IP address or user agent characteristics are either not reliable (IP address might change among multiple requests) or can be forged easily (e. g. User-Agent request header) and thus can yield unwanted false positives (i. e. genuine user switched IP address) or false negatives (i. e. attacker was able to successfully forge request with same User-Agent).
That’s why the best method to prevent session hijacking is to make sure an attacker cannot find out another user’s session ID. This means you should design your application and its session management that (1) an attacker cannot guess a valid session ID by using enough entropy, and (2) that there is no other way for an attacker to obtain a valid session ID by known attacks/vulerabilities like sniffing the network communication, Cross-Site Scripting, leakage through Referer, etc.
That said, you should:
use enough random input for generating the session ID (see session.entropy_file, session.entropy_length, and session.hash_function)
use HTTPS to protect the session ID during transmission
store the session ID in a cookie and not in the URL to avoid leakage though Referer (see session.use_only_cookies)
set the cookie with the HttpOnly and Secure attributes to forbid access via JavaScript (in case of XSS vulnerabilities) and to forbid transmission via insecure channel (see session.cookie_httponly and session.cookie_secure)
Besides that, you should also regenerate the session ID while invalidating the old one (see session_regenerate_id function) after certain session state changes (e. g. confirmation of authenticity after login or change of authorization/privileges) and you can additionally do this periodically to reduce the time span for a successful session hijacking attack.
Can we do something like this.
Store session id in database.
Also store the Ip address and the HTTP_USER_AGENT for that session id.
Now when a request comes to the server containing that matching session id, Check from which agent and ip it is coming from in your script.
Can make this funda work by make common function or class for session so that every request is verified before it is processed. It would hardly take some micro seconds. But, If many users are visiting your site and you have huge database of sessions, then this might be little performance issue. But, It would surely be very secure compared o other methods like
=> Using regenerating sessions.
In regenerating session ids, there is again little chance of session hijacking.
suppose, user's session id is copied and that user is not working or active for sometime and no request is made to server with old session id asking to regenerate new one. Then In case session id is hijacked, hacker will use that session id and make request to server with that id, then server will respond back with regenerated session id and so that hacker can go on using the services. Actual user will no longer be able to operate because he is unknown of what the regenerated id is and what request session id is to be passed in request. Completely Gone.
Please correct me if i m wrong somewhere.
There are lots of standard defenses against session hijacking. One of them is to match each session to a single IP address.
Other schemes may use an HMAC generated from:
the network address of the client's IP
the user-agent header sent by the client
the SID
a secret key stored on the server
The reason only the network address of the IP is used is in case the user is behind a public proxy, in which case their IP address can change with each request, but the network address remains the same.
Of course, to truly be secure, you really ought to force SSL for all requests so that the SID can't be intercepted by would-be attackers in the first place. But not all sites do this (::cough:: Stack Overflow ::cough::).
Session hijacking is a serious threat, it has to handle by using a secure socket layer for advanced application which involves transactions or by using simple techniques like using cookies, session timeouts and regenerates id etc as explained above.
When the internet was born, HTTP communications were designed to be stateless; that is, a connection between two entities exists only for the brief period of time required for a request to be sent to the server, and the resulting response passed back to the client.
Here are a few methods which hackers follow to hijack the session
Network Eavesdropping
Unwitting Exposure
Forwarding, Proxies, and Phishing
Reverse Proxies
Always recommend SSL Secure Sockets Layer
Use cookies also to following ini_set() directives at the start of your scripts, in order to override any global settings in php.ini:
ini_set( 'session.use_only_cookies', TRUE );
ini_set( 'session.use_trans_sid', FALSE );
Use Session Timeouts and Session Regenerate ID
<?php
// regenerate session on successful login
if ( !empty( $_POST['password'] ) && $_POST['password'] === $password )
{
// if authenticated, generate a new random session ID
session_regenerate_id();
// set session to authenticated
$_SESSION['auth'] = TRUE;
// redirect to make the new session ID live
header( 'Location: ' . $_SERVER['SCRIPT_NAME'] );
}
// take some action
?>
In my view you can store session id in database when users login and check everyone for the same before loggin in. delete the same session id which you have stored in database when users logout. You can easily findout session id of each and every user or else I can help you.
One of the easy implementations can be done by making a table in database , as logged users , then at login, update that table with user name and his SID , this will prevent other logins as same user , now at the time of log out , just run a simple query , which deletes the logged in data in database , this can also be used to trace logged in user on ur website at a time .
Obviously when you'll set session cookie in the browser, that cookie is sent in the request. Now when request comes, Server will check the session id in database and grant access. To prevent that only its important to store agent and ip so that before checking server makes sure that sessions access is granted to the unique client and not the unique session id which can be hijacked.
I don't know about the coding part well. So I can tell u an algorithm to do this. Setting stuffs like SSL, or setting the session cookie to secure and httpOnly wont work if a user sniffs the session id from a LAN network(Provided user and attacker are in the same LAN).
So what you can do is, once the user successfully logs into the application, set unique token to each and every pages of the web application and keep a track of this at the server side. So that if the valid user sends the request to access a particular page, the token of that page will also be sent to the server side. Since the tokens are unique for a user for a particular session, even if the attacker can get the session id, he cannot hijack the users session as he cannot provide the valid token to the server.
#Anandu M Das:
I believe what you may be referring to is the use of session tokens with each session ID. This site can explain the use of tokens with sessions:
https://blog.whitehatsec.com/tag/session-token/
Although session tokens are easily compromised by an XSS attack, this doesn't mean that they should never be used. I mean let's face it, if something was compromisable by a security vulnerability on the server, its not the fault of the method, its the fault of the programmer who introduced that vulnerability (to highlight points made by Hesson and Rook).
If you follow proper security conventions and practicies and secure your site from SQL injection, XSS, and require all sessions be managed over HTTPS, then you can easily manage the potential attack from CSRF by use of server-side tokens, stored within the session, and updated everytime the user would cause a manipulation to their session (like a $_POST being submitted). Also, NEVER store sessions or their contents in a url, no matter how well you think they are encoded.
When the security of your users is paramount (which it should be), the use of session tokens will allow better or more advanced functionality to be provided without compromising their session security.
I am trying to prevent session fixation and have read the following from the owasp website:
Session Fixation
Session IDs are to be generated by your application only. Never create
a session only because you receive the session ID from the client, the
only source of creating a session should be a secure random generator.
I handle sessions by using:
ini_set('session.use_only_cookies', 1); // Forces sessions to only use cookies.
ini_set('session.entropy_file', '/dev/urandom'); // better session id's
ini_set('session.entropy_length', '512');
session_start();
and checking for the existence of a user id:
if(isset($_SESSION['user_id'])) {
//act like user is logged in
} else {
//refer user to the login page
}
Does this mean the only source of creating my session is via a secure random generator?
By default PHP is prone to session fixation:
A simple attack scenario
Straightforward scenario:
Mallory has determined that http://unsafe.example.com/ accepts any session identifier, accepts session identifiers from query strings and
has no security validation. http://unsafe.example.com/ is thus not
secure.
Mallory sends Alice an e-mail: "Hey, check this out, there is a cool new account summary feature on our bank,
http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID". Mallory is trying
to fixate the SID to I_WILL_KNOW_THE_SID.
Alice is interested and visits http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID. The usual log-on
screen pops up, and Alice logs on.
Mallory visits http://unsafe.example.com/?SID=I_WILL_KNOW_THE_SID and now has unlimited access to Alice's account.
http://en.wikipedia.org/wiki/Session_fixation
session.use_strict_mode boolean
session.use_strict_mode specifies whether the module will use strict
session id mode. If this mode is enabled, the module does not accept
uninitialized session ID. If uninitialized session ID is sent from
browser, new session ID is sent to browser. Applications are protected
from session fixation via session adoption with strict mode. Defaults
to 0 (disabled).
http://php.net/manual/en/session.configuration.php#ini.session.use-strict-mode
Enabling session.use_strict_mode prevents PHP from accepting ids of non-existing sessions and creating them. This does not prevent other types of session fixation though:
Attack using server generated SID
A misconception is that servers which only accept server generated
session identifiers are safe from fixation. This is false.
Scenario:
Mallory visits http://vulnerable.example.com/ and checks which SID is returned. For example, the server may respond: Set-Cookie:
SID=0D6441FEA4496C2.
Mallory is now able to send Alice an e-mail: "Check out this new cool feature on our bank,
http://vulnerable.example.com/?SID=0D6441FEA4496C2."
Alice logs on, with fixated session identifier SID=0D6441FEA4496C2.
Mallory visits http://vulnerable.example.com/?SID=0D6441FEA4496C2 and now has unlimited access to Alice's account.
This can be prevented by session.use_only_cookies, which is on by default.
You may still be vulnerable to yet more session fixation attacks through XSS, which you will have to counteract with measures other than PHP ini settings.
Session IDs are to be generated by your application only.
That quote from OWASP PHP Security Cheat Sheet is wrong. Restricting the source of the session id has no effect on Session Fixation. An attacker can go to your site and just grab a valid session id.
The passage was fixed and gives now an effective method for preventing Session Fixation:
Invalidate the session id after user login (or even after each request) with session_regenerate_id().
How do you prevent multiple clients from using the same session ID? I'm asking this because I want to add an extra layer of security to prevent session hijacking on my website. If a hacker somehow figures out another user's session ID and makes requests with that SID, how can I detect that there are different clients sharing a single SID on the server and then reject the hijack attempt?
EDIT
I have accepted Gumbo's answer after careful consideration because I've come to the realization that what I'm asking for is impossible due to the restrictions of a stateless HTTP protocol. I forgot about what is perhaps the most fundamental principle of HTTP, and now that I think about this question seems a bit trivial.
Let me elaborate what I mean:
After User A logs in on example.com, he is given some random session ID, for simplicity's sake, let it be 'abc123'. This session ID is stored as a cookie on the client side and is validated with a server-side session to ensure the user who logged in remains logged in as he moves from one webpage to another. This cookie of course would not need to exist if HTTP were not stateless. For that reason, if User B steals User A's SID, and creates a cookie on his computer with the value 'abc123', he would have successfully hijacked User A's session, but there is simply no way for the server to legitimately recognize that User B's request is any different from User A's requests, and therefore the server has no reason to reject any request. Even if we were to list the sessions that were already active on the server and try to see if someone is accessing a session that is already active, how can we determine that it is another user who is accessing the session illegitimately and not the same user who is already logged in with a session ID, but simply trying to make another request with it (ie navigate to a different webpage). We can't. Checking the user agent? Can be spoofed - but good as a Defense in Depth measure nevertheless. IP Address? Can change for legitimate reasons - but instead of not checking for the IP address at all, I suggest checking something like the first two octets of the IP, as even a user on a data plan network who constantly has a changing IP for perfectly legitimate reasons would only usually have the last two octets of their IP change.
In consclusion, it is the stateless HTTP that condemns us to never being able to fully protect our websites from session hijacking, but good practices (like the ones Gumbo has provided) will be good enough to prevent a good majority of session attacks. Trying to protect sessions from hijacking by denying multiple requests of the same SID is therefore simply ludicrous, and would defeat the whole purpose of sessions.
Unfortunately, there is no effective way to unmistakably identify a request that originates from an attacker in opposite to a genuine request. Because most properties that counter measures check like the IP address or user agent characteristics are either not reliable (IP address might change among multiple requests) or can be forged easily (e. g. User-Agent request header) and thus can yield unwanted false positives (i. e. genuine user switched IP address) or false negatives (i. e. attacker was able to successfully forge request with same User-Agent).
That’s why the best method to prevent session hijacking is to make sure an attacker cannot find out another user’s session ID. This means you should design your application and its session management that (1) an attacker cannot guess a valid session ID by using enough entropy, and (2) that there is no other way for an attacker to obtain a valid session ID by known attacks/vulerabilities like sniffing the network communication, Cross-Site Scripting, leakage through Referer, etc.
That said, you should:
use enough random input for generating the session ID (see session.entropy_file, session.entropy_length, and session.hash_function)
use HTTPS to protect the session ID during transmission
store the session ID in a cookie and not in the URL to avoid leakage though Referer (see session.use_only_cookies)
set the cookie with the HttpOnly and Secure attributes to forbid access via JavaScript (in case of XSS vulnerabilities) and to forbid transmission via insecure channel (see session.cookie_httponly and session.cookie_secure)
Besides that, you should also regenerate the session ID while invalidating the old one (see session_regenerate_id function) after certain session state changes (e. g. confirmation of authenticity after login or change of authorization/privileges) and you can additionally do this periodically to reduce the time span for a successful session hijacking attack.
Can we do something like this.
Store session id in database.
Also store the Ip address and the HTTP_USER_AGENT for that session id.
Now when a request comes to the server containing that matching session id, Check from which agent and ip it is coming from in your script.
Can make this funda work by make common function or class for session so that every request is verified before it is processed. It would hardly take some micro seconds. But, If many users are visiting your site and you have huge database of sessions, then this might be little performance issue. But, It would surely be very secure compared o other methods like
=> Using regenerating sessions.
In regenerating session ids, there is again little chance of session hijacking.
suppose, user's session id is copied and that user is not working or active for sometime and no request is made to server with old session id asking to regenerate new one. Then In case session id is hijacked, hacker will use that session id and make request to server with that id, then server will respond back with regenerated session id and so that hacker can go on using the services. Actual user will no longer be able to operate because he is unknown of what the regenerated id is and what request session id is to be passed in request. Completely Gone.
Please correct me if i m wrong somewhere.
There are lots of standard defenses against session hijacking. One of them is to match each session to a single IP address.
Other schemes may use an HMAC generated from:
the network address of the client's IP
the user-agent header sent by the client
the SID
a secret key stored on the server
The reason only the network address of the IP is used is in case the user is behind a public proxy, in which case their IP address can change with each request, but the network address remains the same.
Of course, to truly be secure, you really ought to force SSL for all requests so that the SID can't be intercepted by would-be attackers in the first place. But not all sites do this (::cough:: Stack Overflow ::cough::).
Session hijacking is a serious threat, it has to handle by using a secure socket layer for advanced application which involves transactions or by using simple techniques like using cookies, session timeouts and regenerates id etc as explained above.
When the internet was born, HTTP communications were designed to be stateless; that is, a connection between two entities exists only for the brief period of time required for a request to be sent to the server, and the resulting response passed back to the client.
Here are a few methods which hackers follow to hijack the session
Network Eavesdropping
Unwitting Exposure
Forwarding, Proxies, and Phishing
Reverse Proxies
Always recommend SSL Secure Sockets Layer
Use cookies also to following ini_set() directives at the start of your scripts, in order to override any global settings in php.ini:
ini_set( 'session.use_only_cookies', TRUE );
ini_set( 'session.use_trans_sid', FALSE );
Use Session Timeouts and Session Regenerate ID
<?php
// regenerate session on successful login
if ( !empty( $_POST['password'] ) && $_POST['password'] === $password )
{
// if authenticated, generate a new random session ID
session_regenerate_id();
// set session to authenticated
$_SESSION['auth'] = TRUE;
// redirect to make the new session ID live
header( 'Location: ' . $_SERVER['SCRIPT_NAME'] );
}
// take some action
?>
In my view you can store session id in database when users login and check everyone for the same before loggin in. delete the same session id which you have stored in database when users logout. You can easily findout session id of each and every user or else I can help you.
One of the easy implementations can be done by making a table in database , as logged users , then at login, update that table with user name and his SID , this will prevent other logins as same user , now at the time of log out , just run a simple query , which deletes the logged in data in database , this can also be used to trace logged in user on ur website at a time .
Obviously when you'll set session cookie in the browser, that cookie is sent in the request. Now when request comes, Server will check the session id in database and grant access. To prevent that only its important to store agent and ip so that before checking server makes sure that sessions access is granted to the unique client and not the unique session id which can be hijacked.
I don't know about the coding part well. So I can tell u an algorithm to do this. Setting stuffs like SSL, or setting the session cookie to secure and httpOnly wont work if a user sniffs the session id from a LAN network(Provided user and attacker are in the same LAN).
So what you can do is, once the user successfully logs into the application, set unique token to each and every pages of the web application and keep a track of this at the server side. So that if the valid user sends the request to access a particular page, the token of that page will also be sent to the server side. Since the tokens are unique for a user for a particular session, even if the attacker can get the session id, he cannot hijack the users session as he cannot provide the valid token to the server.
#Anandu M Das:
I believe what you may be referring to is the use of session tokens with each session ID. This site can explain the use of tokens with sessions:
https://blog.whitehatsec.com/tag/session-token/
Although session tokens are easily compromised by an XSS attack, this doesn't mean that they should never be used. I mean let's face it, if something was compromisable by a security vulnerability on the server, its not the fault of the method, its the fault of the programmer who introduced that vulnerability (to highlight points made by Hesson and Rook).
If you follow proper security conventions and practicies and secure your site from SQL injection, XSS, and require all sessions be managed over HTTPS, then you can easily manage the potential attack from CSRF by use of server-side tokens, stored within the session, and updated everytime the user would cause a manipulation to their session (like a $_POST being submitted). Also, NEVER store sessions or their contents in a url, no matter how well you think they are encoded.
When the security of your users is paramount (which it should be), the use of session tokens will allow better or more advanced functionality to be provided without compromising their session security.
I used $_SESSION['name'] to handle data from page to page. I mainly used it to keep the user logged in between pages. Within every page, i check if $_SESSION[logged_in'] is true or not. If true, keep user logged in. Otherwise, do something else.
This is how i handle my sessions - basic sample:
<?php
session_start();
if($_SESSION['logged_in'])
{
//show control panel list
}
else
{
//show login box. Once user logs in. Once user logs in,
//fetch userID, username, etc from database. Also set
//$_SESSION['logged_in'] = true.
}
?>
Somewhere in between codes i do the following:
SELECT * FROM User WHERE userID = $_SESSION['userID'];
I'm not sure if $_SESSION['userID'] would be accessible by users or not. If its accessible, then the page would be in threat because a user could change the userID manually and get access to others account he/she desires.
I'm not much into security. Please advice! What can i do?
Note: i'm trying to make code as simple as possible. For now, no oop is involved.
Your code is vulnerable to session fixation and session hijacking attacks. See http://phpsec.org/projects/guide/4.html for more information.
As you build bigger, more involved applications, you will also want to be careful how you handle logging the user out and handling other session-related aspects, such as privilege escalation. Handling sessions and logins safely is a tricky beast.
Implementing secure authentication is hard. Unless you are doing it as an academic exercise, i would strongly recommend using the library provided by your framework, if you are lucky enough to have a good one.
You will also want to consider things such as the following:
Do not allow the session id to be forced. [session fixation]
When permissions or credentials are changed (e.g. because the user has now logged in or out) then
immediately invalidate the session and start a fresh one.
Provide a logout feature, and be sure to invalidate the session upon logout.
Set the session cookie to HttpOnly -Preferably, require HTTPS and alo set the cookie to secure only.
Consider restricting the session validity to include checking some other information that helps to match the user e.g. user-agent. [session hijacking]
Always expire sessions after non-use and do not implement "keep me logged in" by reconnecting the user to their old http session.
Ensure that all session-related data is destroyed when a session is invalidated, regardless of where it is stored. A new user coming along, may just happen to get assigned a session id that has been used previously. This new session must not have any access to session data that has been set previously against that session id.
$_SESSION is one of the server-side Super Globals. It's not accessible by users or transmitted from your server in any way.
That's pretty good, here are a few other tips for session management:
Do not accept session identifiers from GET/POST variables:
Session identifiers in URL (query string, GET variables) or POST variables are not recommended as it simplifies this attack. It is easy to make links on forms which set GET/POST variables.
Regenerate the SID on each request:
In PHP use session_regenerate_id(). Every time a user's access level changes, it is necessary to regenerate the session identifier. This means that although an attacker may trick a user into accepting a known SID, the SID will be invalid when the attacker attempts to re-use the SID.
Yes, that is pretty much the right idea.
Here are a couple resources that may help, both with understanding session security and secure programming in general:
http://phpsec.org/projects/guide/4.html
http://phpsec.org/projects/guide/
I am making a login script that I would like to be as secure as possible. Problem is, security seems to be a never ending battle. So essentially, I am looking for suggestions and improvements to my ideas.
What I have is a login based solely on sessions. Anytime the session information changes, session_regenerate_id() is called to avoid obvious hijacking attempts.
When the session is not set, I check a cookie for valid login, and on success, I update the session.
I attempt to secure the cookie by adding a hash value along with a piece of unique user information (like username or id). This hash is comprised of various information, including the username/id, undecipherable password hash, part of the IP address, etc. By extracting the username/id from the cookie, I can make a new hash from the valid user information and compare that with the hash in the cookie. My hopes here are to prevent fake cookies and cookie hijacking (unless they also spoof the IP address).
EDIT Assume that the login itself will be done via HTTPS/SSL, so the transfer is (reasonably) secure.
Am I on the right track? What else can be done to secure my login?
Thanks for the help!
Stop what you are doing. Do not check the user-agent or the ip address. The user-agent is an attacker controlled variable and checking this value does not increase the security of this system. The ip address will change for legitimate reasons, such as if a user is behind a load balancer or TOR.
A session id must always be a cryptographic nonce. In php just call session_start() and then start using the $_SESSION super global. PHP takes care of all of this for you. If you want to improve php's session handler, use the configurations. Enable use_only_cookies, cookie_httponly and cookie_secure. Also setting the entropy_file to /dev/urandom is a good idea if you are on a *nix system but if your under windows then your in trouble.
For instance to authenticate a user:
//In a header file
session_start();
...
if(check_login($_POST['user_name'],$_POST['password'])){
//Primary key of this user
$_SESSION['user_id']=get_user_id($_POST['user_name']);
$_SESSION['logged_id']=True;
}
And to verify if a user is logged in:
//in a header file
session_start()
...
if(!$_SESSION['logged_id']){
header("location: login.php");
die();//The script will keep executing unless you die()
}
To improve this system read OWASP A9 and use HTTPS for the entire life of the session. Also read OWASP A5: CSRF aka "session riding" and OWASP A2: XSS because they can both be used to compromise a session.
There is no such thing as secure cookie UNLESS it's transmitted over SSL only. It can be mitigated some when using a persistent non-session cookie (like remember me), by doing exactly what you're doing, but not in the same way you're thinking of doing it.
You can indeed store server variables such as the user-agent, the ip address and so forth (and even JavaScript variables), but they are only good for validating that the persistent cookie data matches the client's new connection. The ip address isn't a good idea except when you know that the client (like you only) isn't going to change on every page load (a la AOL).
Modern web browsers and 3rd party services like LastPass can store login credentials that only require a key press (and sometimes not even that) to send the data to the login form. Persistent cookies are only good for those people who refuse to use what's available otherwise. In the end, persistent, non-session cookies are not really required anymore.
I use a cookie based method (using setcookie function) but ....
session_start();
...
if(check_login($_POST['user_name'],$_POST['password'])){
//Primary key of this user
$_SESSION['user_id']=get_user_id($_POST['user_name']);
$_SESSION['logged_id']=True;
}
...these methods are wrooooong !!!!
I crack my website with an attack based on the cookie.
I used cookie option of the WebCruiser vulnerability scanner, so I get my cookie after login.
Then I changed a simply value on cookie
Then I clicked save cookie.
At this point I clicked on webbrowser see on the left panel then I clicked right then I clicked on refresh page, so I got my admin page without using the login page with user and password.
So if someone push you a virus to read the cookie history of IE or Firefox, you'll be happy to find out your admin user and pass can be used by others.
So how to fix the problem? Simple: combine the cookie with session server or session's cookie with sessions server, or session with file session, or cookie with file session....
will be secure but slow :((((
I keep all login data in the users session, this way its all stored server side.
The only thing i would store in a client cookie is stuff like 'auto login', 'session id'
SESSION more secure than cookie
and my advise is to create a unique id for the current login attempted
like :
$id = uniqid();
$_SESSION['username'.$id] = "something ...";