Git Product home page Git Product logo

owaspheaders.core's Introduction

OwaspHeaders.Core

A collection of ASP.NET Core middleware classes designed to increase web application security by adopting the recommended OWASP settings.

Build Status Release Status License used Changelog Code of Conduct
Build status Release License: MIT changelog Code of Conduct.md

Please note: this middleware DOES NOT SUPPORT BLAZOR OR WEBASSEMBLY APPLICATIONS. This is because setting up secure HTTP headers in a WebAssembly context is a non-trivial task.

Tools Required to Build This Repo

  • .NET SDKs vLatest
    • 6.0
    • 7.0
    • 8.0*
  • an IDE (VS Code, Rider, or Visual Studio)
  • dotnet-format global tool.

That's it.

* = at the time of pushing version 8 of the repo (Dec 2nd, 2023), the .NET 8 SDK binaries are not available for some Linux distributions (such as Fedora). If v8.0 of .NET is not available for your chosen distro, remove the net8.0 TFM from all csproj files in order to build and run the code.

Pull Requests

PRs Welcome

Pull requests are welcome, but please take a moment to read the Code of Conduct before submitting them or commenting on any work in this repo.

Also please make sure to run dotnet format OwaspHeaders.Core.sln in the root of the repo before submitting a PR. This repo uses an editorconfig file to enforce certain formatting rules on this repo. Any PRs which don't adhere to these formatting rules will fail a PR action (for checking the code against the rules). So to save time, please run dotnet format OwaspHeaders.Core.sln ahead of submitting your PR.

Getting Started

Assuming that you have an ASP .NET Core project, add the NuGet package:

dotnet add package OwaspHeaders.Core

Alter the Startup (pre .NET 6) or program (post .NET 6) class to include the following:

app.UseSecureHeadersMiddleware();

This will add a number of default HTTP headers to all responses from your server component.

The following is an example of the response headers from version 6.0.2 (taken on May 15th, 2023)

cache-control: max-age=31536000, private
strict-transport-security: max-age=63072000;includeSubDomains
x-frame-options: DENY
x-xss-protection: 0
x-content-type-options: nosniff
content-security-policy: script-src 'self';object-src 'self';block-all-mixed-content;upgrade-insecure-requests;
x-permitted-cross-domain-policies: none;
referrer-policy: no-referrer

Please note: The above example contains only the headers added by the Middleware.

Secure Headers

The SecureHeadersMiddleware is used to inject the HTTP headers recommended by the OWASP Secure Headers project into all responses generated by the ASP.NET Core pipeline.

Listing and commenting on the default values that this middleware provides is out of scope for this readme. Please note that you will need to read through the above link to the Secure Headers Project in order to understand what these headers do, and the affect their presence will have on your applications when running in a web browser.

Configuration

This Middleware uses the builder pattern to set up the header information, which is a compile time dependency.

In your Startup class (or Program.cs for .NET 6 onwards):

app.UseSecureHeadersMiddleware(RealisticContentSecurityPolicyGenerators.GenerateOwaspHomePageCsp());

This will use the default configuration for the OwaspHeaders.Core middleware. The method (found in /src/Extensions/SecureHeadersMiddlewareExtensions.cs) looks like this:

public static SecureHeadersMiddlewareConfiguration BuildDefaultConfiguration()
{
return SecureHeadersMiddlewareBuilder
.CreateBuilder()
.UseHsts()
.UseXFrameOptions()
.UseContentTypeOptions()
.UseContentDefaultSecurityPolicy()
.UsePermittedCrossDomainPolicies()
.UseReferrerPolicy()
.UseCacheControl()
.RemovePoweredByHeader()
.UseXssProtection()
.UseCrossOriginResourcePolicy()
.Build();
}

Custom Configuration

In order to use a custom configuration, follow the same pattern (perhaps creating your own extension method to encapsulate it):

public static SecureHeadersMiddlewareConfiguration CustomConfiguration()
{
    return SecureHeadersMiddlewareBuilder
        .CreateBuilder()
        .UseHsts(1200, false)
        .UseContentDefaultSecurityPolicy()
        .UsePermittedCrossDomainPolicy
            (XPermittedCrossDomainOptionValue.masterOnly)
        .UseReferrerPolicy(ReferrerPolicyOptions.sameOrigin)
        .Build();
}

Then consume it in the following manner:

app.UseSecureHeadersMiddleware(
    CustomSecureHeaderExtensions.CustomConfiguration()
);

Testing the Middleware

