I have to create a web application that deals with user's sensitive information. I need to immediately clear the browser's cache after user logs out since cached data would be vulnerable.
Client's browser should be enforced to clear the Cache from server side. Also all cache policies must be exposed to the client from the server side.
Is there any solution to this problem?
Set the response to expire immediately, and for good measure tell proxies, etc., not to cache:
Expires: 0
Cache-control: private
Related
I have an API in Next.js (NextAuth.js) that only the frontend will be using. It uses cookies for authentication. My question is could a malicious website change the user's data using CSRF? Should I implement CSRF tokens or can I prevent malicious websites from changing the data without it?
If authentication is based on something that the browser sends automatically with requests (like cookies), then yes, you most likely need protection against CSRF.
You can try it yourself: set up a server on one origin (eg. localhost:3000), and an attacker page on another (eg. localhost:8080, it's the same as a different domain, controlled by an attacker). Now log in to your app on :3000, and on your attacker origin make a page that will post to :3000 something that changes data. You will see that while :8080 will not receive the response (because of the same origin policy), :3000 will indeed receive and process the request. It will also receive cookies set for :3000, regardless of where the user is making the request from.
For mitigation, you can implement the synchronizer token pattern (csrf tokens), double submit, or you can decide to rely on the SameSite property of cookies, which are not supported by old browsers, but are supported by fairly recent ones, so there is some risk, depending on who your users are.
I'm trying to prevent a valid authentication cookie replay attack on asp.net core application which is using default identity.
I have tried a few things but nothing seems to be working. Once the user is logs off from a session, I can see that I can still replay the authenticated request again using the old cookie.
Is there a way to prevent this?
Thanks
ASP.NET Core is not keeping track of sessions server-side. All session information is contained in the cookie itself (see this issue).
If you want to prevent replay attacks you need to keep track of session yourself. A convenient way to do so is to implement an ITicketStore (see SessionStore). Hint: make sure that your store survives an IIS reboot if you don't want your users to experience a logout.
Before doing so, of course you need to assess a replay-attack is a real danger to your setup. Quoting this article:
If you make sure your site is only ever served over HTTPS, and your cookies are set as "secure", "same site", and "HTTP only", then an attacker will not be able to obtain the cookie value unless they have managed to perform a man-in-the-middle (MitM) attack. And if they've done that, you've got much bigger problems.
And:
Another concern would be if their computer or browser is compromised by malicious code. But again, if that happens, they've got bigger problems to worry about.
I try to do a simple auth system with NodeJS.
I want to save the status of login (logged or not) in cookies in browser.
Can anyone read cookies and then add the same cookie to his browser and pretend he is logged?
Is this good way to save the status of login?
Look at the node/npm module client-sessions (from the Mozilla team). It allows you to create encrypted cookies that are stored securely on the client so you don't have to worry about tampering.
This does have a couple of downsides:
You are limited in size to what a browser will store in a cookie, generally 4K is a safe number, so if you need a session bigger than that you will need some backend storage/cache to hold it and use just a key in the cookie.
You cannot invalidate a cookie once it is on the client with a given expire time. You can always use other checks and reset the expiration to now/0/etc but you have to handle that with some backend storage/cache.
I find that a combination of the cookie for authentication with whatever you use for a user database and/or a cache (like redis maybe) make for a good architecture.
I'm fairly new to website development. I'm working on a site where the user logs in with username/password, and gets a sessionID from the server in response. This sessionID is sent back to the server (and a new one returned) with each request.
I'd like the site to work properly if the user opens it in multiple tabs or windows. i.e. once logged in at one tab, opening a members-only URL in another tab works without loggin in. (And, logging out in one tab logs out from all.) I see no way of doing this without storing the latest sessionID in a cookie. That way the latest sessionID can be "shared" among all tabs.
However I am starting to read up on cookies, and some of the security threats. I was unaware that cookies were sent with every request. I don't need to send my cookie to the server, ever. The sessionID is added to the xhr request's headers -- not read as a cookie. So I'm wondering if there is a way to disable sending of this cookie. My only purpose for it is to allow multiple tabs/windows in the same browser to share the same session.
I was reading up on the path parameter for cookies. Apparently this can be used to restrict when the cookie is sent to a server? What if I set the path to something that would never be used? Would this prevent the cookie from ever being sent out automatically? I only want to access it from JavaScript.
A coworker has put a lot of safeguards into the server-side of this application, which I won't go into here. So this question is just about what client-side precautions I can and should take, particularly with cookies, for optimal security. If there is a better way to allow a members-only site to work properly with multiple tabs open at once, I'm all ears.
I discovered just now that in HTML 5 there is local storage, which stores key/value pairs much like a cookie, but is not sent with every server request. Since it's supported in every browser except IE 7 and earlier, I'll be switching to this to enable sharing data between tabs when available, and use cookies instead on IE 7 and earlier.
The sessionID is stored in a cookie already there's no need to manage it. Because the HTTP protocol is stateless the only way to maintain state is through a cookie. What happens when you set a session value the server will look up the dictionary of items associated with that cookie id (session Id).
What is meant by stateless is that between requests HTTP does not know if your still alive or have closed your browser. Therefore with each request the browser will attach all cookie values to the request on the domain. SessionId is stored in the cookie automatically when they go to your site. The Server then uses that value to look up anything you've set in the users session.
Depending on which programming language and/or server you're using the session could be handled differently but that's usually abstracted away from the programmer.
Now with respect to sessions, there are a number of different things that make them insecure. For example if an attacker were able to get their hands on your session cookie value they could replay that cookie and take over your session. So sessions aren't a terribly secure way of storing user information. Instead what most people do is create an encrypted cookie value with the users details, the cookie could be a "session cookie" meaning as soon as the user closes their browser window the cookie is thrown away from the browser. The encrypted cookie contains user information and role information as well as some identifier (usually the clients ip address) to verify that the user who is submitting the request is the same user the cookie was issued to. In most programming languages there are tools that help in abstracting that away as well (such as the ASP.NET membership provider model).
Check out some details on the HTTP protocol and HTTP cookies on Wikipedia first
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
http://en.wikipedia.org/wiki/HTTP_cookie
and check out the membership provider model on ASP.NET, it's a really good tool for helping to secure your site.
http://msdn.microsoft.com/en-us/library/sx3h274z(v=vs.100).aspx
Preventing the browser sending cookies seems to defeat the object of using cookies in the first place.
If you don't want the sessionID to be sent with each request, why set the cookie? A better solution would be to use a custom response header that you send from the server to the browser - this will then be under your control and will not be sent automatically with all browser requests. You are using request headers to send your sessionID anyway so you could receive them from the server using a custom header and read this into your JavaScript from each XHR.
I've been asked to analyse an old web app which stores sensitive information in cookies rather than sessions/similar. (To be precise, it's classic ASP and uses cookie families). The only clients are IE 6/7/8
After the process in question has been completed on the web app, the cookies are cleared down.
The question I need to answer is: once this has happened, how hard would it be for someone to recover the information in the (deleted) cookies?
My understanding is as follows but I would appreciate some confirmation / any additional issues anyone can think of.
The cookies shouldn't be intercepted across the network as they're passed via SSL. They could be viewable in server memory/log files (the app has v. comprehensive logging)/memory dumps (?)
On the client, the cookies are stored in a text file. When the cookie is cleared down, the text file is deleted.
Although the file could be recovered by undeleting it, I believe this is encrypted by ie when it's first written? (I can't test this on ie6 but it seems to on ie7 for http and https)
Assuming it IS encrypted, can anyone confirm how secure this is?
I'm also looking into how the cookies are stored in memory and how easy it would be to retrieve them - Any advice on this would also be appreciated.
The cookies are used to access a database but again, all connections use SSL so this shouldn't be an issue. The database is locked down.
I can't see any other ways of an unauthorised user accessing the cookie contents. What - if anything - am I missing?
We're likely to change the mechanism used anyway but I do need to provide a clear list of vulnerabilities for the current system before we can proceed (to make sure they're all addressed).
Many thanks for any help you can provide.
Storing sensitive information is the vunerability, this means that one way or the other your system can be attacked by stealing information in these files.
The attack is most likely to come from the client side (if your server can be attacked that's already a problem). The only question is how the cookie can be retrieved from the client machine. Since you're using https this only leaves for someone accessing the cookie on the client machine. The vulnerability lies here. All browsers store cookies on the disk and I would doubt they encode them (why would they?). I would look into how IE7, Firefox, Google Chrome and Safari store these cookies but probably not in a really secure way. The biggest vunerability is probably here: if someone writes a program to collect this data and is able to deploy it.
If I were you I would change the application to use sessions instead cookies ASAP. The longer you wait, the bigger the risk that someone can access these credentials.