We have an AngularJS application which has several cookies which need to be set to secure and httponly, however we have one cookie which cannot be httponly as it tracks the progress of a download from the application. All of the information I've found on IIS seems to show how to use rewrite to unilaterally set all cookies to httponly and secure.
Is it possible to exclude cookies from the rewrite rule or are there alternative methods so that individual cookies can have httponly set or not in IIS?
Related
My applications consists of 2 parts:
The web API, written in .NET Core
The web app, written in React and rendered using a nodejs express server
I am hosting these parts on azure, each on it's own sub domain so we have:
api.azurewebsites.net
app.azurewebsites.net
When the user logs in I set a cookie, to my understanding a cookie can be used accross sub domains. The cookie is set the following way:
Response.Cookies.Append("token", "token value", new CookieOptions
{
Expires = DateTimeOffset.Now.AddDays(7),
SameSite = SameSiteMode.None,
Domain = "azurewebsites.net"
});
But the cookie is not sent along with requests to either sub domain. How can this be?
If this is the wrong approach how do I authenticate with a SSR app and a rest api? When the app gets rendered in node it fetches data the exact same way as in the browser using isomorphic-fetch, the cookie is passed along with it.
All this works flawlessly on localhost, the problem starts when the app in on a different sub domain from the api.
UPDATE:
The cookie header looks like this:
Set-Cookie: token=<token>; expires=Sat, 22 Jun 2019 05:35:18 GMT; domain=azurewebsites.net; path=/; secure
On firefox it works different from chrome. On chrome i do the authentication api request, get the token get the cookie header and then the cookie does not get sent along any subsequent requests.
In firefox the cookie does get sent with subsequent requests, however upon refreshing the page the cookie is gone.
I found this ASP.NET Core Sharing Identity Cookie across azure web apps on default domain (*.azurewebsites.net)
Cross sub domain cookies are blocked for the azurewebsites.net domain for security reasons.
I am using express-session module for maintain session. i have two app. i want to share cookies with this apps, parent app run in example.com , and child app run in child.example.com. i set httponly cookie using express-session it sets in the child app.i can verified that cookie in resource tab in chrome debugger.
Network tab:
When the first call to sub-domain:
it load like "http://www.child.example.com" cookie set in the request. while the url is redirect to server IP . cookie not available after that.
like http://13.25.230.2/index cookie not avaliable on that
When you send the Set-Cookie HTTP header, you can specify the domain it is for.
Set-Cookie: name=value; domain=example.com
The domain must be a suffix of the domain hosting the page.
i.e. foo.example.com, bar.baz.example.com and www.example.com can all share a cookie belonging to example.com.
A URL using an IP address has no hostname in it at all and cannot match that rule.
There is no way to share your cookie between example.com and 13.25.230.2. Give the site a hostname instead.
There is no way you can set cookie using setcookie header from one host to another. For example from example.com to foobar.com.
If you have to do it. Then do it by passing the cookie value to server side script for example foobar.com\set-my-cookie.php and use to to save the cookie.
Httponly cookies cannot be set or read from client side code.
Bluemix generates a VCAP_ID cookie which is not secure at the moment (see below). Is there a way I can force it to be secure? Is there any reason for not making it secure?
Set-Cookie:VCAP_ID=[redacted]; Path=/; HttpOnly
vs.
Set-Cookie:VCAP_ID=[redacted]; Path=/; HttpOnly; Secure
No, this is set internally by Bluemix. We can take this back to the dev team to make the cookie secure though.
What is __VCAP_ID_ cookie
Here's what I found from section HTTP Sessions Not Persisted or Replicated of cloudfoundry document:
Cloud Foundry supports session affinity or sticky sessions for incoming HTTP requests to applications if a jsessionid cookie is used. If multiple instances of an application are running on Cloud Foundry, all requests from a given client will be routed to the same application instance. This allows application containers and frameworks to store session data specific to each user session.
And this sticky session is tracked via a cookie named __VCAP_ID_, see cloudfoundry/gorouter/proxy/proxy.go
Setup __VCAP_ID_ cookie
checkout cloudfoundry/gorouter/proxy/setupStickySession()
The configuration for setting this cookie is a private method which means it's decided internally within proxy. The only variable part are maxAge and Path which means it uses maxAge/Path of JSESSIONID cookie for __VCAP_ID_ cookie.
I'm curious why Secure is not part of this. Instead, it is decided when creating proxy in gorouter. I've create issue 99 to track this because it should be as secure as JSESSIONID.
Say you only want to send cookies over HTTPS to the client - not over HTTP. You could use the HTTP secure flags as mentioned in this article. However, since you can use the Apache mod_rewrite module to send a redirect to the user from the HTTP version of your site to the HTTPS version, shouldn't that mean that it will secure the cookies? In other words, does the server send your cookies if its sending out a redirect?
If you are redirecting from HTTP to HTTPS and then set cookies, these cookies will be set over HTTPS. Say you redirect the user from http://www.example.com to https://www.example.com, the Set-Cookie header sent from www.example.com to the user will be encrypted during transport.
However, if the user comes back and enters http://www.example.com in their browser, if the Secure Flag was not set on the cookie, the cookie will be sent over HTTP, unencrypted.
This can also happen if any internal links on your site are HTTP, any links on other sites to yours are HTTP or if a MITM attacker injects a HTTP resource from your site on another site (e.g. <img src="http://www.example.com/x.jpg" /> will leak the cookie over HTTP).
This is why it is advisable to set the secure flag. HSTS can be used to help ensure connections remain on HTTPS only, however setting the secure flag should be the primary focus.
I have a client who runs his Classic ASP site under IIS 6.0. The web site is targeted for ASP.NET 2.0 in the ASP.NET configuration tab. A recent PCI Scan of his site is failing him with an HttpOnly vulnerability on his ASPSESSIONID cookie.
I have installed an ISAPI .dll that successfully sets HttpOnly on all manually created cookies, but ASPSESSIONID cookie is not effected by this for some reason.
I have set web.config with the following configuration:
<system.web>
<httpCookies httpOnlyCookies="true" />
</system.web>
This configuration seems to have no effect whatsoever, on anything. I suspect, even though the web site is targeted for ASP.NET 2.0 it is afterall a Classic ASP application and HttpOnly wasn't supported at all.
The client's web site uses a global.asa instead of global.asax. This rules out using Application_EndRequest to add HttpOnly.
I can load up the client's site using Firefox/Firebug and see the cookies. Those manually created are getting HttpOnly set, but the ASPSESSIONID cookie is not HttpOnly.
Is anyone aware of how to cause the ASPSESSIONID cookie to be HttpOnly given this setup scenario?
The ASP Session Cookie can not be modified by Classic ASP code, so for IIS 6 you would need to have ISAPI module rewrite the cookies.
Setting HTTPONLY for Classic Asp Session Cookie
http://msdn.microsoft.com/en-us/library/ms972826
Client side JavaScript workaround
http://ko-lwin.blogspot.com/2010/12/how-to-secure-classic-asp-session-id.html
Request.ServerVariables("HTTP_COOKIE") will get the current cookie value, which you can then respond with the updated cookie, adding HttpOnly but only issue is if you are trying to pass a security scan, they often don't take the updated value for the cookie, only the initial.