An example ASP .NET Core application - with the middleware installed - is provided as part of this repo (see the code in the OwaspHeaders.Core.Example directory). As such, you can run this example application to see the middleware in use via a provided OpenAPI endpoint - located at /swagger.

Or you could add the middleware to an existing application and run through the following Run the application, request one of the pages that it serves and view the headers for the page.

This can be done in Google Chrome, using the Dev tools and checking the network tab.

secure headers shown in network tab

Shown above in the Response Headers section of the Values response.

Server Header: A Warning

The default configuration for this middleware removes the X-Powered-By header, as this can help malicious users to use targeted attacks for specific server infrastructure. However, since the Server header is added by the reverse proxy used when hosting an ASP .NET Core application, removing this header is out of scope for this middleware.

In order to remove this header, a web.config file is required, and the following should be added to it:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <security>
            <requestFiltering removeServerHeader="true" />
        </security>
    </system.webServer>
</configuration>

The above XML is taken from this answer on ServerFault.

The web.config file will need to be copied to the server when the application is deployed.

owaspheaders.core's People

Contributors

compufreak345 avatar gaprogman avatar jamie-taylor-rjj avatar michaelm2 avatar miguelcrpinto avatar mkokabi avatar rohitjha avatar spslaine avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

owaspheaders.core's Issues

Expect-CT is not implemented

Description

The OwaspHeaders.Core middleware does not yet include support for Expect-CT which is a header related to Certificate Transparency.

Description from MDN:

The Expect-CT header allows sites to opt in to reporting and/or enforcement of Certificate Transparency requirements, which prevents the use of misissued certificates for that site from going unnoticed. When a site enables the Expect-CT header, they are requesting that the browser check that any certificate for that site appears in public CT logs.

Source: Excpect-CT on MDN

Middleware should use OptionsBuilder

As good as the Builder Pattern is, it might be more explicit to consumers if the middleware uses the OptionsBuilder pattern.

This will greatly increase visibility of exactly which values are being set for the different headers.

[High Priority] Remove support for .NET Framework

10k ft View

This library was originally designed to be used by ASP .NET Core applications which use either .NET Framework or .NET Core. However, as of ASP .NET Core 3.0, .NET Framework is no longer supported. See this announcement for details.

This will also help to fix the transient vulnerability that the library has due to it using ASP .NET Core 2.2's Microsoft.AspNetCore.Http.Abstractions. Details on the vulnerabilities can be found here and here.

I explored the options for removing support for both ASP .NET Core on .NET Framework and ASP .NET Core 2.2 in the second half of this stream.

We'll also need a way to communicate to users that the new version of the library (version 8) will not longer be supported by ASP .NET Core on .NET Framework. But that's more of an infrastructure problem for me.

Feature-Policy header is not supported

Description

The OwaspHeaders.Core middleware does not yet include support for Feature-Policy which is a header related to enabling or disabling certain JavaScript API features.

Quote from Scott Helme's blog:

TheFeature Policy is being created to allow site owners to enable and disable certain web platform features on their own pages and those they embed. Being able to restrict the features your site can use is really nice but being able to restrict features that sites you embed can use is an even better protection to have.

Source: A new security header: Feature Policy

Links to Header Information

Support netstandard2.0

Hi there,

although you mention to support netstandard2.0 here the project is built against netcoreapp2.0, not netstandard2.0 - I had to make 2 small changes to make it work with my .Net Core-project built against the 4.6.1 framework. You can have a look at the changes here - should I commit a pull request? I didn't test it against a full netcoreapp2.0, but it should work.

Thanks & best regards,
Christoph

Cross-Origin-Opener-Policy not supported

10k ft View

The HTTP Cross-Origin-Opener-Policy (COOP) response header allows you to ensure a top-level document does not share a browsing context group with cross-origin documents.

COOP will process-isolate your document and potential attackers can't access your global object if they were to open it in a popup, preventing a set of cross-origin attacks dubbed XS-Leaks.

If a cross-origin document with COOP is opened in a new window, the opening document will not have a reference to it, and the window.opener property of the new window will be null. This allows you to have more control over references to a window than rel=noopener, which only affects outgoing navigations.

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Opener-Policy

OWASP recommended value (as of May 11th, 2023): Cross-Origin-Opener-Policy: same-origin

This value means that "Isolates the browsing context exclusively to same-origin documents. Cross-origin documents are not loaded in the same browsing context."

Resources

Does not implement Content-Security-Policy header

Repro

  1. Add SecureHeadersMiddleware to application
  2. Load page
  3. inspect HTTP Headers (in Chrome, open Networking tab in Developer Tools)

