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.
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.
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?
We have a ColdFusion developer who claims that solely by adding a few lines of code in the Application.cfm file of an application that he wants to be encrypted that he can force the IIS Web server to encrypt all communications involving that application. So for example, let's assume this developer's ColdFusion application resides at www.ThisIsIt.com/xyz/. He includes a conditional statement in his Application.cfm file (see below) to force a Web browser to preface the URL to his application with https.
<CFIF not cgi.server_port_secure>
<CFLOCATION URL="https://#cgi.server_name##cgi.script_name#" ADDTOKEN="no"/>
</CFIF>
Meanwhile within Internet Information Services (IIS) Manager, the xyz directory is NOT set to require SSL. If you visit https://www.ThisIsIt.com/xyz/, it will in fact be prefaced by https, but how can the content of his application as well as the communication between server and client Web browser be encrypted if the IIS Web server is not instructed/configured to encrypt the xyz directory, and why does the Web browser indicate an encrypted communication? Is this a mere trick or a legitimate means to encrypt a ColdFusion application?
The application-based rule works by detecting that SSL is not being used and redirects the user to the secure HTTPS domain. A valid SSL certificate is required to be configured otherwise a security message is displayed.
This method only forces HTTPS access for ColdFusion scripts. Static, non-CFML files like CSS, JS, PDF (that don't care about the presence of the application.cfm script) can be accessed directly without any HTTPS redirect.
The best way to "force" SSL for all web requests using IIS is with a web.config rule.
https://stackoverflow.com/a/29089228/693068
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 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.