2.1   Glossary¶

Cross-site request forgery (CSRF)

An attack that tricks the user into sending a malicious request on the attacker’s behalf. The most obvious mechanism to do this is cross-site GET or POST requests triggered by JavaScript run on a malicious site to which the user went in a web browser, although there are other mechanisms. CSRF generally exploits the browser’s security model to trick the browser into sending credentials that it has stored for its user (such as cookies) along with a request that is controlled by the attacker.

Cross-site scripting (XSS)

An attack that involves injecting malicious content (usually JavaScript or CSS, although there are other possibilities) into a trusted web site, such as through untrusted user input that is displayed unescaped to other users. The malicious code then runs within the security context of the trusted site and can access the user’s stored authentication credentials for that site, allowing it to take actions on behalf of the user, steal the credentials, or take other malicious actions.

4.1   Access control¶

Access control is done by scope. Each meaningful domain of access must be assigned a unique scope in the configuration of the authentication system. This needs to capture not only the granularity of user access permissions (for example, whether a given user is allowed to access a specific application), but also the granularity of service-to-service API calls. Restricting the scope of delegated tokens passed to applications limits the damage that can be done by a compromised application.

4.2   Credential isolation¶

The incoming request from a user may contain an access token in one of two places: an encrypted cookie that is read by Gafaelfawr, or in the Authorization header. Because the underlying application should not be fully trusted, we do not want to pass the incoming cookie or token directly to the application, since this would allow a compromised application to act as the user with the full scope of the original cookie (which may have that user’s full scope of access). The incoming authentication credential must be filtered out of the request before it is passed to the backend service.

For backend services that need to make calls on behalf of the user, a new token specific to that service will be issued dynamically, with only the scopes that service needs, and passed to the service via an HTTP header.

For options on how to implement this, and some further discussion, see SQR-051. The recommended approach is to filter out incoming cookies by replacing the Cookie header with a rewritten header and replacing or dropping the Authorization header.

4.3   Unauthenticated and optionally authenticated routes¶

Some services will want to expose unauthenticated routes. Virtual Observatory status routes, for example, do not require authentication. Such routes can use an Ingress configuration that bypasses the generic authentication layer, but should still prevent user credentials from being passed to the backend service if they are called by an authenticated user. In the simple case, this can be done by dropping the Cookie and Authorization headers in the Ingress using the following annotation:

nginx.ingress.kubernetes.io/configuration-snippet: |
  proxy_set_header Authorization "";
  proxy_set_header Cookie "";

If the unauthenticated backend uses cookies for some other purpose, this becomes more complex, since only the authentication cookie should be stripped. If we have this use case, we will implement an unauthenticated mode for the generic authentication service that allows all requests but still performs Cookie header rewriting.

Currently, the generic authentication layer does not support optionally authenticated routes: ones where authentication information should be provided to the application if present, but access should be allowed even if the user is not authenticated. This can be added if that use case arises.

4.4   Logging¶

Because authentication and access control is done via a generic layer in front of all applications, it can log all authenticated operations and maintain data about how tokens are used. This, in turn, will be used to investigate possible security incidents and to look for anomalies in how tokens are used (such as use from an unexpected IP address).

4.5   Configuration¶

In this design, the authentication configuration of a given application is contained in its Kubernetes Ingress resource. Annotations on that resource are read by the NGINX ingress controller and used to construct a subrequest to Gafaelfawr to make an access control decision for a given request.

The necessary configuration can be fairly complex, including:

• The required scopes to allow access
• Whether to create a delegated token for this user
• The scopes of the delegated token, if created
• Whether this is the notebook service (which requires some special token handling)
• Where (and if) to redirect the user to authenticate if they are not authenticated
• If not redirecting the user, whether to present a bearer challenge or a basic auth challenge (the UI of some applications may prefer a basic auth challenge to make ad hoc API calls via a web browser easier)
• Which user metadata headers to send to the application
• Whether to put the delegated token in an Authorization header
• Whether to allow cookie authentication
• Whether to prohibit POST with form submission Content-Type values
• What Content-Security-Policy header to add, if any

This can all be managed with manually-written NGINX ingress annotations with each service, with many of the parameters embedded in the auth-url URL, but this is tedious and error-prone.

We therefore plan to implement a custom Kubernetes resource that specifies a Gafaelfawr-protected resource, and a custom resource controller that writes the Ingress resource based on that custom resource. This will allow the above information to be expressed in more human-readable YAML or derived from the cluster Gafaelfawr configuration.

