googlechromelabs / isewebsecuritybundle Goto Github PK

Expected Behavior

Create a demo application that showcases the bundle and updates with new released to main

Actual Behavior

No demo application currently exists

Steps to solve the Problem

1. Create Google cloud deployment
2. Deploy demo application
3. Link deploy to new releases to this bundle (GH actions or Travis CI)
4. Add links or instructions to README

Expected Behavior

Travis CI continious integration testing, such that each PR has the test suite run against it through travis

Actual Behavior

No CI service implemented

Steps to build a solution

1. Setup Travis CI integration
2. Create workflow
3. Test workflow
4. Apply workflow to repository.

In order to provide a complete development experience when using the bundle, a robust configuration is required. The config tree should allow a developer to control the majority of the moving parts in the bundle, or to use a fire and forget preset that will handle the majority of the configuration for them.

The configuration should consist of two primary parts, Default/Global and Paths. Both will share the same attributes, however any specified configuration in the Paths space, will overwrite the Default configuration in that case. An example configuration is as follows:

ise_web_security:
  default:
    preset: full
    fetch_metadata: 
      allowed_endpoints: ['/images', '/api/health'] 
  paths:
    '^/api': 
        report_uri: "https://localhost:3000/report"
        coop:       cross-site
        coep:       report-only
    '/index':
        report_uri: "https://report-uri:3000/report"
        coop:       cross-site
        coep:       report-only
    '/admin':
        preset: full

The full structure of the config is subject to some change. Discussions around it should be kept in this Issue ticket for future documentation

Expected Behavior

In order to allow a developer to modify their configuration across the application, a path based configuration option is needed. This should exist as an "array" of paths, each containing a key value configuration roughly identical to what is configurable at a global level. These path based configurations should overwrite any global configuration for that service.

Actual Behavior

At present, any major configuration construction effects the whole application.

Steps to Reproduce the Problem

• Refactor config tree as needed to reduce code duplication
• Devise parser for endpoints (Follow Nelmio example)
• Modify listeners to handle endpoint configuration
• Modify services/Policies to handle per endpoint configuration

Expected Behavior

When a symfony bundle is required using composer, a flex recipie should run adding the appropriate config, wiring and other install paramters. These recipies could be stored on the symfony flex contributors repo, to begin with before perhaps being moved to a more permenant location

Actual Behavior

No flex recipie exists for the current repo leading to the bug as found in #11

Steps to Reproduce the Problem

1. Research Symfony Flex recipies
2. Create dummy config files for copying
3. Create Flex Manifest file
4. Create PR into flex repo
5. Test recipie works on blank project

Expected Behavior

At a top level, presets should exist which cover the vast majority of cases for developers. Although config trees may be of help to some developers, it may make more sense to provide overarching presets for all the features at once as both a development tool as to help understand the practical applications of the features.

Each of these presets should and will include high level documentation explaining their benifits.

Steps to Implement Solution

• Extend config provider to parse presets
• Create unified documentation for presets
• Create preset schema
• Ensure presets are human readable
• Get feedback on presets post implementation

Links

#18
#9

Expected Behavior

In order to reduce development overhead, some sensible presets for different application levels should exist for COOP and COEP. These presets should take into account a few basic application architectures, and be stored in an easily extendable manner.

Actual Behavior

Steps to Reproduce the Problem

• Devise sensible presets
• Add presets to bundle
• Apply presets correctly
• Provide tests for presets

Links

#9

For example, COOP / COEP will just not do anything on insecure connections but there's no indication of an issue.

Expected Behavior

Nonce based CSP (with respect to script tags) will help to reduce XSS attack surfaces on web applications built with this bundle. The amount of CSP support already built into the Symfony project is somewhat limited. Discussions remain open with regards to implementing some level of the NelmioSecurityBundle which provides CSP for symfony web applications.

This feature regardless of the level of support is non-trivial and likely will involve interfacing with the Twig templating engine to ensure that nonce replacement/insertion is handled correctly.

Steps to Implement Soltution

• Research CSP modules in Symfony and other bundles
• Decide on what depth CSP should be implemented in bundle
• Research bridge between symfony and Twig
• Construct nonce generation modules
• Construct Template modification modules
• Devise implementation guides

Linked

#16

Expected Behavior

In order to reduce developer friction when implementing this bundle, it's prudent to construct presets that cover the most common site isolation issues that fetch metadata can handle.

Actual Behavior

At present, we have a default policy based on this article. However this does not cover all cases, i.e frame based isolation, certain widget constructions. Although it's possible to implement a custom policy, it's important to provide pre-built policies for both documentation purposes and to reduce friction.

