I have noticed that there is a vulnerability which comes up in results of many penetration tests: “The application doesn’t user secure cookie flag”.
Penetration testers generally mark this vulnerability as “Severity Low” but it doesn’t mean that you should ignore it. It has an important role for protecting your data. The best part of it is that it is very easy to fix it!
First things first, what is secure cookie flag?
What is secure cookie flag?
When cookies are sent in clear text as part of HTTP requests, unauthorized parties can access to their content by intercepting the request (also called as man-in-the-middle attack).
Accessing to a cookie’s content may result in unauthorized access to users’ personal information and other sensitive data such as authentication tokens that are used to login web applications.
Secure cookie flag is basically a parameter that forces applications to use secure cookies so that browser and web server transfer cookies only through secure (HTTPS) connection. Therefore, unauthorized parties cannot see the cookie content. Microsoft recommends configuring web applications to force using secure cookies.
Having a problem with ASP.NET session IDs? Check this post out.
How to fix it?
In order to force an ASP.NET application to enable using secure cookies, add the following line into the section of the web.config file:
If you are using Forms Authentication, make sure to include “requireSSL” attribute in section. For example:
In order to confirm the secure flag in a cookie, use an intercepting proxy such as F12 Developer Tools in browser or a third-party tool such as Fiddler. Check the response headers to see if the “secure” word is there.
As you see in the screenshot below, “test” cookie is “secure”. Therefore, it will show up only in HTTPS connections.
IBM’s Cognos Business Intelligence software relies on IIS for front-end publishing and authentication. If you are prompted to enter your credentials to access Cognos website or administrator console, it means Windows Authentication is failing for IBM Cognos. Here is what to do in this case.
One of the ways to host Cognos BI is to use IIS. By configuring Windows Authentication in IIS, you can allow users to access Cognos without typing any credentials. This SSO (Single Sign-on) access requires certain steps to be followed as explained here and here.
If any of the settings are missing, you may come across an annoying prompt to enter your credentials. It quickly becomes cumbersome to enter your information every time you access to Cognos website.
Are you receiving Secure Channel (schannel) errors? Check these posts out.
Steps to follow when Windows Authentication is failing for IBM Cognos
Make sure that you review the steps in the IBM documentation to configure IIS (Links are above). In addition to the instructions, there are a few more things to check to solve this issue.
A common solution to this issue is that adding website’s domain name into the Intranet Zone of Internet Explorer as pointed out in a Microsoft support document:
Internet Explorer must consider the requested URL to be on the intranet (local). If the computer name portion of the requested URL contains periods (such as http://www.microsoft.com and http://10.0.0.1), Internet Explorer assumes that the requested address exists on the Internet and does not pass any credentials automatically.
Windows Authentication is performed by using either NTLM or Kerberos (preferred). Kerberos relies on SPNs (Service Principal Names) to operate. If there are no SPNs or there are duplicate SPNs for your domain, this might be the reason why Windows Authentication is failing for IBM Cognos. as explained in this article.
Follow the steps below to find and remove duplicate SPNs:
Check current SPNs
Run this at Command Prompt: setspn -F -q /cognosdev If it doesn’t bring any records or if it brings duplicate records, Kerberos authentication may not work with Cognos. In this case, continue with the following steps. Otherwise, do not perform the steps below.
For example: The command may bring a result like the one below. There are duplicate records (in bold) which should be fixed.
As mentioned in this blog post, responseMode=”ExecuteURL” executes the URL in the custom error configuration sends the response to the user Therefore, IIS logs 200 instead of 404 status code. However, responseMode="Redirect” send 302 response with the custom error page URL to the user. User’s browser makes another request to the given URL.
responseMode=”ExecuteURL” – path is treated as URL to execute. Response returned by executing the URL is returned to client as response. On successful child execute, client will see a 200 response. Child request will enter the pipeline in the same worker process. If this request is supposed to be executed by some other application pool, IIS core will generate 403.14. When child execute produce some other error, that error code along with child execute response is returned. – If path starts with “http://”, exact URL specified by path is executed. Hostname has to be current hostname. Else server will produce 404. – When path starts with “/”, it is assumed as URL for the current site and do a child execute on that. – If path doesn’t start with “/” or “http://”, server will produce 404 when trying to execute the URL.
responseMode=”Redirect” – Custom error module blindly uses the path as location header value and send a 302 response. If path is set to “/otherpath/otherpage.htm”, this will be used as the destination and most browsers send this request back to the same host. If you set path to www.iis.net, browsers do the right thing and send the new request to www.iis.net instead. – IIS doesn’t handle application relative paths both for “Redirect” and “ExecuteURL” as handled by Asp.Net (e.g. ~/error/404.htm).
As a generic solution, adding the line below into the custom error page should solve the issue. Make sure to change the file extension to aspx (For example: 404.aspx).
<% Response.StatusCode = 404; %>
Multiple identical logs in Advanced Logging
Logging two events instead of one is by-design for Advanced Logging extension. Advanced Logging extension subscribes to GENERAL_REQUEST_START event in the pipeline. Whenever this event is called, a new log is recorded.
Check your Failed Request Tracing (FREB) logs. If oyu see that there are child requests, It is expected from Advanced Logging to log more than one records for the same request (More about child requests).
On the other hand, IIS logs works differently. They are based on HTTP.sys kernel driver which creates notifications only when a response is submitted. Therefore, there is one record per request in IIS logs.
Starting with IIS 8.5, Advanced Logging module is no longer available. It was integrated in the logging infrastructure of IIS server. So that this issue won’t happen in IIS 8.5 and newer versions. If you are using IIS 8.0 or a lower version, it is recommended to upgrade it.