Expected Result

Headers contain the following (example)

 Content-Security-Policy: script-src 'self'

Actual Result

Headers does not contain the above

Expect-CT is deprecated, consider removing or disabling by default

10k ft View

The following comes directly from the OWASP Secure Headers Project (as of May 11th, 2023):

Deprecated.

⚠️ Warning: This header will likely become obsolete in June 2021. Since May 2018 new certificates are expected to support SCTs by default. Certificates before March 2018 were allowed to have a lifetime of 39 months, those will all be expired in June 2021.

source: https://owasp.org/www-project-secure-headers/#expect-ct

The MDN page for Expect-CT goes into this further:

Note: The Expect-CT is mostly obsolete since June 2021. Since May 2018, all new TLS certificates are expected to support SCTs by default. Certificates issued before March 2018 were allowed to have a lifetime of 39 months, so they had expired in June 2021. Chromium plans to deprecate Expect-CT header and to eventually remove it.

Rather than remove it, perhaps set its default value to disabled.

Custom Content Security Policies not being built correctly

When using a custom configuration to determine the Content Security Policy e.g.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    ...
    app.UseSecureHeadersMiddleware(CustomConfiguration());
    ...
}

private static SecureHeadersMiddlewareConfiguration CustomConfiguration()
{

    var safeScripts = new List<ContentSecurityPolicyElement>
    {
        ContentSecurityPolicyHelpers.CreateSelfDirective(),
        new ContentSecurityPolicyElement()
        {
            CommandType = CspCommandType.Uri, 
            DirectiveOrUri = "https://safeaddress.com/"
         }
    };

            var safeStyles = new List<ContentSecurityPolicyElement>
            {
                ContentSecurityPolicyHelpers.CreateSelfDirective(),
                new ContentSecurityPolicyElement()
                {
                    CommandType = CspCommandType.Uri,
                    DirectiveOrUri = "https://safeaddress.com/"
                },
                new ContentSecurityPolicyElement()
                {
                    CommandType = CspCommandType.Uri, 
                    DirectiveOrUri = "https://fonts.googleapis.com/"
                }
            };


            var safeFonts = new List<ContentSecurityPolicyElement>
            {
                ContentSecurityPolicyHelpers.CreateSelfDirective(),
                new ContentSecurityPolicyElement()
                {
                    CommandType = CspCommandType.Uri,
                    DirectiveOrUri = "https://fonts.googleapis.com/"
                }
            };

            return SecureHeadersMiddlewareBuilder
                .CreateBuilder()
                .UseHsts()
                .UseXFrameOptions()
                .UseXSSProtection()
                .UseContentTypeOptions()
                .UseContentSecurityPolicy(null, true, true, null, null)
                .SetCspUris(safeScripts, CspUriType.Script)
                .SetCspUris(safeStyles, CspUriType.Style)
                .SetCspUris(safeFonts, CspUriType.Font)
                .UsePermittedCrossDomainPolicies()
                .UseReferrerPolicy()
                .Build();
        }

The Policy Elements that are marked as CspCommandType.Uri are being quoted as well being written as unquoted in the HEADER

e.g.

content-security-policy: script-src 'self' 'https://safeaddress.com/' https://safeaddress.com/;style-src 'self' 'https://safeaddress.com/' 'https://fonts.googleapis.com/' https://safeaddress.com/ https://fonts.googleapis.com/;font-src 'self' 'https://fonts.googleapis.com/' https://fonts.googleapis.com/;block-all-mixed-content; upgrade-insecure-requests;

I may be wrong but I understand the header should be returned with only the directives being quoted.

content-security-policy: script-src 'self' https://safeaddress.com/;style-src 'self' https://safeaddress.com/ https://fonts.googleapis.com/;font-src 'self'  https://fonts.googleapis.com/;block-all-mixed-content; upgrade-insecure-requests;

Remove dependency to Microsoft.AspNetCore.All

By adding a dependency to Microsoft.AspNetCore.All in version 3.3.0 you also implictly added a dependency to .NET Core 2.0. As a direct result you excluded projects targetting .NET Standard 2.0. This prevents us from upgrading to the latest version.

You should consider just adding the specific packages you require as a dependency instead of the ominous .All package. Most ASP.NET Core packages target .NET Standard, and not .NET Core.

Not compatible with .Net Core 2.1

Hello,