Steps to Reproduce the Problem

• Devise 2 or 3 potential Fetch Metadata scenarios
• Construct Policies that could solve the issues that would arise
• Implement policies
• Devise Tests
• Update documentation to explain policies

Expected Behavior

Based on a discussion with merewood@, the inclusion of Logging is important for a number of the policies. Fetch metadata in particular due to it being purely serverside, without any broswer based logging options.

This feature should be a combination of Report collection using the Report-to/report-uri api within the browser, general logging through the Symfony Logging API and the Symfony profiler

Actual Behavior

No logging is available at the moment

Steps to Reproduce the Problem

• Implement development mode based on #6
• Add logging to Fetch Metadata Policies
• Add logging to COOP/COEP Policies
• Implement DataCollector for Symfony profiler

Created a new Symfony project via:

symfony new ise_bundle_test --full

Added the following to composer.json

{
    "require": {
        "ise/web-security-bundle": "dev-main"
    },
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/GoogleChromeLabs/IseWebSecurityBundle.git"
        }
    ]
}

Then run:

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)         
Restricting packages listed in "symfony/symfony" to "5.1.*"
Package operations: 1 install, 0 updates, 0 removals
  - Installing ise/web-security-bundle (dev-main e09141b): Downloading (100%)         
Writing lock file
Generating optimized autoload files
Deprecation Notice: Class Ise\WebSecurityBundle\Tests\IseWebSecurityFetchMetaTest located in ./vendor/ise/web-security-bundle/tests/RequestSubscriberTest.php does not comply with psr-4 autoloading standard. It will not autoload anymore in Composer v2.0. in phar:///home/rowan/bin/composer/src/Composer/Autoload/ClassMapGenerator.php:201
composer/package-versions-deprecated: Generating version class...
composer/package-versions-deprecated: ...done generating version class
84 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Symfony operations: 1 recipe (de0b1b118c4285a123651ecd0d43296d)
  - Configuring ise/web-security-bundle (>=dev-main): From auto-generated recipe
Executing script cache:clear [KO]
 [KO]
Script cache:clear returned with error code 1
!!  
!!  In IseWebSecurityExtension.php line 18:
!!                                   
!!    Notice: Undefined index: coop  
!!                                   
!!  
!!  
Script @auto-scripts was called via post-update-cmd

Expected Behavior

Trusted types will help reduce the scope of browser XSS sinks in the application. However as the application is primarily server side, with limited scope of javascript interaction, the implementation of this feature should simply provide a mechanism for defining Trusted Types headers and, if possible, an implementation guide as to how to use them in an application

Steps to implement a solution

• Understand Symfony CSP scope
• Define headers for Trusted types
• Devise sensible Trusted types policies
• Produce trusted types policy implementation guides

Expected Feature

Construct an interface for Fetch-Metadata policies. This is to provide a default "first party" policy, while also allowing developers with more specific needs to construct their own policies based on an interface provided by the bundle. This will also allow us to build our own policy presets more easily and use them in the configuration tree.

Actual Behavior

At the moment the Fetch-Metadata policies in the bundle are controlled by the config tree. This will become unweildy quickly to be sure.

Expected Behavior

As with fetch metadata in #5 COOP and COEP should have associated policy interfaces and default policies. They should be replacable by the end user but should include a number of enforceable default and preset policies.

Actual Behavior

At present, the ResponseSubscriber service handles COOP/COEP directly, this should be broken out to allow an interface to take over and handle it at a more abstract level.

Steps to Implement a solution

• Construct a COOP and a COEP policy interface
• Refactor COOP and COEP into separate policies
• Update Config to reflect refactoring
• Manually wire new Policy Services
• Create Default COOP and COEP policies

Expected Behavior

The Bundle should come with an automatic development mode, such that when the Symfony environment is detected to be in Development mode the bundle reacts accordingly. This should include the in built reporting API, activating logging internally for services like fetch metadata, and including in some level a profiler within symfony's built in profiler service.

Actual Behavior

At present a services_dev.yaml file exists however it is not correctly wired into the container service. This can be used to register specific services such as the profile and report-to controller such that they are not made active in production mode where they might cause resource or information leaks.

Steps to implement a solution:

• Wire up development services with the services_dev.yaml
• Create a development configuration tree
• Implement Symfony's internal logger in required services
• Ensure that there are no "trailing" routes in production mode
• Setup and configure a Symfony profiler for a more integrated development experience