5.1   JupyterLab origins¶

The web security documentation for JupyterHub recommends using a separate subdomain for each user. We will follow this recommendation.

This will require serving notebooks using a wildcard certificate. The plan is to use a wildcard certificate from Let’s Encrypt, using the DNS solver to authenticate.

6.1   Summary of security model¶

The rules for what happens during JavaScript requests are very complex and have evolved over time. There are two parts to the security model: whether the browser will immediately send the request to the remote site or instead send an OPTIONS request first (this is called a CORS preflight), and whether the JavaScript initiating the request can see the response. Here is a brief and incomplete summary of the rules:

1. All requests to the same origin are allowed and will not trigger a CORS preflight check. This is a key part of why it is not possible to defend web services against JavaScript served from the same origin.
2. Requests to a different origin will trigger a CORS preflight check unless all of the following conditions are true (plus some other, less relevant ones):
   • The request is a GET, HEAD, or POST
   • The request does not send headers other than Accept, Accept-Language, Content-Language, and Content-Type
   • The Content-Type header, if set, is one of application/x-www-form-urlencoded, multipart/form-data, or text/plain.
3. If a CORS preflight check is triggered, the request will only be allowed if the server returns success to the OPTIONS call and includes appropriate headers allowing this remote origin.
4. If the request is made with credentials, it may be sent without a CORS preflight check if it meets the above criteria. However, unless the response from the server includes an Access-Control-Allow-Credentials: true header, the response will be rejected and will not be accessible to the JavaScript code making the request.

See Cross-Origin Resource Sharing on MDN for a good high-level summary and the the Fetch specification for all of the details.

In most cases, the Rubin Science Platform does not need to support cross-origin requests. When different components need to talk to each other, those requests are normally made by the server, not by JavaScript executed in the web browser. Use of the Portal Aspect from the Notebook Aspect is the one exception and is discussed in notebook-portal.

6.2   Application design¶

Where possible, Rubin Science Platform applications should not support cross-origin requests. Doing so securely will require substantial additional effort, so if the same need can be met by making the request from the server using a delegated token, that approach is preferred.

Applications must follow the standard web application conventions of using appropriate HTTP verbs based on whether a request may change state. In particular, GET must be reserved for read-only requests, and all requests that modify data or otherwise change state must use POST or another appropriate verb.

Unless required by a protocol that the application needs to implement, only applications intended for use via a web browser should accept POST with a Content-Type of application/x-www-form-urlencoded, multipart/form-data, or text/plain. APIs should instead require the body of a POST have a declared content type of application/json, text/xml, or some other value. (In other words, the typical REST API should require JSON or XML request bodies and not support form-encoded request bodies.) This forces a CORS preflight check for cross-origin POST requests, avoiding the problem where a POST from malicious JavaScript is sent with credentials and has an effect on the server even though the response is discarded by the web browser.

Applications designed for use with a web browser that accept form submissions should use normal CSRF prevention techniques, such as the synchronizer token pattern:

Applications that do not intend to support cross-site requests should respond with an error to any OPTIONS requests so that CORS preflight checks will always fail. Applications that intend to provide routes usable by client-side JavaScript from other Rubin Science Platform UIs (such as the Portal Aspect’s support for JavaScript use in the Notebook Aspect) will need to implement CORS internally. See 6.6   Internal cross-origin requests for more information.

6.3   Authentication methods¶

In general, users will authenticate to browser-based applications using a cookie and to APIs using an Authorization header. However, since the authentication layer is shared, it supports both authentication mechanisms. This can be useful for dual-purpose APIs used both via React browser UIs and via direct API calls, and for some cases where one may want to allow a service or other non-browser client to make authenticated requests to an application that is normally used within a web browser. However, it increases the risk of CSRF because including an Authorization header in a request always forces a CORS preflight check, but asking for cookies to be included does not.

Therefore, the authentication layer will support configuration indicating whether a given application should support cookie authentication. This can be disabled for pure APIs that aren’t intended to be used via a JavaScript frontend. When disabled, requests with cookies but no Authorization header will be denied by the authentication layer before reaching the application, providing defense in depth against problems with other CSRF protection mechanisms.

APIs that are also used by JavaScript frontends will continue to allow cookie-based authentication.

6.4   Origin header¶

