If I have a site (e.g. foo.com) and on the home page of foo.com, there is an image request where the src=bar.com..., will the cookies on the bar.com domain be sent to the bar.com servers?
Yes. HTTP doesn't distinguish between one kind of resource or another (image vs html).
The cookie will typically be included in any type of request, but the scenario you describe is what's known as a third-party cookie (that is, the cookie is set on a domain that is different than the domain of the loaded page) and most browsers offer a privacy setting to block third-party cookies.
A third-party cookie allows the owners of bar.com to place an image (say a banner ad) on foo.com and track the users of foo.com even though those users have never visited bar.com. This is a privacy concern and many users elect to block such cookies.
This question is old, but was the first result on Google for me, so I think it's worth clarifying how this works nowadays (2021).
When bar.com sets the cookie, they can specify a SameSite attribute.
If the cookie is set with SameSite=Lax (or the SameSite attribute is not specified), then the cookie will not be sent for requests for images/iframes/etc hosted on bar.com, but will be sent if the user clicks a link on your foo.com homepage that takes them to bar.com
If the cookie is set with SameSite=Strict, the cookie will not be included in requests to bar.com that originate from another webiste, including if the user clicks a bar.com link on foo.com.
If the cookie is set with SameSite=None, the cookie will be sent to bar.com, including requests for images.
If third-party-cookies are not blocked by the user then most modern browsers will set or send cookies of the third party domain when a request is made to the third party web site. IE 6 has a different kind of blocking mechanism called leashing. wiki: A leashed cookie is a third-party cookie that is sent by the browser only when accessing a third-party document via the same first-party.
Yes cookies are sent on all requests.
This includes "img" and "script" as well as XMLHttpRquest calls from javascript and can be a security issue on script tags as scripts loaded by one website can load scripts from another site and will send their authentication cookies too. This can be exploited to steal data.
Yes, aspx/js/css/image requestion need the cookie verification.
Related
I have a single-page static app hosted at example.com. My server for the app is hosted at server.com. I keep these two services completely separate and they can scale differently this way. When the user wants to login their username and password is passed to yoyoma.com and a cookie is set on server.com with the access_token. The user is then redirected to example.com and is now logged in.
From the static app at example.com, we can now make AJAX requests to server.com setting withCredentials=true so that the access_token we set is passed along to server.com. This works perfectly in every browser but Safari. The only way I've gotten Safari to work is by going to preferences -> privacy -> disabling "Prevent cross-site tracking". I know that the cookies are getting set on server.com, but they don't get passed with the AJAX request. It seems to be some Privacy feature that Apple thinks is just wonderful, but how are you supposed to get around this issue. I'm not an ad service, I'm not doing anything evil, just trying to get my app to work. I specifically want to build a single page app where the server is on a different domain. Is this possible in Safari or has their privacy setting made this impossible?
Note: I should also mention to security fanatics that when the access_token cookie is set, the user is then redirected to example.com with a CSRF token. This csrf token is passed in every AJAX request by a header to prevent Cross Site Request Forgery.
Assuming you're set on keeping different domains - which is not at all unreasonable there are some ways to tackle it, but they come with compromises
1
Have example.com redirect to a server rendered server.com/login for creating the httpOnly cookie and then redirect them back to their logged in state in your SPA.
As I understand it, when Prevent cross-site tracking is enabled in Safari, the intention is to have the user interact with the other domain before cookies are allowed to be sent.
By redirecting them, that intent has been created and you should have no issue setting a cookie and have it be sent by example.com.
However it does come it its own set of limitations
Read more
2
Look into the discussion related to StorageAccess as the idea here is to work with third party auth solutions that rely on cookies from different domains. Safari ITP has sorta made those harder to use, so the idea is to work with vendors for a better solution than LocalStorage.
3
Store your key in LocalStorage, and vet all running javascript code coming from you and make sure to follow best practices when it comes to dealing with user created values.
LocalStorage exposes your to potential XSS, but Cookies expose you to CSRF attacks. You have to mitigate those and it's not too hard, but keep in mind you introduced those vectors when cookies were used.
Any XSS that happens is game over, even with httpOnly cookies. Forget your auth key, running the attackers code can do so much more damage.
Keylogger to take username/password
If the attack happens after an authed state, they could pop up a modal asking re-auth.
Submit a request to change email and then ask for password reset
Don't get me wrong, it's easier to dump LocalStorage as a generic attack versus the attacks listed above
That being said, in the end the resources you spend on dealing with cookie issues, could be better spent hardening down your javascript running on the users browsers to ensure they aren't running malicious code
You can't protect them from extensions though, and a httpOnly cookie would at the very least ensure that their keys aren't leaked. Know your compromises.
Edit: Keep in mind that whatever approach you're taking, any further reliance on browser needs to think through the different versions of browsers out in the wild. As an example, don't assume using httpOnly cookies and setting a sameSite policy negates the need for a CSRF token. Any addition of cookies might s till need a CSRF token as a header as of today unless it's a controlled environment.
Personal Opinion held loosely.
Do no harm. Cookies add "harm"/work that you have to mitigate.
Cookies might protect attacks leaking access tokens but why would an attacker care about the access token when they can run any code they wish?
LocalStorage weakness is XSS, but Cookies does not protect against that.
What prevents them from just taking the password?
Popping up a login modal to an unexpected user that won't think twice, hell Github does that from time to time for good reasons, it's not unheard of.
Background: I have a javaee webapp deployed on tomcat which uses form based authentication. When the web server receives a login request, it sends the request to a dedicated authentication service which validates user login (User id and password). After successful authentication user's session is maintained in the web server.
Problem: I have written a simple webpp source code here, to simulate the scenario. On successful login the current HttpSession instance is invalidated and new instance is created. For each request for a post login page, the session is validated. A new JSESSIONID cookie is set which is used to identify the user during the session until session is expired or user logs out. This cookie can easily viewed in browser's dev tools. If I copy the cookie and set this in a different browser via JavaScript (document.cookie="JSESSIONID=xyzz") and then try to access a post login page, the server identifies it as a valid request and session is validated successfully. The post login page is served without user being challenged for user Id and password.
POC: User opens chrome and enter the URL http://localhost:8080/mywebapp/ and logs in with admin and pass1234. On successful log in the home page http://localhost:8080/mywebapp/home is shown. Now the JSESSIONID cookie is copied and set in FireFox. User enters http://localhost:8080/mywebapp/home in Firefox and is shown the home page without being challenged for userId and password.
Question: How can this be prevented wherein same session is getting replicated over multiple browsers?
You can't prevent this specific case of simply copying the cookie from your own browser (or by copying the cookie value from a HTTP payload copypaste/screenshot posted by an ignorant somewhere on the Internet). You can at most prevent the cookie getting hijacked by XSS or man-in-middle attacks.
This all is elaborated in Wikipedia page on the subject Session Hijacking of which I snipped away irrelevant parts (either already enforced by Servlet API, or are simply not applicable here).
Prevention
Methods to prevent session hijacking include:
Encryption of the data traffic passed between the parties by using SSL/TLS; in particular the session key (though ideally all traffic for the entire session[11]). This technique is widely relied-upon by web-based banks and other e-commerce services, because it completely prevents sniffing-style attacks. However, it could still be possible to perform some other kind of session hijack. In response, scientists from the Radboud University Nijmegen proposed in 2013 a way to prevent session hijacking by correlating the application session with the SSL/TLS credentials[12]
(snip, not relevant)
(snip, not relevant)
Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users whose IP address is liable to change during a browsing session.
Alternatively, some services will change the value of the cookie with each and every request. This dramatically reduces the window in which an attacker can operate and makes it easy to identify whether an attack has taken place, but can cause other technical problems (for example, two legitimate, closely timed requests from the same client can lead to a token check error on the server).
(snip, not relevant)
In other words:
Use HTTPS instead of HTTP to prevent man-in-middle attacks.
Add a checkbox "Lock my IP" to login form and reject requests from different IP associated with same session in a servlet filter. This only works on users who know themselves they have a fixed IP.
Change session cookie on every request. Interesting at first sight, but breaks when user has same website open in multiple browser tabs/windows in same "session".
Not mentioned, but make sure you don't have a XSS hole anywhere, else it's very easy stealing cookies.
Last but not least, I'd like to make clear that this problem is absolutely not specifically related to Servlet API and the JSESSIONID cookie. All other stateful server side languages/frameworks such as PHP (PHPSESSID) and ASP (ASPSESSIONID) also expose exactly the same security problem. The JSESSIONID was previously (decade ago orso) only a bit more in news because by default it was possible to pass the session identifier along in the URL (which was done to support HTTP session in clients who have cookies disabled). Trouble started when ignorant endusers copypasted the full URL with JSESSIONID inside to share links with others. Since Servlet 3.0 you can turn off JSESSIONID in URLs by enforcing a cookie-only policy.
<session-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
See also:
How do servlets work? Instantiation, sessions, shared variables and multithreading
How to prevent adding jsessionid at the end of redirected url
remove jsessionid in url rewrite in spring mvc
What you have stated is called session hijacking. There are many good answers on how to prevent it.
Using same Jsession ID to login into other machine
we can use Encryption or hide JSESSIONID using Browser control.
Thanks
I have recently been reading about session ID's and how websites track users.
I was wondering how session ID's are safe inside cookies. Couldn't a website read another website's cookies and get your session ID?
Cookies are stored on the client's browser with cookie name, value and the expiry. But multiple websites may have cookie with same name so cookies are grouped with respect to domains. See the Firefox's cookies screenshot bellow.
Suppose sites A and B have cookies with name ABC. Browser will provide the cookie data for site A from site A only.
We have an implementation understanding with a merchant to create our domain cookies when user is on his site. Now in FF assuming that third party cookies acceptance is set we are able to create the cookies and flow works fine. But the issue is that after the cookie is created and third party cookie is disabled later - the request to load an image from merchant site page to ours site - we do not receive the cookie details.
Is it an expected behavior or we need some special mechanism to get the cookie?
Please help.
You may already know this but cookies are domain based. You can only access cookies on requests for the same domain.
If your image is displayed on sample.com and your the url of the image is sample.com/img.jpg then when the request is made for the image the cookies will be sent along with the request.
On the other hand if the image is displayed on sample.com and the image url is yoursite.com/img.jpg then you won't receive the cookies for sample.com.
Also, dev.sample.com and sample.com are different domain names.
Hopefully this helps clarify why you can't receive cookies. This behavior is mainly security related to prevent websites from sniffing cookies from other sites.
Setup: Grails 1.1, Acegi/Spring Security plug-in
I want users to log in over SSL, so I have '/login/**' in my channelConfig.secure[] list, but almost everything else is in channelConfig.insecure[]. Every request for /login gets redirected to https:// and every other request is redirected to http://.
My problem is that the login process sets the cookie to "Send over encrypted connections only," so when the login page redirects to /home, the home page doesn't see the cookie and redirects me back to the landing page. When I try to log in again, the login page sees the cookie and redirects me...etc.
I hunted through this page about SecurityConfig to see if there is an option to allow cookies created over SSL to be read over unencrypted HTTP, but I found nothing. Is there some option I can set to make my login cookie available to my unencrypted controllers?
This would be a vulnerability.
Any man-in-the-middle that can see the session cookie would be able to make requests as the user. This is almost as bad as the password being intercepted. The man-in-the-middle wouldn't be able to establish new sessions on his own, but he would be able to do anything the user can do once a user logs in.
Using SSL does a lot more than simply hiding the user name and password at login.
First, it provides confidentiality for all messages between the client and server. It's easy to recognize the password as sensitive data, but it might not be as obvious which application features use sensitive data as well. Protecting any user input and dynamically generated content is safer and easier than trying to carefully evaluate the privacy issues of each data field used in your application. Static content such as images, help pages, etc., probably isn't as sensitive, but by analyzing requests for that content, an attacker might get a good idea of what a user is doing on the site.
Second, SSL provides integrity for every request. This prevents an attacker from modifying or appending their own nefarious input to user requests, or modifying the results produced by the server.