None of my cookies have a SameSite attribute set. I have just noticed that Firefox DevTools console shows the following warning for my website:
Cookie “PHPSESSID” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite
It also displays exactly the same warning message for my first party cookies (such as that I use to store a shopping basket) as well as for all the Google gtag cookies. I have checked and both Safari and Chrome show no warning. If I didn't happen to use Firefox for development I would never have known!
The link provided to the Mozilla website provides no timeframe for when such cookies may be rejected by the browser and confusingly states that cookies without a SameSite attribute will be treated as Lax (which would be fine).
So my question really is can I ignore this warning as it seems somewhat erroneous or must I take steps to set a SameSite attribute for all cookies including session cookies which is a bit of a hassle!
Thanks.
To answer my own question, in case this is of help to anyone I decided to be on the safe side I wouldn't ignore the Firefox warning and implemented the following code in htaccess:
<ifmodule mod_headers.c>
Header always edit Set-Cookie ^(.*)$ $1;SameSite=Lax
</ifmodule>
This sets SameSite to Lax for all my first party cookies including the PHP session cookie.
I didn't set Secure and SameSite to None as I don't require this and anyway it apparently has some support issues on older browsers.
Related
A cookie has been set with the SameSite=Strict attribute. When Javascript tries to read the cookie before making an XHR request the cookie seem to be unavailable. But the developer tools show the cookie exists. This problem is happening only in the recent version of Firefox. Not sure if I am missing anything. The domain and the path are set right on the cookie.
Apparently, it depends on how you get to the page that performs the XHR request. If you get there by clicking on a link on another website (say, following a link on your webmail client), the Strict cookies will not be available, even in subsequent XHR requests! This behaviour seems to be different in Firefox than in other browsers.
Some more info you may find here: https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/
I still don't know why, I think it about the firefox behavior, I fixed by using location.replace("") to reload page, but you can also use "lax" or "none" to fix that.
Is it possible to change the HTTP_REFERER value in VBScript? To avoid XSS attacks I am using CSRF data in my links. But when I am linking the user to an external website, this CSRF data could be caught by the destination webpage if they are checking the HTTP_REFERER.
So I read you should put an intermediate page in between, which will redirect to the desired page. So I tried creating a page named RedirectPage.asp which takes the URL as a parameter and does a Server.Redirect. But if I would click an external link on pagex.asp?CSRF..., the final HTTP_REFERER I catch is still pagex.asp.
So is there a way to "clean up" my REFERER header?
Thanks!!
By using a meta redirect instead of a redirect header, you can alter the referrer in Firefox and IE, but not Chrome, as mentioned here: https://stackoverflow.com/a/2985629/160565
You can consistently clear (not change, but eliminate) the http_referer by redirecting through an SSL page however.
To save yourself a redirect, you could also check for browsers that support the rel="noreferrer" html5 attribute and use that instead in those cases. I believe currently that's just webkit browsers.
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer
I have a problem with saving session data with IE9. When users login the session is saved correctly. Now, if they browse through the application, the application stores the pagehistory into the session data (I use this for the applications back button). Unfortunately IE9 does not always save this data into the session (sometimes it does and sometimes it does not). It works perfectly with other browsers.
If you are using PHP, try adding a header like:
//vfranchi - necessary to IE8, so it won't throw a warning
header('P3P:CP="This site does not contain a P3P policy."');
I think this is related to IE8 not saving cookie information when the site doesn't have a explicit privacy policy. I had the same problem and that fixed for me.
Remember this statement needs to be before any output just like session_start()
Solved it by switching off IE8 compatibility mode.
I'm using jQuery's ajax .get method to retrieve data from my server. Works perfect in Chrome, but in IE9 it is not sending the Cookie header and that breaks the app. Any idea why? Here's the jQuery code:
$.get(this.server + 'rest/photo/' + this.profileId + '/count', function(data) {
$('#imageCount').html(data);
});
I have the same problem here, I can't get the jQuery .ajax() function to work. The only workaround I found is this:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />
You can add this meta tag to the top of the page to get it working. But it doesn't feel like a good solution. I think the problem is that the xmlhttprequest object in IE9 is different, so jQuery cannot find the respective object, therefore ajax is not triggering.
I ran into a similar issue to the OP many years later with IE9 which, sadly, is still hanging on.
Every browser I tried, including IE10+, seemed fine with passing cookies to my backend, but IE9 would just drop them. It didn't seem to matter what attributes were on the cookies. The main page and API were on the same domains and the cookies matched, the schemes were the same. I wasn't doing anything with IFRAMES, so the P3P 'potato' hack didn't help.
So I started doing some research on what it was about IE9 that could be different. This Microsoft post was very enlightening, and outlines all the things the IE8 and IE9 did to help lock down CORS security holes:
Must use HTTP(S), and both endpoints must use the same scheme
Must use GET/POST
No custom headers allowed
Only text/plain content-type allowed
More sensitive to Security Zone settings
Cookies will be stripped from the request
That last item about the cookies got me thinking, what if IE9 thought I was making a cross-site request? It certainly looked like it was getting shot down in fine fashion like that. I had already checked some of the obvious things like the scheme and domain, but maybe I didn't check everything.
The solution? Specifically, I was using reqwest as my ajax library. It has a cross-origin parameter, which I had left set to true for some reason. Setting it (correctly) to false did the trick - all my cookies were picked up by the server. So it was a dumb mistake, but I learned a thing or two.
Hope this helps someone!
I've been tinkering with URL Rewriting on my site and fixing the canonicalization of my URLs (so I don't have duplicate data on search engines, etc.) and it was recommended everywhere to either always remove/force the trailing slash (I chose to remove it) and also to redirect /index to . So I put the following two rules in my .htaccess for Apache's mod_rewrite to pick up:
--remove trailing slash
RewriteRule ^(.+)/$ http://%{HTTP_HOST}/$1 [R=301,L]
--remove trailing /index
RewriteRule ^(.*)/?index$ http://%{HTTP_HOST}/$1 [R=301,L]
These rules work just fine in the browser. But some of my ajax forms stopped functioning all of a sudden! I traced it both in Chrome and Firefox(Firebug) and what happens is very strange. In both browsers, the page does an ajax call to:
<mydomain>/ajax/index (ajax params intact) --> 301 redirect to <mydomain>/ajax/
<mydomain>/ajax/ (ajax params are no longer sent!) --> 301 redirect to <mydomain>/ajax
<mydomain>/ajax (ajax params again not sent) --> 200 OK but obviously script complains that params don't exist
Can anyone confirm that this is the case or am I losing it? If so, why the heck does it behave like this? And is there a proper solution for fixing it (other than changing all my ajax calls to never get redirected eg <mydomain>/ajax )?
Thank you very much for you time guys :)
Cheers
Ali
The HTTP specification says that a browser should resend the parameters along with the redirected request for a 301 redirect. On the other hand, it also says that the browser should manually confirm with the user that it's OK to resend those parameters each time the request is redirected. That kind of defeats the point of AJAX, if the user gets two dialog boxes popping up every time he/she submits your form. So for that reason, if nothing else, I'd recommend setting up your server-side scripts so that there will be no redirects on AJAX calls.
In reality, browsers tend to ignore the part of the specification that tells them how to handle a redirect on a form submission. So you're probably not crazy; it seems perfectly believable that the behavior you're seeing is built into the browsers intentionally (or maybe because someone was too lazy to code it the right way).