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.
Related
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.
We are implementing CA Site minder on external server for single sign on.
We did all necessary configuration on our server as well as on policy server.
When I hit my URL request get interrupted by ISAPI Filter and Site Minder Replace it with Log in Page Then I put credentials and click log in.
This request goes to policy server and after authenticating site minder redirect me to original url that I hit early on but somehow i am not getting SMSESSION Cookie.
I check FRT log and found that cookie is there in Request Header which mean site minder able to generate and pass the cookie to request but not set in Response header So its getting removed from response.
I tried to find why its getting removed or response not setting SMSESSION Cookie but not able to find any reason.
I am using Integrated pipeline mode and the same setup is working fine with classic mode but since my application is MVC I can't use that and i have to use integrated mode.
The SMSESSION cookie is not provided to the application from SiteMinder. It is initialized in the client browser after login and should be included when the authenticated request arrives back at your application.
I suggest monitoring the client side to ensure the SMSESSION is received after login and sent back out in the application request.
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.
We are using the Sharepoint.OpenDocuments.EditDocument2 ActiveX control and method.
The method is being called from JavaScript in an IE6 client on a Windows XP SP3 client (fully patched).
The server is running IIS6 on Windows Server 2003 SP1
Fronting the IIS server is Tivoli Access Manager (TAM) which proxies access to the web applications sitting behind it. Similar to forms authentication, it creates a session cookie for authentication purposes, that must be present for the HTTP request to reach the IIS server.
In front of TAM is an F5/BigIP load balancer and SSL encryption offloader, which enforces that incoming requests use the HTTPS protocol.
What is happening is that HTTP requests issued by this control do not contain any session cookies that were present in the browser. It drops the ASP.NET session cookie, the ASP.NET forms authentication cookie and the TAM cookie
Because the TAM cookie is missing the request is redirected to the TAM login page, which then shows up via HTML conversion in Word or Excel.
The API documentation at http://msdn.microsoft.com/en-us/library/ms440037.aspx mentions nothing about security or appropriate usage scenarios for this control.
Should these controls work in an ASP.Net Forms Authentication scenario or are they only supported with Windows Authentication. If Forms Authentication is supposed to function, how do we get the control to include the necessary session cookies in its requests?
The answer as provided by Microsoft Support.
This control merely forwards the URL of the document being retrieved to the appropriate office application.
The office application attempts to negotiate authentication with Sharepoint Server (full version). If no Sharepoint, the Office application does a simple get on the URL.
Ultimately, this means that this control does not support authentication scenarios that rely on session cookies.