as 2.1 is the latest LTS version of .Net Core we are currently using this version and not .Net Core 2.2. Unfortunately the latest version of the nuget package references Microsoft.AspNetCore.Http.Abstractions in version 2.2.0 - this does cause version conflicts in .Net Core 2.1 that I am not able to resolve.

I don't know if it's possible to fix this by downgrading the minimal required version or if it's needed - but it'd be great if you could check ;)

Thanks & best regards,
Christoph

X-Powered-By header is included by default

Description

The X-Powered-By header is still exposed in server generated responses. OwaspHeaders.Core should have the ability to remove this, if included in the SecureHeadersMiddlewareConfig.

This may require re-writing how the headers are added in the Invoke method to enable removal of headers.

This can be implemented by doing something like:

context.Response.Headers.Remove("HeaderName");

Upgrade to .NET Core 2.0

With the release of .NET Core 2.0 (and all of the related libraries and features) it is required that OwaspHeaders.Core is upgraded to .NET Core 2.0 (and by extension .NET Standard 2.0 compatible).

There is already a branch for this, and all development work should happen in that branch before being merged into Master.

Attention should be paid to ensure that the AppVeyor build and releases do not break.

Allow configuration for X-Content-Security-Policy

This is an issue to discuss the Pull Request I am to file soon.

There are different sources about if it is a good idea to add the X-Content-Security-Policy-header.

https://content-security-policy.com/ says Note: It is known that having both Content-Security-Policy and X-Content-Security-Policy or X-Webkit-CSP causes unexpected behaviours on certain versions of browsers. Please avoid using deprecated X-* headers.

I did not find out what this "unexpected behaviour" is and sources like stackexchange or stackoverflow tell that this header is the only way to make Internet Explorer a bit more secure, although not all properties work.

Well-respected products like IdentityServer also set this header in their Quickstart-Guide, to the same value as the normal Content-Security-Policy header.

In my understanding it does not hurt to set it to the same value and by adding "sandbox" and optionally "allow-scripts" "allow-forms" it should help with IE. I did not find a good source about "allow-same-origin".

I am currently working on adding an optional config.UseXContentSecurityPolicy - property (set to false by default) that will just put the content of the Content-Security-Policy-Header to the X-Content-Security-Policy-Header as well. Also on the TODO is to test that I can add "sandbox allow-scripts allow-same-origin allow-forms" to this header.

I am not quite sure if this is the right route to go, so if anyone has any better ideas feel free to add those here.

Pull request will come soon.

"Feature" request: a changelog

Hi,

Could you add a changelog.md file to explain features/fixes for each new version?

I've seen that the NuGet package has been updated (several times) about 6 days ago, yet I do not see any description (other than the commits themselves) explaining what those versions contain and if any breaking changes, security fixes, etc have been introduced.

Also, the GitHub release page contains only one version while the NuGet contains about 20. Any reason for that discrepancy?

Thanks!

Does not implement X-Content-Type-Options header

Repro

  1. Add SecureHeadersMiddleware to application
  2. Load page
  3. inspect HTTP Headers (in Chrome, open Networking tab in Developer Tools)

Expected Result

Headers contain the following

 X-Content-Type-Options: nosniff

Actual Result

Headers does not contain the above

X-XSS-Protection has been deprecated and can cause issues with modern browsers if present.

10k ft View

The following comes directly from the OWASP Secure Headers Project (as of May 11th, 2023):

Deprecated.

⚠️ Warning: The X-XSS-Protection header has been deprecated by modern browsers and its use can introduce additional security issues on the client side. As such, it is recommended to set the header as X-XSS-Protection: 0 in order to disable the XSS Auditor, and not allow it to take the default behavior of the browser handling the response. Please use Content-Security-Policy instead.

Source: https://owasp.org/www-project-secure-headers/#x-xss-protection

The MDN page for X-XSS-Protection goes into further detail:

Warning: Even though this feature can protect users of older web browsers that don't yet support CSP, in some cases, XSS protection can create XSS vulnerabilities in otherwise safe websites. See the section below for more information.

They also say this, perhaps add this to documentation:

Note:
Chrome has removed their XSS Auditor
Firefox has not, and will not implement X-XSS-Protection
Edge has retired their XSS filter
This means that if you do not need to support legacy browsers, it is recommended that you use Content-Security-Policy without allowing unsafe-inline scripts instead.

ReportUri in ExpectCt not optional / hard-coded in default config

Regarding to the spec the report uri directive is optional:

The OPTIONAL report-uri directive indicates the URI to which the UA SHOULD report Expect-CT failures (Section 2.4). The UA POSTs the reports to the given URI as described in Section 3.

