I have a static website on an Azure web server/portal that holds our company's documentation. Recently, I've been making changes to our code that sets our cookies to ensure that they comply with the browser SameSite requirement as explained here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite
I've been able to fix all my scripts that create my cookies, but while testing them today, I see that there's this cookie message that still appears in my FireFox console:
Cookie “ARRAffinity” 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
This message only appears when I clear the cache from the site and load the page. Once I reload the page a second time or load any other page after that, I no longer see the message.
I believe this ARRAffinity cookie technically comes from Azure's Application Insights (AI)--or something on the Azure web server. It doesn't appear in our javascript files at all. We use AI for our analytics. Here is the code snippet that we got from Azure about two years ago. It gets injected into the header of each .htm page on our site:
var appInsights=window.appInsights||function(a){
function b(a){c[a]=function(){var b=arguments;c.queue.push(function(){c[a].apply(c,b)})}}var c={config:a},d=document,e=window;setTimeout(function(){var b=d.createElement("script");b.src=a.url||"https://az416426.vo.msecnd.net/scripts/a/ai.0.js",d.getElementsByTagName("script")[0].parentNode.appendChild(b)});try{c.cookie=d.cookie}catch(a){}c.queue=[];for(var f=["Event","Exception","Metric","PageView","Trace","Dependency"];f.length;)b("track"+f.pop());if(b("setAuthenticatedUserContext"),b("clearAuthenticatedUserContext"),b("startTrackEvent"),b("stopTrackEvent"),b("startTrackPage"),b("stopTrackPage"),b("flush"),!a.disableExceptionTracking){f="onerror",b("_"+f);var g=e[f];e[f]=function(a,b,d,e,h){var i=g&&g(a,b,d,e,h);return!0!==i&&c["_"+f](a,b,d,e,h),i}}return c
}({
instrumentationKey:"<The Key>"
});
window.appInsights=appInsights,appInsights.queue&&0===appInsights.queue.length&&appInsights.trackPageView();
(Note that <The Key> in the snippet above is actually a unique multi-character string that Azure gave us when we set up and configured the AI resource. I removed it here for privacy.)
I've since revisited the site where I got that code, but the snippet has changed to something newer:
https://learn.microsoft.com/en-us/azure/azure-monitor/app/javascript#snippet-based-setup
I'm not sure if I need to do anything to fix this.
Does ARRAffinity cookie come from some server-side script that Microsoft creates?
Do I need to do anything on my side to resolve this console message? If so, what?
ARRAffinity cookie is automatically created by Azure. You can turn it off by going to Configuration --> General Settings and then click on Off in the App Service as shown below.
As your's is a static website, i don't think this would be an issue. In fact, it is recommenced to turn ARR Affinity to Off for any Cloud Native applications.
When ARR Affinity is turned off, all the App Service instances (in a load balanced env) will be used effectively.
If ARR Affinity is turned on, all the requests for a given session will be sent to the same server irrespective of the load on it.
By default, the setting is on to to support legacy applications that needs Session stickiness.
Related
We are using AWS Amplify for our NextJS web app and keep receiving error when ever I try to load the application once deployed to Amplify. Locally there is no issue.
I am using Amplify's default Auth configuration, with basic email and password auth. It looks like it could be related to the Amplify cookie being set in the header but I cannot find any documentation within AWS to prevent this or reduce the amount of information passed with the header. Any help would be appreciated.
I have faced the same issue and was able to solve it. Here's how -
Identify the CloudFront Distribution ID for your app. You can find it in the Deploy logs of your app build console.
Search & open that particular CF Distribution and go to the Behaviours tab.
Select the Default behaviour (5th one in my case) and hit Edit.
Scroll down to the Cache key and origin requests section.
Here you will find settings to control what's included in the headers of the request that goes to the server. In my case, I didn't need any Cookies so I chose None, and it solved the issue for me.
In your case, you can do the same or pick what all info needs to be in the headers.
Check to see if there are any unnecessary cookies for that domain.
I was getting this error (on a site I don't own). I took a look at the request headers and found a very large number of cookies (several dozen) for the site's domain. I cleaned up the cookies which seemed non-critical and the error went away.
As the error implies, the size of the entire request header section is above 8192 bytes. Request headers include the accept headers, the user agent, the cookies, etc. and all combined can get rather large. Large headers look malicious to some WAFs. I once had a single user having trouble with our site. Turns out they were a polyglot and had configured their browser to accept several dozen languages causing their accept-language header to be suspiciously long, and the WAF refused to proxy the request.
I faced the same issue using Nextjs, amplify and an external Auth provider.
The problem is that AWS S3 service has a request header maximum allowed size of 8192 bytes, so when ever you try to access the static generated pages of Nextjs it returns that error. This has already been asked here
In my case, I was using an external Auth provider and I was able to solve the issue configuring the cookies only for the '/api/' path. That way the Auth cookies are sent only to the Nextjs api endpoints, so your request header is lighter whenever you try to get the static pages.
I have two Spring Web applications that work together. I'm running the first application from the IDE on localhost, while the second one is running in docker on app.127.0.0.1.nip.io.
The two applications interact indirectly through the users browser by redirecting and POSTing between the two apps. This is slightly similar to how an SP and an IdP work together in SAML2.
In my case, the first application on localhost is sending a 302 to the second application. After doing some work, the second application sends an HTML page with a form an JS code to autosubmit it, back to my first application on localhost. The HTML looks similar to this:
<form method=POST action="http://localhost:8080/some/path">
...
</form>
My first application is using Spring Session with a session cookie, and this works just fine. However, when the second application makes the browser POST the form, the browser does not send the session cookie with the POST request.
When both applications are running in docker under .127.0.0.1.nip.io, the cookie is sent.
I've tried to find any hint if this behaviour is expected, and what headers or other bits the applications could use to influence this.
At this point, this is mostly an annoyance while debugging, but I'm concerned that once the two applications will run on different FQDNs and/or different domains, the browsers will also block the cookie being sent.
I've tested this with current versions of Chrome and Firefox.
The problem is the new(ish) SameSite cookie policy that covers exactly this case: another application is POSTing to a host via HTTP. The default now is SameSite: lax, which does not allow sending the first-party cookie values on this request.
The solution is to allow the session cookie to be sent by specifying SameSite: none. Be aware however that this might create security vulnerabilities. For my application, this is not an issue, so I can allow the cookie to always be sent, and especially when I run my application in the debugger.
For the production deployment, I will be able to tighten this, since both applications will run under the same domain (a.example.com and b.example.com), and both will use TLS, so I can set the session cookie to SameSite: lax.
Here's a decent explanation: https://web.dev/samesite-cookies-explained/
I've been using Postman in my app development for some time and never had any issues. I typically use it with Google Chrome while I debug my ASP.NET API code.
About a month or so ago, I started having problems where Postman doesn't seem to send the cookie my site issued.
Through Fiddler, I inspect the call I'm making to my API and see that Postman is NOT sending the cookie issued by my API app. It's sending other cookies but not the one it is supposed to send -- see below:
Under "Cookies", I do see the cookie I issue i.e. .AspNetCore.mysite_cookie -- see below:
Any idea why this might be happening?
P.S. I think this issue started after I made some changes to my code to name my cookie. My API app uses social authentication and I decided to name both cookies i.e. the one I receive from Facebook/Google/LinkedIn once the user is authenticated and the one I issue to authenticated users. I call the cookie I get from social sites social_auth_cookie and the one I issue is named mysite_cookie. I think this has something to do with this issue I'm having.
The cookie in question cannot legally be sent over an HTTP connection because its secure attribute is set.
For some reason, mysite_cookie has its secure attribute set differently from social_auth_cookie, either because you are setting it in code...
var cookie = new HttpCookie("mysite_cookie", cookieValue);
cookie.Secure = true;
...or because the service is configured to automatically set it, e.g. with something like this in web.config:
<httpCookies httpOnlyCookies="true" requireSSL="true"/>
The flag could also potentially set by a network device (e.g. an SSL offloading appliance) in a production environment. But that's not very likely in your dev environment.
I suggest you try to same code base but over an https connection. If you are working on code that affects authentication mechanisms, you really really ought to set up your development environment with SSL anyway, or else you are going to miss a lot of bugs, and you won't be able to perform any meaningful pen testing or app scanning for potential threats.
You don't need to worry about cookies if you have them on your browser.
You can use your browser cookies by installing Postman Interceptor extension (left side of "In Sync" button).
I have been running into this issue recently with ASP.NET core 2.0. ASP.NET Core 1.1 however seems to be working just fine and the cookies are getting set in Postman
From what you have describe it seems like Postman is not picking up the cookie you want, because it doesn't recognize the name of the cookie or it is still pointing to use the old cookie.
Things you can try:
Undo all the name change and see if it works( just to get to the root of issue)
Rename one cookie and see if it still works, then proceed with other.
I hope by debugging in this way it will take you to the root cause of the issue.
I am having a problem implementing Microsoft's latest Identity 2.0 in my ASP.net 4.5 Web Forms project. This is my scenario...
I have downloaded the latest Webforms.Samples code from https://aspnet.codeplex.com/SourceControl/latest and pretty much performed a straight port (for the purposes of testing) into my project.
In development, the code/implementation works correctly, when we move to our IIS 7.5 staging server, after a period of time (usually 3 or 4 hours, but varies) the test users experience the following problem...
When they login, the login process appears to run correctly and redirects them back to the specified return url, but the authorisation is not complete/recognised and they get immediately returned back to the login page.
I should say that the login page/process doesn't fail (no errors) and the underlying code return 'success' (as this is the only path that will invoke the redirect), but the actual mechanism appears to be passive. To prove this, I have created a test page that simply echoes the user's identity and even immediately after an apparently successful login, the user identity is anonymous.
The only way I have found of fixing the issue is to restart the web application and again it runs fun for a while.
Can anyone give me any pointers on where I can look to begin to debug this issue or what the cause might be?
Thanks.
ASP.NET_SessionId + OWIN Cookies do not send to browser This page seems to provide a workaround to the issue by creating a session on application start up.
Starting with this great analysis by #TomasDolezal, I had a look at both the Owin and the System.Web source.
The problem is that System.Web has its own master source of cookie information and that isn't the Set-Cookie header. Owin only knows about the Set-Cookie header. A workaround is to make sure that any cookies set by Owin are also set in the HttpContext.Current.Response.Cookies collection.
The workaround I created is now outdated: I've made a small middleware
(source, nuget) that does exactly that, which is intended to be placed immediately above the cookie middleware registration.
Use Microsoft's suggestion of a SystemWebCookieManager instead.
I have a web app that is being hit by facebook. The login page retrieves the keys that I need and sets some session variables. When the server then redirects the user to the next page, the session information is lost. I’m running the IIS engine on vista ultimate at the moment, the app pools don’t matter because I’m using a state service and I’m still losing the session state. I’ve tried both the overloaded method of the response.redirect function and also adding a header to the page to force the redirect and none of this seems to work. Does anyone have any ideas of what I’m missing?
I’ve tried both of these:
Response.Headers.Add("refresh", "3;url=Dashboard.aspx")
And
Response.Redirect("Dashboard.aspx", False)
[EDIT]
So i just did a little experiment and well it turns out that when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
[EDIT]
So I found an article on this and after addin gthe header the problem was solved (for now)
http://support.microsoft.com/kb/323752
Response.AddHeader("P3P: CP", "CAO PSA OUR")
when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
If you're in an iframe, any cookies you set are “third-party cookies”. Third-party cookies may be subject to more stringent conditions than the normal “first-party” cookies you are setting when the user is directly on your site. This can be due to different browser default cookie handling or because the user has deliberately configured it like that. (And for good reason: many third-parties are unpleasant privacy-invading advertisers.)
In particular, in IE6+ with the default settings, you cannot set a third-party cookie unless you write a P3P policy promising that you will be a good boy and not flog your users' data to the nearest identify thief.
(In practice of course P3P is a dead loss, since there's nothing stopping the site owner from just lying. Another worthless complication that provides no actual security. Yay.)
I'd try running Fiddler and see if your session cookie is being sent properly with the response when interacting with your app via Facebook.
The session depends also on cookie support by the client. When you say the app "is being hit by facebook" are you sure that by what ever means they are "hitting" you they are supporting cookies?
Response.Redirect and refresh don't carry session. Server.Transfer() can but loses the ability to transfer to other servers/sites.