I was wondering if allowing the user of a site to access and modify cookies with javascript from the console is a security issue? What harm can be done by allowing users to have this? Is it only considered a security issue in some situations but not others? Also does using HttpOnly cookies prevent the user from modifying cookies?
You are talking about two different scenarios:
Allowing JavaScript to read/modify cookies
Can a user modify cookies if they are flagged as HttpOnly
1) Allowing JavaScript to read/modify cookies.
The reason you normally do not want JavaScript being able to access cookies (reading or writing) is that most site use cookies to handle site authentication. It is common for attackers to create an exploit of Cross-Site Scripting (XSS) on a web site, and use that to read the values of the authentication cookie and send them to a server the attacker controls.
When the attacker has the session cookies, there is a chance (depending on the security of the site) that the attacker can insert the victims authentication cookie's values into the attackers session. Then when they go to the target site, they are treated as the victim and can do anything the victim can do.
Stealing cookies is not the only thing that can be done through XSS, to read more, look at OWASPS - A3 Cross-Site Scripting write-up.
2) Can a user modify cookies if they are flagged as HttpOnly
Yes. The user can modify the cookies, html, css, JavaScript, anything that is on their machine. That is why secrets should never be stored on the client's computer, and ANY values coming from the client/user's computer needs to be considered untrusted until proven to be valid.
Related
I've read that save token JWT in localStorage is a bad practice.
https://dev.to/rdegges/please-stop-using-local-storage-1i04
I'm working with ReactJs, and to other side have a API Rest with NodeJs.
Where and how I should save token JWT ?, in a Cookie?
Gretting from Chile,
If the choice is between cookie and localStorage, both have their pros and cons when it comes to security. With all security attributes set correctly (HttpOnly, secure, SameSite=strict) it is true that a cookies could be more protected against certain attacks.
However, SameSite attributes may not work for everyone, and may not protect all functions against CSRF (Cross Site Request Forgery) attacks.
HttpOnly will protect the value from being accessed from JavaScript which is good if the application suffers (XSS) Cross Site Scripting vulnerabilities. However, any moderately qualified attacker could easily achieve what they wanted without accessing the actual value of the token anyway.
The thing to remember when storing tokens in localStorage is that it is not cleared when the browser is closed, meaning that a user will not become logged out by closing the browser - which many have come to expect. If that is a problem, you may want to consider storing the JWT in the sessionStorage instead.
localStorage seems fine because many people are using localStorage.
If you want extra security feature
You can make your token lifespan short eg {30 min, 60 min}
Also You can check your user active state whether or not
The user will Logout automatically
I am setting http-only cookie from the server for storing some user info so that i can validate user on backend. Say some hacker steals this cookie from someone's browser and go to my webpage and add the same cookie using document.cookie = "cookie_name = cookie_value" if cookie is not there. If cookie is there then he can delete the existing http-only cookie using chrome developer tool and later add it using document.cookie = "cookie_name = cookie_value" on his browser.
Now when server gets a call from hacker browser, it gets a cookie set by hacker and would validate it. How can i stop this?
Cookies leave you vulnerable to Cross-Site Request Forgeries and their kin. Not just hackers stealing cookies, but hackers borrowing a user's browser which already has the cookies. This is part of why tokens are more common today.
If you have to use cookies, there are various things you can do to make them slightly less insecure--updating the cookie on each request, verifying request IP against sending IP, configuring your web pages not to allow the loading off offsite content, forcing re-login for any major actions, and other user verification means. None of them is perfect.
Simple: You cannot. http-only serves a different purpose than validation. Your assumption that a hacker will use a browser is the first problem you have. I would never use a browser for something like that since a browser would restrict me. I would forge a HTTP request with my own tools and send a header with http-only and secure and whatever you want me to to your server.
If you want to validate your cookies, you will need to implement your own solution instead of relying on browser mechanisms. You could for example bind the cookie to a certain IP range and add some kind of token to the end of the cookie-key or cookie-value.
In general, do what #bryanx says. DO NOT USE COOKIES TO STORE DATA. They are fine for session tokens and the like.
Don't use cookies.
Cookies are necessary for preserving information between sessions, but any time you leave information on the client, you open yourself up to potential issues like you described. If you only need the information maintained during the user's session, you may want to consider using a $_SESSION instead of a cookie.
If you must use cookies, you may want to consider building out logic that if the cookie doesn't match a previously authenticated device, that you challenge the user again for their credentials. There are many ways to solve for this, just get creative.
Let's say I set a domain-specific cookie from within the browser, like so:
document.cookie="foo=bar;domain=.baz.com"
Is this cookie susceptible to CSRF? I haven't been able to find a clear answer to this question. We currently have an auth system set up using JWT's, and I'm trying to figure out how to extend these sessions across domains.
Yes.
CSRF attacks cause the victim to perform an unintended action on a site on which they are already authenticated. It works by tricking the user to submit a form (or similar action). The source of the submission can be hosted on any domain but the target is the site they are logged in to. Because the cookie was set by the original site, it will be sent along with the unintended action.
All cookies have domains. If you as a developer don't set them, the browser uses the current hostname as the domain. The fact that the domain is specifically set to match more hosts only makes the potential target sites larger.
See Cross-Site Request Forgery (CSRF)
I'm using cookies in my Java EE application (jQuery on the client) and while taking security as a key point, I came to know that one can read the cookies and edit them by reading article's. I'm really want to make application out of these attacks.
I read How to prevent Javascript injection attacks within user-generated HTML on SO and didn't find a solution to make my cookies secure.
There are several flags you can set for cookie to mitigate the security risk.
The secure flag. It mandates that cookie should only be sent through https. This is important, even when your site is using https. Why? Let's say a bank site forces end user to use https. The user connects to the bank site through https, login successfully. The bank site sends the cookie back to the user browser through https. Assuming a hacker can sniff the network and see all the cleartext communcation between the end user and the bank site. Obviously for now, the hacker cannot see anything, as the cookie is transmitted through secure channel. Here is what the hacker can do if the HttpOnly flag is not set
a) The hacker creates a site www.maliciouscode.com.
b) He sends an email to the end user with the link, luring the end user to the site.
c) The user takes the bait, connecting to http://www.maliciouscode.com site through another browser tab.
d) The malicious site redirects the user browser to the bank site through http.
e) The user browser sends the cookie through HTTP to the bank site.
f) The hacker intercepts the cookie since it is sent as cleartext, places it in his own browser and login as the user
The HttpOnly flag. The name is misleading. It is not the opposite of the secure flag. It means the cookie should only be used by browser through http (and https) protocol only, but not used by other means such as JavaScript. If a browser that supports HttpOnly detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, the browser returns an empty string as the result. This is to prevent the XSS attack.
Unless there is some other vulnerability in your site (or the user's system), there is no way for a third party to modify cookies.
Therefore you can treat them exactly the same as you would any other data that comes from the client (except that you don't need to worry about cookie data being faked with a CSRF attack). That is to say: Trust the cookie as much as you trust the user.
Cookies are not secure. Forget protecting them.
You should protect your server by having all communication on HTTPS. HTTPS protects your cookies more than anything else (it cannot protect against Session Hijacking though).
Do not store any sensitive information in the cookie other than the session id.
Make sure your cookies are configured as HTTP ONLY. If not, the session id will be sent as a part of the query string and can be intercepted (and cached) by any one.
Regenerate your session id on major events like user login, password change, etc.
Is there anyway to access the data associated with a cookie such as path, flags, and expiration date from javascript? All I've been able to find for cookie access is document.cookie, which only provides a list of name value pairs. Why is the interface for cookie access so limited?
No, there is none, in terms of safe, cross-browser support.
Reasoning comes down to security.
The goal of cookies was to allow for communication back and forth from the browser to the server.
If you could allow any front-end script to manually edit the domain / path / expiration of a cookie, just for knowing its name, it would lead to a lot of potential security-holes, if not for spoofing access, then at least for invisibly tracking people.
That's not to say that cookies are inherently safe, or even particularly safe at all.
I mean to say that by allowing any and all JS to edit any and all cookie data sent to the server (moreso than just CRUD), any pretence of security would disappear in a heartbeat.