Secure cookie flag

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:

<httpCookies requireSSL="true"/>

If you are using Forms Authentication, make sure to include “requireSSL” attribute in section. For example:

<system.web>
    <authentication mode="Forms">
        <forms requireSSL="true">
            <!-- forms content -->
        </forms>
    </authentication>
</system.web>

Confirm the fix

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.

Secure cookie flag is displayed
Cookie is secured

As you see in the screenshot below, “test” cookie is “secure”. Therefore, it will show up only in HTTPS connections.

References

Windows Authentication is failing for IBM Cognos (Solved)

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.

Windows Authentication is failing for IBM Cognos
Windows Authentication prompt

Background

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.

Solution 1

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.

Internet Explorer May Prompt You for a Password

Solution 2

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:

  1. 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.

    Checking forest DC=MyDomain,DC=com
    CN=MyDomainUser,CN=Users,DC=MyDomain,DC=com
    HTTP/MyReportServer
    HTTP/MyReportServer.MyDomain.com
    CN=MYREPORTSERVER,CN=Computers,DC=MyDomain,DC=com
    WSMAN/MyReportServer
    WSMAN/MyReportServer.MyDomain.com
    TERMSRV/MYREPORTSERVER
    TERMSRV/MyReportServer.MyDomain.com
    RestrictedKrbHost/MYREPORTSERVER
    HOST/MYREPORTSERVER
    RestrictedKrbHost/MYREPORTSERVER.MyDomain.com
    HOST/MYREPORTSERVER.MyDomain.com
    Existing SPN found!

  2. Remove duplicate SPNs (if there are any)

    Run the commands below to remove duplicate SPNs in the example above.

    setspn -d http/MyReportServer.MyDomain.com MyDomainUser
    setspn -d http/MyReportServer MyDomainUser

  3. Add new SPNs (if needed)

    Run the following commands to get the Service Principal Name added to the Web Application Pool Account:

    Setspn -f -s http/cognosdev.domain.com domain\cognosadmin
    Setspn -f -s http/cognosdev domain\cognosadmin


    Add this line to the Windows Authentication tag in the applicationHost.config file (under System.WebServer heading): 

    useAppPoolCredentials=”true”

    Save the file and run iisreset

References

IIS is logging 200 instead of 404 status code

When you try to access a web page that doesn’t exist, browser shows 404 HTTP status code. However, you may see 200 instead of 404 status code in IIS logs. 

Here is the line from my IIS logs. This is actually a failed request that displayed “404 Page not Found” error to the user.

2018-11-27 17:32:28 ::1 GET /app1/kkrr1 – 80 – ::1 Mozilla/5.0+(Windows+NT+10.0;+WOW64;+Trident/7.0;+Touch;+rv:11.0)+like+Gecko – 200 0 0 0

Looking for a way to determine user browsers from IIS logs? Check this post out.

What to do if you see 200 instead of 404 status code

The root cause -in my case- is the custom error configuration in the web.config file. I have the configuration below that redirects users to a custom page when there is a 404 error.

<httpErrors existingResponse="Replace" defaultResponseMode="Redirect" errorMode="Custom">
     <remove statusCode="404"/>
     <error statusCode="404" responseMode="ExecuteURL" path="/index1.htm"/>          
</httpErrors>

Once I changed ExecuteURL to Redirect in the responseMode attribute, IIS started logging 404 errors.

<httpErrors existingResponse="Replace" defaultResponseMode="Redirect" errorMode="Custom">
     <remove statusCode="404"/>
     <error statusCode="404" responseMode="Redirect" path="/index1.htm"/>          
</httpErrors>

IIS log that shows the correct status code (404) after the change:

2018-11-27 17:33:25 ::1 GET /app1/oopp – 80 – ::1 Mozilla/5.0+(Windows+NT+10.0;+WOW64;+Trident/7.0;+Touch;+rv:11.0)+like+Gecko – 404 0 2 46

200 instead of 404
Incorrect (first line) and correct (second line) status codes

Background

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).

Source

Still having the issue?

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.

References