If you put sit Paros on the traffic between your browser and a web application being hosted in WebSphere, you will have two session identifiers passed as part of the cookie section of the HTTP request:
A JSESSIONID. This is your HTTPSession ID as far as I can tell.
An LTPA2 token. This is your “single sign on” session as far as websphere is concerned.
Now, IBM say that a single hosted application cannot invalidate the LTPA2 token when a user is signing out. The thinking behind this is that it is an SSO identifier, so a single application should not be able to invalidate it as it is intended for use across multiple applications. There is no configuration in WAS to declare “this environment hosts only one application so therefore that app can invalidate the LTPA2 token”.
What is worrying is that these LTPA2 sessions hang around for a configurable amount of time. Therefore, if another user got a handle on a users’ LTPA2 token, they can use it to access that users’ session and therefore their sensitive data.
You can prevent a man in the middle attack to capture the session value by forcing the transmission of the cookie to occur over SSL, and by specifying HTTP only for cookies. However, I am still worried about the cookie being available on the local machines’ hard drive. The browser has to store it somewhere, so therefore there has got to be a way to get access to it?
My question is, is it possible for someone to get an LTPA2 value such as this from the hard drive? Say someone sits down in a library, signs in to their online banking, does some work and then logs out. Is it possible for the next user to get the LTPA2 token somehow?
I tried searching through the directories where I thought FireFox 4 and IE8 would store the cookie, but couldn’t pattern match the value. My gut instinct is that it may be possible to find this data on certain browsers?
By default the LTPA2 token is a "Session Cookie" Websphere does not set an expiry on that cookie, and it is just stored in Browser Memory until the user closes their browser.
Unless your client is explicitly manually pulling that cookie and storing it client side, it will not be stored in any files on the user's machine.
You can invalidate the LTPA token if you want to.
But this would require using IBM extensions (naturally)
Look at these:
(a) http://www.ibm.com/developerworks/websphere/techjournal/1003_botzum/1003_botzum.html
LTPA token is non-standard, but is simply a credential/token and does not impact the application development team.
Redirects to the ibm_security_logout URL in order to remove the LTPA token when users log out.
(b) ftp://ftp.software.ibm.com/software/dw/wes/0409_botzum/WAS-511-Security-AdvancedTopics.pdf
Though these articles are old, these should still work (as these basics haven't changed a lot over the years)
By invalidating the LTPA token(which as Terrell mentioned in a "in memory session cookie" )all your worries that you had should be gone.
HTH
Manglu
Related
I am building a Web Application using Angular 2 and the backend service built in ASP.NET Core Web API.
For authentication, I am thinking of using JWT and storing the token in a Secure HttpOnly Cookie.
For extra security, I am also thinking of capturing the IP Address for the user on the initial login and on each request after the initial login, revoking the token if the IP Address changes.
So the questions I have are:
Is this extra level of security worth it?
Will there be any problems with the IP check I am thinking of using? Based what I know about networking, I don't think an IP Address will legitimately change between request. Even if it does, I think it would be very rare. However I am not going to pretend I know enough about networking to confirm that.
Edit 1
(In response to an answer).
Thank you for answering my question. I have responded to a few of your responses.
My initial thought was that using JWT in a cookie to connect to an API is not the typical use case, why don't you use a standard MVC app then, but that's not your question and actually it's equally secure as long as the token is in a secure, httponly cookie (and of course the implementation is correct). It's just a bit unusual I think.
I am not sure why you consider using cookies this way unusual?
Is it because most of the time cookies are used for session state? I personally think storing a token in a secure cookie instead of keeping the token in a http header or local storage should be a very typical use case because of how much more secure it is. Unless I am missing something?
So I guess I will ask what is the disadvantage of doing it this way?
It depends. If you are worried about session theft, probably yes. If you keep the token in an httponly cookie (protected against xss), that's more secure than a token anywhere else, but still, your threat model may show different threats and validate your concern. The usual problem is you can't do this, see below.
This application will be dealing with a lot of PPI information so I do have a concern on token theft.
Most probably, there will be problems. It depends on your users, how and from where they use your application. If they use mobile devices, IP addresses will change a lot and such a solution is out of the question. If they are corporate users in a company internal network, it can be feasible. Anything inbetween is a gray area. A typical home user will have their IP changed once in a while, most people get dynamic IP allocation from their internet providers. An IP lease typically lasts a few weeks (at least where I live), but ISPs can configure it any way they want, it can be a day or even shorter.
My impression with IP address lease renew is majority of the time the client gets the same IP address. However I should not make that assumption I suppose?
However I can see this can be more of a problem with mobile devices. Some of the clients will be on the road often so this is a good point you have made that can become a problem.
One typical solution you can choose to do is offer this option on the login screen. If a user chooses to use IP address validation, he opts for greater security but accepts the fact that sometimes he may have to log in again. Or he can choose lower security with his session being more stable. Whether it's worth to explain this to your users is I think a business decision.
Never thought about giving the client an option which does sound like a good idea.
Edit 2
(In response to an answer).
Also I'm not sure whether your JWT only has a session id or if your server is stateless and all session data is in the JWT. In the first case, you don't even need the JWT, you could just pass the session id as normal, and standard .Net MVC does that for you. If it's session data too, JWTs are unencrypted by default, so session contents will be visible to endusers, which may or may not be a problem. (And a JWT is protected from tampering by its signature, so it's only about confidentiality, not integrity). Storing session data in the JWT and the JWT in the cookie may also face cookie size issues, depending on your target browsers.
My backend ASP.NET Core Web API will be stateless. The decision has already been made to use Angular so discussing is a moot point.
As for why I think using a JWT this way is a little unusual: I think JWTs are mostly used when tokens need to be passed to different URLs (to different services). For this purpose, httpOnly cookies are obviously inadequate because of the same origin rule. If you can afford using httpOnly cookies, you could just store your session info on the server side.
A much as I would like to discuss the above topic because my solution could be flawed, I think the powers that be may close this post for getting off topic?
Might be more appropriate to ask a new question targeted toward the above subject?
As for lease renews resulting in the same IP: Well, they don't always. It depends on your business case, but some ISPs give you IPs only for a short time. If it's ok for your users to get logged out once in a while, then it may be ok for wired (home) users. And it is definitely a big problem with mobile devices.
My initial thought was that using JWT in a cookie to connect to an API is not the typical use case, why don't you use a standard MVC app then, but that's not your question and actually it's equally secure as long as the token is in a secure, httponly cookie (and of course the implementation is correct). It's just a bit unusual I think.
On to the point, your question is very valid as is your concern about problems.
Is this extra level of security worth it?
It depends. If you are worried about session theft, probably yes. If you keep the token in an httponly cookie (protected against xss), that's more secure than a token anywhere else, but still, your threat model may show different threats and validate your concern. The usual problem is you can't do this, see below.
Will there be any problems with the IP check I am thinking of using?
Most probably, there will be problems. It depends on your users, how and from where they use your application. If they use mobile devices, IP addresses will change a lot and such a solution is out of the question. If they are corporate users in a company internal network, it can be feasible. Anything inbetween is a gray area. A typical home user will have their IP changed once in a while, most people get dynamic IP allocation from their internet providers. An IP lease typically lasts a few weeks (at least where I live), but ISPs can configure it any way they want, it can be a day or even shorter.
So reality is if you have a normal, usual userbase, you will most probably run into problems.
One typical solution you can choose to do is offer this option on the login screen. If a user chooses to use IP address validation, he opts for greater security but accepts the fact that sometimes he may have to log in again. Or he can choose lower security with his session being more stable. Whether it's worth to explain this to your users is I think a business decision.
Update in response to Edit 1 :)
As for why I think using a JWT this way is a little unusual: I think JWTs are mostly used when tokens need to be passed to different URLs (to different services). For this purpose, httpOnly cookies are obviously inadequate because of the same origin rule. If you can afford using httpOnly cookies, you could just store your session info on the server side. Also I'm not sure whether your JWT only has a session id or if your server is stateless and all session data is in the JWT. In the first case, you don't even need the JWT, you could just pass the session id as normal, and standard .Net MVC does that for you. If it's session data too, JWTs are unencrypted by default, so session contents will be visible to endusers, which may or may not be a problem. (And a JWT is protected from tampering by its signature, so it's only about confidentiality, not integrity). Storing session data in the JWT and the JWT in the cookie may also face cookie size issues, depending on your target browsers.
As for lease renews resulting in the same IP: Well, they don't always. It depends on your business case, but some ISPs give you IPs only for a short time. If it's ok for your users to get logged out once in a while, then it may be ok for wired (home) users. And it is definitely a big problem with mobile devices.
I think you can do it with JWT and IP. When the user logs in. Capture the IP for the length of the session. At every login Capture IP then use that to validate the Token is from the owner who started the session. If another IP hits the system. force a revalidate and new token. IP+JWT+Password = login. If you had mobile apps that required 1 login and always remember the login. User never has to enter login again. Then cache the userid\password in the application {securely} and then resend it automatically when the IP changes. JWT is secure when using SSL Difference between SSL and JWT
Sorry for reviving this, but lately I have been thinking a lot about encryption and security and thought of something (that I guess is pretty similar to what HTTPS does)
When user logs in, the server responds with a normal greeting (user info, JWT and whatever other data you need to pass) + you will pass a public key
Have a backend that supports any asymmetric encryption method (I like RSA) and have your front (also needs to run the same encryption method) end receive the public key, encrypt the data, and send it to the server with every subsequent request.
If any of the data that the user needs to provide changes, revoke.
You can even keep track of a clock, if its off by too much, revoke.
For extra layer, have the client transmit a public key on login/signup and boom, hermetic comms like a hazmat suit.
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?
Most Web Applications use cookies to manage the session for a user and allow you to stay logged in even if the browser was closed.
Let's assume we did everything by the book to make sure the cookie itself is safe.
encrypt the content
set http only
set secure
ssl is used for the connection
we check for tampering with the content of the cookie
Is it possible to prevent someone with physical access to the machine to copy the cookie and reuse it on another machine and thus stealing the session?
It doesn't make sense to "protect" against this. If this kind of copying happens, then either:
The end user did it on purpose because they wanted to change computers. This is, of course, not something you should care about or be concerned about.
An attacker has already compromised the user's browser and gotten access to the cookies stored inside. By definition this cookie is a secret that proves that the identity of the HTTP client. If the attacker already has access to it, they can already use it in any number of ways of their choosing that you won't be able to prevent or distinguish from the real user accessing the server legitimately.
This risk is inherent in using cookies to authenticate sessions: the cookie is a bearer token, anyone who can present the cookie is authenticated.
This is why you see further protections such as:
automatic log out after a certain amount of time, or period of inactivity;
device fingerprinting;
requiring re-authentication for critical actions (e.g. making a bank transfer or changing your password).
I'm building a Flex client against a Struts backend and I have to find a way to transmit the session token without relying on cookies, because I can't use cookies in a Flash movie.
I'm looking at putting the token in either the message body or the URL. Putting it in the URL has somewhat of a bad reputation, security-wise. However, I just read up on session hijacking, CSRF and XSS, and I couldn't really see why it should be worse than cookies. If anything, not having a cookie that is transparently sent along whenever you access a particular domain is more secure, or is it?
Basically, the only reason I can see is that the token is visible in the request and might be leaked via the browser history, a web server log etc. How bad is this really, and are there ways to mitigate risks? What other risks might there be?
How bad is this? Well, one of our competitors had a link from their internal (session based pages) to our site and I saw it on the server logs. Quick copy and paste with the /sess/sess_34984923_34423423/ type stuff and I was logged into their system with full access permissions of that user (luckily, they weren't an administrator and it wasn't anything "super secure" like a bank/email etc: but still).
Also, depending on how exactly you implement it, the full url (including the session token) could be cache by proxy servers and even by Google (if people use the Google toolbar).
The way I've done this Flash session interactivity is to send a session identifier in the Flash parameters (in the HTML) to the Flash which then sends it back to the server. I've found most browsers/Flash combinations also send the cookie which I further authenticate against.
I have an anecdote for you. I was filling out some paperwork for a well known company in the US. They printed out a confrontation page generated by a web application, how do I know? At the bottom of the page Window's print manager included the URL which had the JSSESSIONID.
Let me be clear, the employee just handed me a sheet of paper that would allow me to login immediately as if I had their username and password. DOAH!
I suggest you further read on a very severe security topic called Session Hijacking which allows a malicious attacker to impersonate to a user once he have his session id.
I would like to improve security on a current application regarding session management and I want the users to be logged in until they explicitly logout.
How does one implement that securely?
Keep session information in database, like sessionid, ip, useragent?
Please provide the requirements, possibly a database layout, do's and don'ts, tips and tricks.
Note:
I know frameworks like asp.NET, rails, codeigniter, etc... already take care of that, but this is not an option. Actually it for a classic asp application. But I think this question does not relate to a specific language.
Read Improved Persistent Login Cookie Best Practice (both the article and comments).
You should know that such a system cannot be secure unless you use https.
It's quite simple:
User logs in.
The server sends the user a cookie with an expire date far in the future.
If you want, you can record the IP of the user.
User requests another page.
The server checks the cookie (possibly the IP stored with the cookie), sees that the user is logged in, and servers the page.
Some security considerations:
As stated above, there is no secure way unless you use https.
If you're using shared hosting, try to find out where your cookies are stored. Often they reside in the /tmp directory, where every user as access to and through that someone could possibly steal your cookies.
Track the IP, if you know that the computer isn't ever going to change it.
Don't store any information in the cookie. Just store a random number there and store the information belonging to it on the server in a database. (Not sensitive information like preferred colour can be stored in the cookie, of course.)
Create a cookie with a ridiculous expiry like 2030 or something. If you need session state, keep a session ID in the cookie (encrypted if security is priority) and map that to a table in a database. IP/UserAgent etc. tend to be meta-data, the cookie is the key to the session.