The report-uri directive is REQUIRED to have a directive value, for which the syntax is defined in Figure 2.

Whereas in OwaspHeaders.Core it is required

if (string.IsNullOrWhiteSpace(reportUri))
        throw new ArgumentException("Must supply value of reportUri in SecureHeadersMiddleware");

To be able to use this header with the required report-uri in the default config there is a hard-coded reportUri.

.UseExpectCt("https://gaprogman.com/report", 86400, true)

I think the parameter should be optional and no URI should be hard-coded.

Thanks & best regards,
Christoph

Remove X-XSS-Protection header from defaults

Description

As the Chromium team have announced their plan to deprecate the XSSAuditor in Chrome, along with it having been removed from Edge in October, 2018, the X-XSS-Protection header should be removed from the default builder. However, since legacy browsers still support the header, it should still be possible to add the header via an extension method.

Notes for Implementers

Removing UseXSSProtection() from the BuildDefaultConfiguration extension method will get us part way to fixing this issue.

Domains are not used in CSP

Steps to Recreate

Add a CSP (assumes that #16 is fixed) which uses a domain rather than a command (i.e. www.gaprogman.com versus using 'self') and the reported CSP in the browser will be broken.

Cause

All values for CSP directives are added without the use of single quotes (i.e. ') - which are needed for all directive values which are not domains (i.e. 'self') but not for domains (i.e. www.gaprogman.com). This is done in the [BuildValuesForDirective](https://github.com/GaProgMan/OwaspHeaders.Core/blob/5f2ab0bdc7ef4e7d56e01397706193990bfdb181/src/Extensions/StringBuilderExtentions.cs) method

The uris are added to the [ContentSecurityPolicyConfiguration](https://github.com/GaProgMan/OwaspHeaders.Core/blob/5f2ab0bdc7ef4e7d56e01397706193990bfdb181/src/Models/ContentSecurityPolicyConfiguration.cs) as lists of strings. Replace this with a model which has an enum (csp command, domain name) and a uri/command as a string.

For example:

public enum CspCommandType
{
  CspCommand,
  Uri
}

In the [BuildValuesForDirective](https://github.com/GaProgMan/OwaspHeaders.Core/blob/5f2ab0bdc7ef4e7d56e01397706193990bfdb181/src/Extensions/StringBuilderExtentions.cs) method, separate the directive values by CspCommandType and add them using the following logic:

  • CspCommand should be wrapped in ' chars (i.e. 'self')
  • Uri should NOT be wrapped in ' chars (i.e. www,gaprogman.com)

Does not implement X-Permitted-Cross-Domain-Policies header

Repro

  1. Add SecureHeadersMiddleware to application
  2. Load page
  3. inspect HTTP Headers (in Chrome, open Networking tab in Developer Tools)

Expected Result

Headers contain the following (example)

 X-Permitted-Cross-Domain-Policies: none

Actual Result

Headers does not contain the above

Content Security Policy is not used

Steps to recreate

Use the Default Secure Headers Config builder, run a server with the middleware set up on it, put in a request to a page on the server and CSP is not used.

Thoughts/Ideas/Cause

Although the CSP is set up correctly, however in the UseContentDefaultSecurityPolicy method (and those which follow it in the layout of the file), does not set the value of config.UseContentSecurityPolicy

Unit tests disabled if something is wrong in setup

The unit tests don't actually run if there is an error in the setup phase or the parts executing this. I think the "if"-clauses in the tests should be assertions instead. I also found one test where this caused the test to not do anything at all as there was passed a HeaderPresentConfig in a HeaderNotPresent-Test:

[Fact]
        public async Task Invoke_ExpectCtHeaderName_HeaderIsNotPresent()
        {
            // arrange
            var headerPresentConfig = SecureHeadersMiddlewareBuilder.CreateBuilder()
                .UseExpectCt("https://test.com/report").Build();
            var secureHeadersMiddleware = new SecureHeadersMiddleware(_onNext, headerPresentConfig);

            // act
            await secureHeadersMiddleware.Invoke(_context);

            // assert
            if (!headerPresentConfig.UseExpectCt)
            {
                Assert.False(_context.Response.Headers.ContainsKey(Constants.ExpectCtHeaderName));
            }
        }

I did change all tests to assert instead of not run if they are set up wrong. PR is coming right after this issue.

blob:, *, data: are capsulated between quotes

font-src, style, img etc. has the possibility for blob: or data: or *. However when creating an ContenSecurityPolicyElement the value is always capsulated with quotes but this is not valid for browsers (like Chrome) which ignores the CSP rule.

image

image

I think it will be good when setting a value, you can exclude the quotes. I will make a pull request for this.

Edit: good to show my configuration:

new ContenSecurityPolicyElement { CommandType = CspCommandType.Directive, DirectiveOrUri = "blob:" };

Cross-Origin-Embedder-Policy not supported

10k ft View

The HTTP Cross-Origin-Embedder-Policy (COEP) response header configures embedding cross-origin resources into the document.

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy

OWASP recommended value (as of May 11th, 2023): Cross-Origin-Embedder-Policy: require-corp

This value means that "A document can only load resources from the same origin, or resources explicitly marked as loadable from another origin."

Resources

Cross-Origin-Resource-Policy not supported

10k ft View

The HTTP Cross-Origin-Resource-Policy response header conveys a desire that the browser blocks no-cors cross-origin/cross-site requests to the given resource.

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy

OWASP recommended value (as of May 11th, 2023): Cross-Origin-Resource-Policy: same-origin

This value means that "Only requests from the same Origin (i.e. scheme + host + port) can read the resource."

Resources

Re-write to use a Fluent Interface and Builder Pattern

Description

The current version of the project uses a config file (see secureHeaderSettings.json for an example). This could prove to be difficult for some users, as they would have to create the file and learn the schema.

Possible Solution

Move towards a Fluent Interface with Builder Pattern for building an instance of the middleware and inserting it into the pipeline.

Example:

app.UseSecureHeadersMiddleware()
    .WithHsts("any relevant config in here")
    .WithCsp("content security policy string here")
    .Build();

All arguments will be nullable, with defaults and XML documentation provided. Only the headers which have been dot supplied will be built, and an explicit call to Build() will be required as the final part of the middleare

In the above example, the only extra headers inserted would be HSTS and CSP.

Other Considerations

Consider renaming the extension method which includes the middleware. Something like:

  • app.UseOwaspHeaders()
  • app.OwaspHeadersConfig()
  • app.IncludeSecureHeaders()

SetCspUris with each of one CspCommandType.Directive and CspCommandType.Uri results in duplicate values in header

Example, Startup.cs:
.UseContentSecurityPolicy() .SetCspUris(new List<ContentSecurityPolicyElement>{ new ContentSecurityPolicyElement() { CommandType = CspCommandType.Directive, DirectiveOrUri = "self" }, new ContentSecurityPolicyElement() { CommandType = CspCommandType.Uri, DirectiveOrUri = "cdnjs.cloudflare.com" } }, CspUriType.Style)

In StringBuilderExtensions.BuildValuesForDirective, the second if statement (direvtiveValues.Any(), line 67) re-adds any Uri directives, so that cdnjs.cloudflare.com shows up twice in the policy. Probably don't need the two ifs (lines 48/67), and can just use the two wheres (lines 51/52 and 56/61)

Does not implement Referrer-Policy header

Repro

  1. Add SecureHeadersMiddleware to application
  2. Load page
  3. inspect HTTP Headers (in Chrome, open Networking tab in Developer Tools)

Expected Result

Headers contain the following (example)

 Referrer-Policy: no-referrer

Actual Result

Headers does not contain the above

Clear Site-Data is not implemented

Description

Clear Site-Data is a new header which can be used to tell the browser to wipe out cookies and tokens automatically when a user logs out. This can be useful in stopping Session Hijacking once a user has logged out.

Adding support for the Clear Site-Data header will require some form of controller attribute, perhaps. This is because we don't want Clear Site-Data to be included in every response from the server, only those responses which are generated by logging out.

This will require some thought and planning before implementation.

Links to Header Information

HPKP is being deprecated in Chrome and Firefox

As pointed out in this post on the Chromium support portal, HPKP is being deprecated in Chrome - with firefox likely to follow suit

This will first remove support for HTTP-based PKP (“dynamic pins”), in which the user-agent learns of pin-sets for hosts by HTTP headers. We would like to do this in Chrome 67, which is estimated to be released to Stable on 29 May 2018.

This means that, effectively, this header is deprecated and should be marked in the code as such. This particular header should only be enabled if the consumer sets up their configuration file to reflect it.

(i.e. do not instantiate and empty HPKP object and use that in the header injection code).

possibly requires to some thought and communication with other (more intelligent) people about how to handle this. A tweet has been sent (with OWASP mentioned) asking the community about this:

https://twitter.com/dotNetCoreBlog/status/928258899794382848

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.