Let's say I have a website at http://domain.org on which I also have Google Analytics (GA) and Mixpanel (MP) Javascript tracking codes. Both MP and GA store cookies on the user's browser for my entire domain including sub domains (.domain.org).
Because of this every time I do a request to any URL in this entire domain, the cookies for GA and MP are sent along.
New Relic on the other hand store their cookie on the bam.nr-data.net domain.
Why do GA and MP do this? Only in a situation of strange backend hackings one would use the values in these cookies on the backend.
Google Analytics uses first party cookies (by injecting the javascript code that's setting the cookie into the web site source) because 3rd party cookies are often blocked (in many browsers they are blocked by default).
Since they are set under your domain name they are sent to your server. That's pretty much a side effect of the original intent (which is to make the tracking more reliable), your are not supposed to use them in your backend.
When setting up Google Analytics you can use the cookie domain parameter to limit ga cookies to a specific part of your domain/subdomain. You cannot, to the best of my knowledge, make GA use a third party cookie.
On a related note, if your goal is to avoid sending the cookie data with each request, you can tell Google Analytics to use localStorage (instead of cookies) to store the client ID.
Here's a thread on the HTML5Boilerplate repo discussing implementation and the pros and cons of such an approach.
The TL;DR is if you don't have to support IE7 and older, and if you're not tracking across multiple sub-domains, you can use localStorage with no problems.
Related
I have a small LTI application that integrates with canvas, and after the LTI launch I can't access the cookie. This is failing in Safari (always) and Chrome (sometimes).
I am forcing the SameSite=LAX field of the cookie.
I'm not sure what else I should try.
There have been numerous changes in Chrome (and other browsers) regarding cookies and iframe.. For LTI 1.3 launches this is extra difficult because of how you need to track the state of the launch in the cookie while processing the OIDC flow.
The basics of what is changing is there is now a 'SameSite' cookie policy, where Only cookies set as SameSite=None; Secure will be available in third-party contexts, provided they are being accessed from secure connections. So marking the cookies as Secure and HTTP-Only is a must in addition to the SameSite=None
Also in Safari, the third-party frame will have to request access to the storage API before the cookie will be accessible.
Firefox is using a partitioned approach to the storage, and so the frame will behave as normal unless you then open your application as a new window then the cookie store may or may not follow depending on how the new window was created.
Cookie Status is an excellent resource to track how third party cookies work in the different browsers and what you should change to make it work.
I occasionally receive warnings from PHPIDS about certain cookies, and on further examination, it appears that a particular client keeps sending me cookies that I did not set, e.g. mp_d21cb8a9f34838c02aeec897b3728a94_mixpanel.
How is that possible? It was my understanding that cookies are only sent back to the server/domain that set it, and I do not use mixpanel and to my knowledge did not set that cookie.
I understand that mixpanel is a web tracking tool, but I do not use it (I use Google Analytics). I have no other users on my server/domain, I have no affiliate ads/banners on my site, and I do not support user generated content. So I am fairly certain that my server did not set that cookie, but then why does the client browser (IE11) keep sending me that cookie? The user's behavior seems legitimate, i.e. it appears to be no bot or script.
Do I have a fundamental misunderstanding how cookies work? Can some other server set cookies for MY domain? Any ideas how this comes about? Are there known browser bugs that mixes up cookies?
Regards,
Arno
I created a Google site page with 5 links on it. Is it possible to create on my site a script or something that stores in a cookie the link on which the user has clicked, and then the next time he will connect to the page, he will be automatically redirected to the link he clicked on ? For information, the user connect to the site with his Google email account.
How can I do that please?
Thank you very much in advance for your help
While it is possible to read cookies and redirect using JavaScript inside a Google Page (using widgets), browsers will not allow you to set cookies for a completely different domain for obvious security reasons.
Related:
How to set a cookie for another domain
Cross-Domain Cookies
What's your favorite cross domain cookie sharing approach?
You could theoretically try and send an AJAX request from the Google Page with a "where should I direct this user to?" and expect a URL or a null.
See:
CORS $.ajax session cookies (access-control-allow-credentials & withCredentials=true)
Cross domain POST request is not sending cookie Ajax Jquery
But overall, your task is not as straightforward as it may seem. The browser will, fortunately, not play along.
I am testing an application that requires a user to authenticate, and then uses a cookie to track the user session. If authentication fails, a cookie is set that identifies the session as belonging to an unidentified user.
Unfortunately, authentication is via Kerberos or NTLM, which cannot be done in JMeter 2.8. My plan is therefore as follows:
Log into website with Internet Explorer.
Copy cookie that identifies session out of IE and into JMeter cookie manager as a user-defined cookie.
Use JMeter to test application
Essentially, this is session hijacking.
What I am observing is that (1) the JMeter cookie manager does not seem to be supplying the cookie to the application in the first request, (2) after the first request the application sends a different cookie back to JMeter, and (3) subsequent requests use the application-defined cookie, not the one I supplied.
So my questions are:
Is the approach described plausible, in theory at least?
Do application-defined cookies always override user-defined cookies?
Why might the cookie manager be not sending my user-defined cookie?
Thanks in advance.
Try using JMeter nightly build, it has been reported recently that it worked with NTLM after upgrade of httpclient libraries.
http://jmeter.apache.org/nightly.html
You approach seems really weird to me and I don't think it will work or even if it does be realistic.
I consider myself newbie when it comes to securing my web applications.
I have built a website which updates the webpages regularly through an AJAX call. The Ajax call returns a decent JSON object to be used at the client side.
There is a simple problem I need to overcome: How can I prevent other people to use the same AJAX call without permission? What if they build a website, AND at the client side they allow their users to make the same AJAX call to my servers and grab what they need.. AND THEN parse it to their own needs at the client side?
I cannot put an extra layer of security like user authentication.
They won't be able to actually do this from the client directly because the browser will prevent cross domain AJAX requests for anything other than JSONP (scripts). That said, they can proxy it on their server if they want so it doesn't buy you much.
ASP.NET MVC has an antiforgery token mechanism that you should look at for inspiration. The basic idea is that you use both an encrypted cookie and an encrypted, hidden form input containing the same data that you write to each page that you want to secure. Do your AJAX calls using a POST and make sure to send back the form input. On the server-side decrypt the cookie and input and compare the data to ensure they're the same. Since the cookie is tied to your domain, it will be much harder to inject in the request that is being sent back. Use SSL and regenerate the cookie/input content periodically to make it even harder to fake the cookie/input.
You can check the HTTP_REFERER http header and see if the request originates from your page. This can however be spoofed, so don't think of it as a bulletproof solution. The best counter-meassure is user authentication, really.
You can't. That's because you can't differenciate between an AJAX call from your web app and another user's webapp.
Here are some things that might help a little bit.
Obscuring/encrypting your AJAX response. This fails mainly because you have to include the decryption code in your app as well.
Check the IP origin. If the IP didn't access your server before, you can assume that the AJAX call is not from your website. This doesn't work if a) the user switches the IP while being on your site / timing out or b) if another website sends a fake http request first before using your AJAX API.
Another idea would be to send Javascript instead of a JSON object. The Javascript should contain all the logic needed to update your website, and of course could check if the website is your own. (window.location). That has some disadvantages though: more work for you, higher traffic load and it can be broken anyways.
I don't think it's a bad thing actually. Another website could have just as easily scraped the info from your website.
If by "stealing" you mean getting some content from your website (using HTTP GET), that's more or less the same problem as hot-linking. You could have some basic protection technique using the HTTP Referer header (it can be worked around, but it works in most cases).
The other problem you have (making sure the requests come from your application) have to do with CSRF (Cross-Site Request Forgery). There are various protection mechanisms against this, mostly based on embedding tokens in forms for example.
You could potentially combine the two approaches, although the real protection against getting the content would come from user authentication (otherwise, the other site could also get the page from which you're delivering those tokens and proxy it).
(In addition, techniques that rely on remembering the IP address would probably not work well in the whole web architecture: it might cause problems if you get a pool of proxy servers or if the client is a mobile device that may change IP address between various requests, which would be perfectly legitimate.)