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.
Related
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)
So I just noticed that one of the internet banks websites is passing session id as url parameter. ( See image below )
I didn't previously see anywhere that ';' in url, in this case it is after 'private;'.
1) What is the use of this ';'?
2) And why internet bank, which needs to be securest place in the internet is passing session id as url parameter?
At first, I thought they are doing it because some of the users disallow use of cookies, but then again, if they allow it, use cookies, if not - url, but I do allow use of cookies, so obviously thats not the case.
3) I guess then they should have some other security measures? What they could be?
4) And what one can possibly do if he knows others valid session id?
As I know, you can quite easily log into others peoples session if you know that id, because its not hard to edit cookies and its much easier to pass that session id as url parameter, especially if you have something like:
session_id($_GET[sessionid]);
Thanks!
1) You should ask whoever designed the application your red box is covering. URL can be anything you want; the convention of key=value&key2=value2 is just that - a convention. In this case, it's Java, and it commonly uses the convention of ;jsessionid=.... for its SID.
2) It's not that big of a deal. Normal users can't copy-paste cookies like they can copy-paste a GET parameter, but power users can do whatever they want (using Mechanize, wget, curl and other non-browser means, or even browser extensions). And if you allow it for some users and disallow for some, it's not really much of a security precaution, is it? Basically, cookie SID will make the attack a bit harder, but it's like putting your front door key under the mat - definitely doesn't keep your door secure. Additionally, cookies are shared between tabs: if a site wants you to be logged in with two accounts at once, you can't do it with cookies.
3) Serverside security, yes. One effective countermeasure is one-time SIDs (each time you visit a page, the server reads the session from the current SID, then starts a new session with a new SID for the next request). A less effective but still good method is to validate other information for consistency (e.g. - still same IP? Still same browser?)
4) Yes, if you know someone's valid SID, and the server does not adequately protect against session fixation, you can "become" that person. This might enable the attacker to, say, pay his bills with your money, for instance.
So, #Amadan correctly covered #1 and #4. But there's a bit more that needs expansion.
Using Session identifiers in a URL can be a major problem. There are a few cases where it's critically bad:
Session Hijacking:
If a user copy-pastes a URL into an email.
In this case, the attacker can simply read the email, and steal the session identifier (thereby resuming the session).
You could partially defend against this by making session lifetimes short, and validating things like IP addresses or User Agents in the session. Note that none of these are foolproof, they just make it "slightly" harder to attack.
If the connection is ever downgraded to HTTP.
If they are not using Http-Strict-Transport-Security (HSTS), then an attacker may be able to successfully downgrade the session to HTTP only (via MITM style attack). If the server isn't setup perfectly, this can cause the URL to leak to the attacker, and hence the session identifier.
Session Fixation Attacks
An attacker can craft a session identifier, and send the user a forged link with that session identifier. The user then logs in to the site, and the session is now tied to their account.
You can mitigate this by strictly rotating session identifiers every time the session changes (log in, log out, privilege upgrade or downgrade, etc). But many servers don't do this, and hence are susceptible to fixation style attacks.
The reason that cookie sessions are seen as more secure is not because they are harder to edit. It's because they are more resistant to fixation attacks (you can't create a URL or link or form or js or anything that sends a fraudulent cookie on behalf of the user).
Why the bank uses a URL parameter? I have two guesses:
Because they want to support those who don't allow cookies.
Which is sigh worthy.
They don't know any better.
Seriously. If it's not in a compliance doc or NIST recommendation, then they likely don't do it. Hell, there are implemented NIST recommendations that are known to be insecure, yet are still followed because it's in writing.
What is the use of this ;?
This is just a query string separator. & isn't the only sub-delim specified in the URL specification (RFC 3986).
And why internet bank, which needs to be securest place in the internet is passing session id as url parameter?
It could be that this session ID is never used, and the actual session identifier user is passed in cookies or in POST data between each navigated page. The only way to verify this is to try copying the URL into another browser to see if your session is resumed, however then again they may be checking things like User Agent - not real security but would dissuade casual attacks. Do not try this on a live system you do not have permission to do so on as it would be illegal. If you want to learn about security download something like Hacme Bank and try on there.
I guess then they should have some other security measures? What they could be?
No doubt they will, otherwise this would be a huge security threat. The URL could be leaked in the referer header if there are any external links on the page. The types of security a bank uses for their website is too large to list here, however they should be meeting certain industry standards such as ISO/IEC 27001 that will cover the types of threat that their site would need to be secure against.
And what one can possibly do if he knows others valid session id? As I know, you can quite easily log into others peoples session if you know that id, because its not hard to edit cookies and its much easier to pass that session id as url parameter, especially if you have something like:
As the ID is displayed on the screen it might be possible to read it (although IDs are generally long). A more realistic attack is Session Fixation. This is where an attacker can set the Session ID of their victim. For example, sending them a link that includes the attacker's Session ID. When the victim follows it and then logs in, as the attacker has the same session, they are logged in too.
Storing the Session information in a cookie or in a URL are both viable methods. A combination may used as
Security session management and (Server) Session management are separate aspects:
The fundamental difference is that cookies are shared between browser windows/tabs, the url not.
If you want your user to be logged on when navigating to the same site in different tab, sharing the security session (=without a new logon procedure) then cookies are a good way.
To differentiate "sessions" per tab and associate distinct server sessions with distinct tabs (Think of the user running two "stateful" transactions in two different tabs in parallel), managing a sessionId on the client which can be different per tab is required. Cookies won't work here.
Putting it in the URL is one way to assure this information is routinely added to requests fired from the page (referrer header). Alternative methods would require specific code to add this information explicitly to each request which is more work.
See How to differ sessions in browser-tabs?
in web application like a society networks users log in and do some works for long times like 2 hours or more, now i store some data like user ID (identity number in member table) in session and found users details data by this id .
and when each user log in to site i store this data for that user on session for 2 hours.
for this work i set my session time out on 120minutes and i want to know is this work good?
i mean storing session for 2hours.
in another hand i can store that ID on encrypted cookie on client and i want to know is this way secure and if user/hacker can decrypt my cookie and retrieve user id (this id is my identity table id) can attack to my site and do some thing or not?
In the world of Web, information storage connections in the session variable is wrong path. You do not control the session variable and can be lost at all momments.
I do not know the architecture used, but on an IIS server you can configure the encryption key for the authentication cookie in your Web.config file on your site web
<machineKey validationKey = "AutoGenerate, IsolateApps"
decryptionKey = "AutoGenerate, IsolateApps"
validation = "SHA1" decryption = "Auto" />
It is not possible that this information is hack on client side.
This is the better way
The problem with storing identification with a cookie is probably not decrypting the cookie but steeling the cookie as whole. This is common session and permanent cookies.
If you want to not to bother user with new login while the site is still active in browser consider shorter session timeout combined with a javascript keep alive (e.g. page refresh each 10min). Otherwise you have on server lot of sessions no longer needed.
If you want to keep user loged in even if browser window is closed. Consider including a browser identification information in the cookie (e. g. Is browser fingerprinting a viable technique for identifying anonymous users?) with good server encryption.
Don't forget to force https.
Do not store in an encrypted cookie. Store in a signed cookie. It's different, here is the why:
https://spring.io/blog/2014/01/20/exploiting-encrypted-cookies-for-fun-and-profit#modifying-the-decrypted-value
The 'old' alternative of having a session, is a bit less scalable than relying on a signed cookie, but it should be more secure, even if someone like NSA has all kinds of ways to go around signing/encryption. ** ˆˆparanoid statement ˆˆ ** but then again, if they have that, they will most likely also have man in the middle access and all sorts of sessions would be pointless.
There are a lot of questions and answers about session fixation on StackOverflow, however, I am still confused about one thing. People often suggest that storing session in cookies is not enough to overcome the session fixation issue and you should rotate the session id after login. I can imagine that if you only use the session id to identify a user, you may still be vulnerable to an attack. However, I would like to ask about one specific case.
Let's assume that you use a signed cookie to store the whole session. On login you put into the cookie an id identifying the user. After logout, you delete the id. You do not change the session id, but as you change the session itself and you sign it, I cannot see any attack scenario taking advantage of this design. Is session fixation still an issue and, hence, is session id rotation still necessary in this case? If yes, can you provide an attack that could be used? Thank you.
The basics of Session Fixation is that it’s possible for an attacker to make the victim use a session that the attacker has access to. This is generally done by inducing the victim to use a certain session ID that is known to the attacker and doesn’t change after authentication.
Now what you’ve described doesn’t sound like a session identifier but rather a simple client-side data storage of user authentication data.
But nonetheless, if you make the cookie data dependent on data that again depends on the authenticated user which additionally is signed by the server, it certainly will change after authentication and won’t be known to the attacker. Then the security of that scheme depends on its actual implementation.
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.