Supporting material: Details on decision point about strict origin checking and acl:trustedApp

From Solid Community Group

Background

Web Access Control (WAC) has a section that details how servers should handle requests from web applications (or rather, requests with header Origin set) by checking the origin against a list of trusted origins. This must be done in order to prevent cross site scripting attacks.

In NSS v4 WAC is implemented using solid-permissions. This library implements origin handling as an boolean option called strictOrigins. It also provides an option originsAllowed where you can provide a string, a statement (as in statements in rdflib.js), a list of strings, or a list of statements.

When running solid start init in NSS v4 it suggests strictOrigins to false by default. It also does not make use of the originsAllowed option in solid-permissions. This has the effect that NSS v4 servers does not enforce strict origin check by default, and even if enforced, does not provide a configuration to allow POD providers or users to list origins they trust.

In NSS v5 WAC is reimplemented using acl-check. This is a rewrite by Tim Berners-Lee, reducing src files from 1829 SLOC to 192 SLOC. You can disable strict origin checking by setting the various origin-parameters to null. It also allows for a list of origins to be trusted.

When making use of acl-check in NSS v5 the team at inrupt decided to turn strictOrigins on by default. The team also implement the configurable option trustedOrigins as a list of strings, which allows POD providers to set a list of trusted origins.

Why we should have strict origin checking

Strict origin checking is far from a complete solution to the problem of malicious applications taking advantage of access they've tricked users to grant them. But it limits a very specific attack vector, which is that the malicious application is not able to gain access to resources shared with the compromised user without being trusted by the user who did the sharing.

Example:

  1. User A visits evil.com
  2. evil.com convinces user A to trust evil.com
    • User A whitelists evil.com as a trusted application
    • User A log in with their credentials using some authentication protocol (e.g. WebID-OIDC)
  3. evil.com starts extracting all the data it can
  4. evil.com finds URIs to resources that are shared with User A by User B
  5. evil.com makes requests on the behalf of User A to resources controlled by User B
  6. evil.com is denied access to these resources, since User B is not trusting evil.com

Problem

Web application developers have grown accustomed to strict origin check not being on by default in NSS v4 (both inrupt.net and solid.community has it turned off today). So if servers upgrade to NSS v5 and if they turn on strict origin checking (which should be recommended), this will break a lot of applications that are not trusted.

WAC allows for origins to be trusted with the predicate acl:origin for resources and containers. This is not supported by the sharing pane which makes it impossible to use the data browser to grant web applications access to specific resources. 

# example for granting access to files (resource.acl)
<#application-access> 
  a acl:Authorization; 
  acl:agent <[WebID]>; 
  acl:origin <[TrustedOrigin]> 
  acl:accessTo </resource.acl>; 
  acl:mode acl:Read, acl:Write, acl:Control.  

# example for granting access to containers (.acl) 
<#application-access> 
  a acl:Authorization; 
  acl:agent <[WebID]>; 
  acl:origin <[TrustedOrigin]> 
  acl:accessTo <./>; 
  acl:defaultForNew <./>; 
  acl:mode acl:Read, acl:Write, acl:Control.

There is no specification/standard on how applications can ask for permission to resources on Solid servers, so developers have to ask users to manually update their ACL files (e.g. use curl).

History

This is a summary of the overview provided in a working document that inrupt has created to get an easier overview of the problem.

When Arne Hassel was working to fix a bug with the use of acl-check he realized the problem.

Inrupt quickly organized a meeting with the inrupt team on February 27th. The decision was to split the solution into two: a short- and a long-term solution. The long-term solution would be something that was decided with the community and probably implemented as a specification. The short-term solution would be something that made the pain of migrating from v4 to v5 minimal for existing web applications. There were suggestions to what these solutions could be, but it was decided to set up a new meeting ASAP with Tim Berners-Lee to get his insights into possible ways to go about this.

The second meeting was done February 28th. First of all, Tim was very clear that the fact that strictOrigins was turned off by default in NSS v4 was a very bad choice. He wants it to be turned on by default in NSS v5. Second, he suggested implementing a proposed feature of the WAC that explains how users might list trusted origins for their PODs by using acl:trustedApp. The outcome of the meetings was to implement this feature as a short-term solution, and to start a process with the community on how we want to automate a process where applications can ask for access to resources on a POD.

The following weekend Arne implemented the short term solution in three parts. These are explained in solid/acl-check#17, solid/node-solid-server#1121, and solid/solid-panes#58, with suggested PRs fixing these being solid/acl-check#18, solid/node-solid-server#1122, and solid/solid-panes#59 respectively.

With these PRs users can add trusted origins to their PODs using acl:trustedApp. There is also a new pane, trustedApplications, that allows users to manage their trusted applications using the data browser.

In addition to these PRs we need to create resources that document and show users how they can add trusted applications themselves (e.g. tutorials).

Suggested solution

Inrupt suggests the following decisions to be made by the CG.

  1. Turn on strict origins checking by default in NSS v5
    • Turn on strict origins checking on inrupt.net and solid.community
  2. Merge PRs that implements the feature acl:trustedApp
  3. Work on a long-term solution where applications have a mechanism to ask users for access to data

Alternative solutions

These are some alternatives the team at inrupt have thought of. The team doesn't support these solutions, but they want to present them to the CG so that group can make an informed decision.

  1. Turn off strict origins checking by default in NSS v5
    • Tim does not want this solution
    • It sends a bad signal that we deliberately make our servers less secure by default
  2. Set up a system where application developers can ask POD providers to list their application as a trusted origin
    • This centralizes the ability to trust applications to POD providers, which we would argue against the philosophy of Solid
Retrieved from "https://www.w3.org/community/solid/wiki/index.php?title=Supporting_material:_Details_on_decision_point_about_strict_origin_checking_and_acl:trustedApp&oldid=65"