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)
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 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.
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.
When building a widget that is designed to be embedded on 3rd party websites, there appear to be two schools of thought as to how to do it:
Use iframes
Use the main page's DOM
When using the iframe method, cross domain requests are not a problem, as the server thinks that the request originates from its own page.
When using the main page's DOM, cross domain requests are an issue, and the server needs to respond with the appropriate CORS headers for it work.
Which of these two methods is more secure, and what security issues should be taken into account in implementing each of these methods?
You might find this post interesting - How to protect widgets from forged requests:
You don't want this [widget] to be vulnerable to CSRF so you write an iframe to the page. Based on the origin inheritance rules the parent site won't be able to read the CSRF token. However what about clickjacking (or likejacking )? Because of CSRF you must be within an iframe and there for the x-frame-options cannot help, and the same holds true for frame-busters
Negatives of IFrame approach
Vulnerable to Clickjacking / Likejacking
Negatives of DOM approach
Vulnerable to CSRF.
CORS headers on your server will be allowing access to either the whole world, or whole sites that are pre-registered with you. While this doesn't in itself present a vulnerability, care must be taken to make sure no sensitive information is made available (such as user data). There is no way to limit access to your widget only - you would be giving access to the whole Origin (i.e. protocol, domain and port).
As you are manipulating the DOM these objects would be accessible from the remainder of the page outside of your widget.
Summary
In the end it depends on the functionality of your widget. What is the consequence of the parent site automatically submitting the form or clicking a button on your widget under the context of the user? If there is a like or +1 button, the hosting page could be fraudulently promoting their site by making the like/+1 be registered with you without the user's knowledge or consent. This would apply to both approaches, only the attack method would differ (i.e. CSRF or Clickjacking).
The accepted answer on the above post has a solution for CSRF vs Clickjacking:
Clicking on the widget needs to open a pop-up window containing a new page -- an iframe is not good enough, it must be a new window -- which is entirely under the control of your web application. Confirm the action, whatever it is, on that page.
Yes, this is somewhat inelegant, but the present Web security architecture doesn't give you any better options.
In summary, the IFrame approach appears to have overall more security and implementing the popup window upon interaction mitigates the Clickjacking risk.
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.