My problem is probably a very common one ;)
I want to implement user sessions for a website. The restrictions for this to work are these:
It has to work without cookies, since they can be disabled.
It has to work without passing the session id (or session-related id) inside the GET and/or POST form variables.
It has to work without inspecting the HTTP Referer header field, since this might be empty.
It has to work without JavaScript, since this can be disabled.
The only thing I found was using HTTPS (which is a good choice anyway...) and "Digest access authentication". The only shortcoming is that MD5 is used as the hashing mechanism which is considered insecure.
Is there any way of establishing a user session that cannot be hijacked easily by applying the restrictions mentioned above? And does Digest access authentication solve this and what might be the shortcomings?
Edit:
I found another approach that might work: If the site is HTTPS only then one can grab the SSL/TLS session identifier on the server side (e.g. using mod_perl if using Perl on server side) and use that session id. Note that user association with one such session id must be done separately. But still with this approach the server side always has a valid secured session id.
Is this correct?
As mentioned here: https://security.stackexchange.com/questions/48856/is-using-an-ssl-session-id-along-with-a-cookie-based-session-verification-more-s
The easiest and most secure approach (given the information I gathered until now) seems to be:
The Website is HTTPS only.
The session id is the SSL/TLS session identifier and this id is stored in a database and may or may not be associated with a user account record (user authentication is done using normal forms over HTTPS then).
If anyone has a better approach, I would be glad to read about it.
Related
Steps to re-create the issue:
Login with Admin Credentials and copy the session cookie.
Open another browser, Login as another user, paste the session cookie of the admin. Refresh the page. Now, you'll be
logged in as Admin.
How to solve this issue? Any suggestions would be of great help.
Tried using the event subscriber to get the previous session before drupal loads the cookie session, but no luck with it.
This is not a problem, I mean, of course, Session Hijacking is a really big concern - but standard defences are fine.
These are the controls that I know are widely known/used:
Ensure HTTPS is used everywhere,
Only use a securely created random string for the cookie value,
Set the secure flag on all cookies. This will ensure that they are only sent over an SSL connection,
Change the session cookie on each new login attempt.
All of Drupal 8's cookies are secure by default.
The exception is BigPipe's no-JS cookie, see https://www.drupal.org/node/2678628 — but there are no security consequences there.
I know some very sensitive applications may also store - for each session - the following additional information:
SSL Session ID
HTTP User Agent
Remote IP Address
In my point of view, I wouldn't bother with checking the HTTP User Agent or the remote IP address. They don't add that much security and they will break legitimate use in certain scenarios. Checking the SSL session ID (SSL session binding) would be OK from a security perspective, but could be painful to implement, the other defences are fine.
If your concern is Cookie Theft via XSS, the best defence is to use standard methods to avoid XSS bugs in your web application. See OWASP for plenty excellent resources.
You may find a lot of best practices to write secure code for Drupal 8 here: https://www.drupal.org/docs/8/security/writing-secure-code-for-drupal-8
You may also find a pretty old discussion about this on Drupal here: https://www.drupal.org/project/drupal/issues/19845
I read this article on using Spring Security to "secure" (password-protect) a REST-like service: http://www.baeldung.com/2011/10/31/securing-a-restful-web-service-with-spring-security-3-1-part-3/.
This solution is what I seem to want, however, I noticed that at the bottom of the article, the authentication process is based on a cookie. If you notice, after a user logs in, a cookie is sent back to the user, and the user keeps using this cookie on subsequent request to access the REST endpoints (see the curl commands).
My concern about this approach centers on security; meaning, what's to stop the user from sending this cookie to someone else for use or someone from copying this cookie and using the REST service without proper authentication?
Is there a way to set the cookie (or cookies) such that it is valid for only one user? For example, for only the IP that authenticated correctly? But even this is problematic, as multiple users may share one external IP address.
It looks like the code is just demonstrating how to maintain a session between requests, exactly as your browser would do, by storing the JSESSIONID cookie. So I think your question is really the same as "what's to stop a user from copying the session cookie from their browser and giving it to someone else?". Of course there is nothing to stop them doing that but why would they want to? The same argument applies to any kind of security token. There's nothing to stop them giving away their username and password either which would have the same effect.
In most cases a web service would be stateless, so it wouldn't use session cookies. But OAuth tokens and so on are just as sensitive, often more so since they usually have a longer life span.
I have a standard HTML login page, which I would much rather use than the standard HTTP authentication pop-up provided by browsers. Today, I am using session cookies to keep track of the session after logging in, but I'd like to be stateless and pass the HTTP authentication every time. The web services I am hitting already support this, so this is a browser-only issue.
Adding authentication credentials is trivial in jQuery, but I don't know how to keep them around. If you go from the login page (a jsp) to the Home page (another jsp) you clearly don't keep the username and password fields from the login page. I know some browsers will store your HTTP authentication credentials if you enter them from the pop-up, but I don't know if they get stored when using an XHRRequest. If they do, is there much consistency among browsers?
Also, the user needs to be able to "sign out" of the application, too. If the browser stores the authentication credentials, is there a way to clear them using JavaScript.
I feel like I can't be the first person to try to solve this. Is there some jQuery plugin or something that already handles this? Or is it simply not possible to do what I'm trying to do?
You have 2 options:
1) Client-side storage of credentials -- not a good idea. For obvious reasons you don't want to store the username/password on the client. If you had a hashed version of the password, it might not be so bad, but still not recommended. In any case, if you're going to store on the client side, you either have to use a cookie, or HTML5 local storage (which is not widely supported, yet)
2) Server-side storage of credentials -- typically done with sessions. Then the resultant Session ID can be passed back to the client and persisted in either a cookie or in the URL of each subsequent AJAX call (?SESSID=xyz for example)
The server-side approach would be the most secure, reliable, and easiest to implement
Okay, I'll take a stab at helping ...
Firstly, understand how HTTP authentication works. There are two versions - Basic and Digest. Basic transmits in plaintext, digest is encrypted. With these types of authentication, the username/password are passed in the HTTP header with every single request. The browser captures these at login and they are stored in an inaccessible browser session cookie which is deleted when the browser session is closed. So, in answer to one of your questions, you can't access these from javascript.
You could create your own session cookie variables for username and password. The jQuery functions for this are really simple. See jquery-cookie module as one example of how to set session cookies. These could be retrieved from the session cookie and sent with each ajax request and validated in the server. However, this is not a particulary good way to do authentication since sniffing the network will allow anybody to easily grab your auth details. But, it would work.
Using session cookie based authentication where the session ID is sent sent with each request is the best way to do this. At the server side, you need to have a function called for every HTTP request. This function should do the following:
check to see if the session has been authenticated
if no:
redirect to login screen
if yes:
do authorization and allow the user access to the page
Most web frameworks support session cookie authentication and the management of session ids at the server. This is definately the way to go.
This is interesting one.
Manage user sessions on server by use of cookies. Create a session when user first accesses the login page and pass the session id/key as value to one of the cookie via response. When the user is authenticated put user "key" info in cookie and "values" in application context at server. Once user is logged, any subsequent request will be authenticated based on session cookie value at server. Authorization will be done based on user "key" passed as cookie value.
On logout clear the session based cookies from server and refresh the site to default page.
Cookies are bizarre with different browsers - just a note ;)
Hope this helps.
Update
The answer below was posted in 2012 and the links are mostly dead. However, since then, a more elegant standards-based approach to the same solution appeared using JSON Web Tokens. Here is a good blog post explaining how to use them.
Most answers miss the point, which is to avoid having any server-side session. I don't want any application state in the server. I'll award the bounty to answer that came closest, but the real credit goes to the rest-discuss group and Jon Moore for the correct answer and to Mike Amundsen for helping me to actually understand it.
The best answer I've gotten is to use a cookie, but not the typical automatic session id cookie given to you by most application servers. The cookie (which will automatically be sent with each subsequent request) is a user identifier and time signed by the server. You can include an expiration time with the cookie so it simulates the typical 30 minute session on a server (which means you have to push it forward with subsequent requests) as well as keeps the same cookie from being valid forever.
The XHR/AJAX part is a red herring. This will work whether you are doing XHR requests or an old-fashioned page-by-page web application. The main points are:
The cookie is automatically sent on subsequent requests so there's no
special scripting required - it's just how browsers work already.
The server does not need to store any session for the user, so the user
can hit any server in a cluster and not have to re-authenticate.
Slightly interesting in that you consider pushing some of the authent to the client. If you want a conventional solution, KOGI's server-side suggestion is the way to go.
But you also seem to be asking questions about memory leaks involving your user supplied secrets. Good questions. But to take a general stab at answering that I'd say it would have to be browser specific. It's browser internals, javascript engine internals -dependent where a client side application (i.e., the browser, or js in the browser) is storing the values the user inputs.
Most likely those values are not replicated needlessly throughout memory, but there's no way to guarantee that. Apart from responsible javascript coding practices, there's nothing you can do to guarantee the limit of locations of user inputs.
Slight digression
The basic point is if you store it on the client it is not really secure -- unless, the serve stores encrypted information on the client with a key that only the server (or the user via their correct credentials), has. So you could conceivably code a JS application to do some authent on the client -- much the same as how bank card (used to?) do POS authent by checking the PIN to the PIN on the card, and not back at the DB. It's based on the (somewhat flimsy) assumption the user has no direct read/write access of the "dark area" cookie/local storage on client / mag strip on bank card. So I would only advise this as disqualifier for false authents and not as a sole qualifier for the credentials.
Main point
If you do want to be stateless, just store user credentials in localstorage, or as a cookie but encrypt them with a server key. When you need them send an XHR with the encrypted / use stored credentials to the server over HTTPS, let your server decrypt them and send them to the callback. Then pass those cleartext of HTTPS to do your authent.
I'm trying to make a web service secure.
It's not for a bank or anything of that sort, but the organization using it may lose some money if the service will be used by someone not authorized (it's hard to tell exactly how much..).
The purpose is not to allow unauthorized applications to use any method (other than "GetChallenge". for users authentication there is a different mechanism which checks for username and password. I actually combined the two, but they serve different purposes):
So here's what I do:
I send a (ASP.NET) session key (for everyone to read. ASP.NET's session Is 15 randomly generated bytes, it lives for 20 minutes unless prolonged, and ASP.NET will not receive any request without it).
In my SignIn method, apart from username and password (which anyone can acquire, since it's a part of a public site), I receive a third parameter - the session key hashed by md5 algorithm with 6 bytes as salt.
And only if the hash is correct (I'm hashing and comparing it on the server side) - I let the users sign in.
From then on in every method, I check if the user is signed in.
Added: The username and password are sent as clear text, and that's not a problem (not the one I'm addressing at least). The problem is for someone (other than the company we're working with) writing an application which uses my web service. The web service should only be used by an authorized application.
Also, the session id is sent back and forth with every request and response (as a part of ASP.NET session mechanism. That's how ASP.NET knows to "track" a session specific for a user). Sorry for not clarifying that from the first place.
(irrationally thought it was obvious).
How strong and effective is that security strategy?
Thanks.
Updated based on your edit and comment
It's pretty secure and is very similar to the approach used by Google, Facebook and others for their API keys. Except...
Session ID plain text potential issue
I would recommend against using Session ID as part of a security mechanism.
The one issue is with passing the session key in plain text across the network. There is potential that this could open up some Session hijack and other attacks.
From the Microsoft Docs:
The SessionID is sent between the server and the browser in clear text, either in a cookie or in the URL. As a result, an unwanted source could gain access to the session of another user by obtaining the SessionID value and including it in requests to the server. If you are storing private or sensitive information in session state, it is recommended that you use SSL to encrypt any communication between the browser and server that includes the SessionID.
As you are using the Session ID as part of your security mechanism I would say that is sensitive data.
One way to ensure someone doesn't get hold of your session key is to run your service on HTTPS. Personally I would avoid using the Session ID in this way and generating a non-related value instead.
Recommended change
Follow more closely the model used by Google and the like. Generate a new GUID for each application, store the GUID in a database on the server, pass the GUID in each request to your server from the client.
Benfits:
Identifies the client application uniquely, allowing you to track and manage usage per client nicely
Easily disable any client by removing the GUID from your data store
No sensitive data on the wire
I would still run the service on HTTPS as it's easy to setup and gives the added benefit of protecting any other data you send to your service.
The purpose of encryption is not to
allow unauthorized applications to use
any method
Wrong. The purpose of encryption it to prevent the understanding of data whilst either in transit or stored. It prevents data being 'useable' by those that do not have the means to decrypt.
What you are describing is something similar to a public/private key system. You're making your session key available to everyone. Then only after they've md5 with the correct salt (as per your server side comparison) you're then trusting that source.
You've got NO authentication here except for username and password. Also your data isn't encrypted during transit. I fail to see how this is at all secure.
I think you're best bet is to use an SSL certificate (so your web service is running over HTTPS) along with the username and password. If you want to be doubly secure you might want to go down the route of checking source IP ranges and login locations as an additional check. Perhaps a forced password change interval will help in the case that consumers are passing credentials to a third party + audit how the web service is actually being used.
As a side note if you want to hash something don't use MD5, its broken.
From a web services perspective the ideal way to use authentication or provide security to your service is something like this: Web Service Authentication (Token and MD5 Hashing to encrypt password).
The way you describe it, it does not seem secure at all.
What is the point of letting the SignIn method accept a hashed session key, if the session key is public ("for everyone to read")?
Plus: "in every method, I check if the user is signed in. " How do you check that?
A common (and reasonably secure) strategy would be to generate a (unique, sufficiently long and random) session ID server-side, and send it to the client after it has authenticated. Then check every client request and only accept it if it contains the session ID. To do this, either embed the ID into all links on every page, or set it as a cookie, depending on what's easier for you.
On logout, just delete the session ID on the server.
That way, no one can invoke any method without a valid session.
I am currently working on the authentication of an AJAX based site, and was wondering if anybody had any reccomendations on best practices for this sort of thing.
My original approach was a cookie based system. Essentially I set a cookie with an auth code, and every data access changed the cookie. As well, whenever there was a failed authentication, all sessions by that user were de-authenticated, to keep hijackers out. To hijack a session, somebody would have to leave themselves logged in, and a hacker would need to have the very last cookie update sent to spoof a session.
Unfortunatley, due to the nature of AJAX, when making multiple requests quickly, they might come back out of order, setting the cookie wrong, and breaking the session, so I need to reimplement.
My ideas were:
A decidedly less secure session based method
using SSL over the whole site (seems like overkill)
Using an iFrame which is ssl authenticated to do secure transactions (I just sorta assume this is possible, with a little bit of jquery hacking)
The issue is not the data being transferred, the only concern is that somebody might get control over an account that is not theirs.
A decidedly less secure session based method
Personally, I have not found using SSL for the entire site (or most of it) to be overkill. Maybe a while ago when speeds and feeds were slower. Now I wouldn't hesitate to put any part of a site under SSL.
If you've decided that using SSL for the entire site is acceptable, you might consider just using the old "Basic Authentication" where the server returns the 401 response which causes the browser to prompt for username/password. If your application can live with this type of login, is works great for AJAX and all other accesses to your site because the browser handles re-submitting requests with appropriate credentials (and it is safe if you use SSL, but only if you use SSL -- don't use Basic auth with plain http!).
SSL is a must, preventing transparent proxy connections that could be used by several users. Then I'd simply check the incoming ip address with the one that got authenticated.
Re-authenticate:
as soon as the ip address changes
on a time out bigger than n seconds without any request
individually on any important transaction
A common solution is to hash the user's session id and pass that in with every request to ensure the request is coming from a valid user (see this slideshow). This is reasonably secure from a CSRF perspective, but if someone was sniffing the data it could be intercepted. Depending on your needs, ssl is always going to be the most secure method.
What if you put a "generated" timestamp on each of the responses from the server and the AJAX application could always use the cookie with the latest timestamp.
Your best bet is using an SSL connection over a previously authenticated connection with something Apache and/or Tomcat. Form based authentication in either one, with a required SSL connection gives you a secure connection. The webapp can then provide security and identity for the session and the client side Ajax doesn't need to be concerned with security.
You might try reading the book Ajax Security,by Billy Hoffman and Bryan Sullivan. I found it changed my way of thinking about security. There are very specific suggestions for each phase of Ajax.