If cookie authentication is used, the authentication layer will check for an Origin header sent with the request and ignore cookie authentication if that header is present, not null, and does not match the origin of the requested URL. The browser will add the Origin header automatically to cross-origin (and some same-origin) requests, and it cannot be disabled in JavaScript. This effectively disables cookie authentication for cross-site requests in browsers that support Origin, although the above explicit configuration should also be used for defense in depth.

6.5   POST content type¶

Applications that do not intend to support form submission do not need to accept the POST requests that avoid CORS preflight checks (ones with a Content-Type of application/x-www-form-urlencoded, multipart/form-data, or text/plain. We can therefore reject such requests at the generic authentication layer and prevent them from ever reaching the application. This relieves the application of having to check the Content-Type of the POST body and protects against overly-helpful framework libraries that may attempt to interpret POST bodies of the wrong content type. This will be an optional per-application configuration option.

6.6   Internal cross-origin requests¶

Some Rubin Science Platform applications may wish to provide APIs that can be used via JavaScript from other Science Platform applications. For example, the Notebook Aspect uses client-side JavaScript to display images from the Portal Aspect inside the Notebook Aspect UI. As described in 5.1   JupyterLab origins, each Notebook Aspect user instance will run in its own origin, so this is a cross-origin request. Furthermore, it is a cross-origin request without a simple list of allowed origins, since the origin for the Notebook Aspect is dynamic (based on the username). There will likely be other examples, with requests originating either from the Notebook Aspect or from other Science Platform UIs such as the top-level page.

Applications such as the Portal Aspect that need to satisfy these requests therefore must reply to the OPTIONS request sent as the CORS preflight check. This request should not be blindly successful. Rather, the application must check the Origin header to see if it matches the expected pattern of allowed origin, such as the pattern of a Notebook Aspect user notebook origin from the same Rubin Science Platform instance. If so, it must respond with success, copying the Origin value to the Access-Control-Allow-Origin response header and including Access-Control-Allow-Credentials: true in the response headers. If the origin doesn’t match a Notebook Aspect user notebook origin from the same instance, it should reply with an error.

Similarly, when replying to the subsequent actual request, the Portal Aspect must include Access-Control-Allow-Credentials: true in the response headers.

Unfortunately, this cannot be done in the generic authentication layer because the NGINX ingress doesn’t support intercepting and delegating OPTIONS requests, and it cannot be done directly in the ingress because the NGINX ingress CORS support doesn’t support dynamic validation of origins. It will therefore need to be done in the code of the application that serves cross-origin requests.

7.1   Application design¶

Rubin Science Platform applications ideally should attempt to use the full restrictive policy as described above. However, failing that, they should at least be designed to avoid inline JavaScript and inline styles. Inline objects are the easiest to construct in an XSS attack, so blocking them makes XSS attacks considerably more difficult.

Applications should then add the following header to their responses:

Content-Security-Policy: default-src https:

which will require all resources be loaded via HTTPS and disable unsafe inline objects of any type.

If the application serves all of its own resources and does not load resources from any external site, it should send this stronger header instead:

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

If it does not use JavaScript at all, it can disable loading JavaScript with:

Content-Security-Policy: default-src 'self'; script-src 'none'

Many other variations are possible; see Content Security Policy for more information. In general, an application should disable as many types of resources as possible. If it isn’t using a type of resource, turning it off means it’s not available as a potential vector of XSS.

7.2   Adding CSP via the ingress¶

When the application is written internally by Rubin Observatory, there is no reason not to have it send its own Content-Security-Policy header. However, sometimes we may deploy externally-written applications that can use a more restrictive content security policy but for whatever reason do not send the header.

For those applications, we will add a Content-Security-Policy header to all responses via the NGINX ingress configuration.

7.3   User-controlled content¶

Services that return user-controlled content, such as files from a user’s home directory, should set a maximally restrictive Content-Security-Policy on those responses and attempt to force the browser to download files rather than display them:

Content-Security-Policy: default-src 'none'; sandbox; frame-ancestors 'none'
Content-Disposition: attachment
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

This can be done either in the application or by the NGINX ingress configuration. The Content-Disposition header would ideally be added by the application so that it could add a suggested filename for the download.

With these settings, ideally the service should serve content with an accurate Content-Type header. The settings should force download rather than display of the file regardless of the Content-Type, but some operating systems may choose how the file is stored based on the Content-Type and this configuration disables content sniffing (dynamically determining the type of file from its extension or contents).