I am going to write a server api that responsible for user authentication. From my limit knowledge and understanding, when a user login with username and password, session will be created and auth cookie with username will save into cookie. When the user request for the next page, the user information in the cookie will send to server and server will recognize it. so my question is what if another person manually copy the existing cookie info and create the same cookie in a browser of another computer? Will it skip the login stage? Can anyone explain in details how to prevent this in details? thanks
Yes, it will most likely skip the login stage. What you describe is a form of session hijacking, or cookie hijacking. Using cookies over unencrypted connection (ie. HTTP instead of HTTPS) is not a secure solution because anyone can steal and use the same cookie and this is usually enough to get full access with no need to authenticate. (It can be - though it usually isn't - made harder to exploit but not impossible.)
Soon there will be no reason not to use HTTPS (see my answer to other question for details).
In addition to making sure that no one can read the cookie (using HTTPS and HttpOnly) you also have to make sure that no one can guess the session ID (eg. it cannot be a sequential or small number or anything like that).
See also:
Session hijacking on Wikipedia
Session hijacking on OWASP
Session fixation on Wikipedia
Session fixation on OWASP
Session riding (XSRF, CSRF)
Related
I can use session details of other users and can do the session hijacking.
For ex.
I am login with a user 'A' and saves the session cookie of 'A' and logout. Now I login with another user 'B' and after login replace the session cookie with the session cookie of 'A' with the help of Burp tool or any browser extension tool.
Now I can perform action like 'A'. As 'A' is login now without any login details. This is very highly critical issue.
Also I can upload double extension file (for ex. filename.exe.txt).
But you're forgetting the most important part of session hijacking, which is, How do you get access to others session cookies? You can replace your cookies to login on any site, after all, that's how they work, they're used to simulate a state in a stateless protocol like HTTP, that's the expected behaviour.
The real problem here is how you can get the session cookie of other users to impersonate them. For example, if the session cookies are generated by using a predictable algorithm, i.e. using an auto-incrementing session token that will always add 1 to the previous one, with this you can just get you session cookie, subtract 1 and voilá, you'll be authenticated as a different user.
Another way to get session cookies is with XSS attacks, if the cookies are not flagged as HTTP only, then you can get them via javascript and send them to your server, where you'll use them to impersonate different users.
However, just grabbing your session cookie and using it in a different browser and getting logged in as that user without credentials, it's not a session hijacking at all, that's just the intended behaviour.
What I see as a problem here, is that you said that you logged out as A and it didn't expired your session token, since you could still use user's A cookie, but besides that, I don't see any problem.
I've heard that my site can get attacked by hackers who:
Go to my site to start a session.
Somehow get a client to go to my site with the same session ID
The client logs in
When the attacker comes back to my site with the session id he has full access to that clients account.
I can see this being done if the session ID is passed by url and it makes sense to cycle it (session_regenerate_id) but is this needed if I just use session_start and I don't put the session id in url at any point in time?
There are session fixation attacks other than session-ID-in-URL. In particular, browser controls over cross-domain cookies are weak.
If an attacker has control over foo.example.com, for example by means of an XSS hole in an application running there, they can write a session ID cookie with parameter domain=example.com, which will then be passed to your application running at bar.example.com and hey presto session fixation.
As a developer you often don't have any control over what other vulnerable applications might be running in neighbour domains, so it is best to assume cookie injection can happen and recycle sessions on a princpal change.
Well, if the session ID is only transferd by a cookie (is not in the URL and you do not accept one in the URL) then it is not that important to protect against session fixation attacks by recycling the session ID.
However it is still good practice, as this could also help against a session cookie which was laying around longer time (and potentially be placed by a former user). So with most security practices it is the same here: just do it, even if you cant find a way it might get exploited.
I have a Cakephp 2+ site that needs certain actions to require an SSL connection, (i.e. login, password reset, etc.), but I don't require the entire site to be secure. While implementing this I found that the Session was not being saved when moving between the SSL and non-SSL pages. I found this question on stack https://stackoverflow.com/a/12068099/1353839 that solved the issue for me, but I am wondering at what cost.
The answer in the above question required commenting out a line in lib/Cake/Model/Datasource/ as follows:
if (!isset($sessionConfig['ini']['session.cookie_secure']) && env('HTTPS')){
// $sessionConfig['ini']['session.cookie_secure'] = 1; // <-- Commented Out
}
Are there any security ramifications to doing this? Also, is there a way to do this without affecting the cake core files since that is generally frowned upon?
Thanks in advance.
First off, modifying the core file is a bad idea, you should set 'session.cookie_secure' in your configuration instead.
The purpose of a session is to store critical information on the server and associate that information with a client via a session key. The session key is typically stored in a cookie and sent to the server with every request. Using secure cookies prevents the session key from being transmitted to non-SSL pages; that is why you cannot see the session data.
Turning off secure cookies allows the session key to be sent to non-SSL pages, however, it is sent as plain text so it you will be susceptible to session hijacking. Depending on what your doing, this may or may not be a big deal. Regardless, by using SSL for login, password reset, etc... you will protect the information that your users' actually enter (i.e. username, password, etc...).
You are going to authenticate users over SSL so that a MITM cannot intercept the authentication but then afterwards you want to let the session cookie be sent through plaintext HTTP so that the MITM has the opportunity to pick it up and use it for themselves?
Given that, what's the point of using SSL at all?
(Yes, I know your session cookies expire so getting one of those it not as good as getting the actual credentials, but this still sounds like a terrible idea security-wise.)
Don't modify the core files. You can specify the required configuration in your app/Config/core.php. Read the comments in there above the session configuration statement and it mentions how to specify required ini setting.
My friend and I have a pari for beer.
From wikipedia:
Requiring a secret, user-specific
token in all form submissions and
side-effect URLs prevents CSRF; the
attacker's site cannot put the right
token in its submissions
The atacker can use browser cookies indirectly, but he can't use them directly!
That's why he can't put the cookies into the link using document.write()
Let us look how the logout link is generated. Is it secure way? Can this GET request be faked?
function logout(){
echo '<a href="?action=logout&sid='.htmlspecialchars($_COOKIE['sid']).'>Logout</a>';
}
sid is a session ID, generated for every session
on the server side, the following checking is performed:
$_GET['sid']==$_COOKIE['sid']
Absolutely not! Never use session identifiers for CSRF protection.
As far as why? Well, the answer is simple. Doing so opens the door for session hijacking attacks. Imagine someone copies and pastes the link for some reason into an email or onto the web. Now, the person on the other end of the email has the session identifier of that session. Sure, if they click the link it won't activate the session, but someone who knows what they are doing will still be able to use it.
And don't use a secret cookie either. Cookies are transmitted on every request. So the mere existence of a cookie does not verify that the user intended to make the request.
How to do it instead? Follow the OWASP recommendations. Use a unique, random token that's issued on each request and is associated with the session. Then verify that the token is valid on submission and then invalidate the token! It should be a one-time-use token only. Have it submitted by the form, and not attached to a link directly...
This prosed security system is immune to CSRF. The reason why this works is because in a CSRF attack the browser keeps track of the cookie, so the attacker doesn't need to know the cookie value when he is building the request. If this proposed security system where vulnerable to CSRF an exploit like the following Proof of Concept would log out a browser:
<img src=http://victim_site/index.php?action=logout&sid= />
Clearly in this case sid needs a value, and an attacker cannot obtain this value without using XSS, which makes this a moot point. Using xss an attacker can read a CSRF token to forge requests. This was used in the MySpace worm Sammy.
The use of the cookie a valid, however weaker form of CSRF protection. One problem is that it totally undermines http_only cookies. Ideally a CSRF token and a session id should be a Cryptographic nonce. However, it is more secure to have them be separate values.
Edit: This answer is at least partially wrong. Using the session ID as a CSRF token could lead to session hijacking if, eg, links are copy+pasted around. See ircmaxell's answer and comments.
Yes, because the session ID is both random and associated with the user, it would be an acceptable form of CSRF protection.
That said, it would be even safer to use a different random number, on the off chance that malicious JavaScript is able to grab the session cookie (and session ID)… But if I had to choose between “no CSRF token” and “session ID as a CSRF token”, I'd always pick the session as a CSRF token.
The only potential problem with using session IDs as CSRF tokens is: if someone was able to steal a CSRF token, they would also be able to hijack the associated session… But I can't think of a sensible scenario where that would be an issue.
Now, from the discussion on Marc B's answer, below: using a nonce would provide other benefits (like preventing duplicate form submissions)… But it isn't any more secure against CSRF attacks than the session ID (with the one caveat I mention in the first second paragraph).
See also: CSRF Validation Token: session id safe?
And what's to stop someone from editing the HTML that you send them, as well as the cookie, which you've also send them? Both are are under the control of the user.
With firebug I can trivially change the contents of any page, as well as any cookie.
Now, if you'd modified your version so that the SERVER stores that ID, then it would be harder to hack...
$_SESSION['form_token'] = 's33krit valu3';
if ($_POST['form_token'] == $_SESSION['form_token']) {
... everything's ok ...
}
Since the session data is kept on the server, out of the attacker's hands, this is far more secure than trusting the attacker won't think to modify the cookie.
You owe your friend a beer.
Recently we removed jsessionid from URL did cookies based session management to prevent "session hijacking attack"
But we found that first request URL always has jsessionid when cookies are enabled and subsequent request URL has NO jsessionid.
using the jsessionid from first url we could directly hit other pages in the workflow
Question : is there any security vulnerability exposing jsessionid only on first request?
There is a solution to remove jsessionid from first request , but wanted to check , if its really vulnerable to mandate the changes
thanks
J
EDIT : I got my doubt clarified. Thanks for replies.
What you've done here could improve the overall security of the solution somewhat, but won't necessarily prevent session hijacking.
the security issue with placing the session ID in the URL is that URLs are exposed in various places (eg, copy and pasted URLs could expose a live session, URLs can be stored in proxy server logs, web server logs and browser history), which could allow an attacker to grab a valid session ID and get access to your users data.
Ideally you should remove the JSESSIONID from the URL in all places, and only use cookie storage.
Additionally if you want to mitiate Session hijacking there's a number of other areas to consider.
You need to use SSL on all pages where the session ID is passed (this is to mitigate the risk of the session ID being intercepted in transit (eg, the Firesheep attack).
If the session ID is set before you authenticate the user, you should ensure that a new session ID is issued when the user logs in.
Also if possible the session cookies should be use of the httpOnly and secure flags, to reduce the risk of them being leaked over cleartext channels.
There's some good additional information on the OWASP Site
BTW if you've got more question on the security side of things, there's a stack exchange site specifically for that at Security.stackexchange.com
did cookies based session management to prevent "session hijacking attack"
Whats stopping the cookie being hijacked?
Session managment is a server side thing - You need to server to check (based on the cookie) that the user is meant to be logged in.
I don't think you've improved security here at all to be honest, take a look at this excellent article to see why.
If someone gets hold of the session id then they pretty much hijack the whole session, see Predictable Session IDs vulnerability.