openid / sharedsignals

OpenID Shared Signals Working Group Repository
45 stars 11 forks source link

Initial security audit feedback #166

Closed FragLegs closed 4 weeks ago

FragLegs commented 1 month ago

The first draft of the security audit highlighted several small items that ought to be fixed before we move to a release version.

2024-04-09_WP4.1a-Report.pdf

The relevant sections have been copied below.

3. Notes on the SSF Specification

Based on our work with the SSF specification, we suggest the working group consider the following changes. Most of these are based on (necessary) assumptions explained in Section 2 and we note that our model reflects the specification with these changes.

Issuer Identifier Validation.

While the configuration discovery specification mandates Transmitters to only use issuer identifiers with the https scheme [10, Section 6.1], there is no requirement for Receivers to only request configuration documents from https URLs. If a Receiver requests a Transmitter’s configuration document from an http URL, a network attacker may launch an MitM attack, resulting in the Receiver accepting arbitrary, attacker-chosen configuration data (including JWKs) and arbitrary, attacker-chosen SETs. We, therefore, recommend explicitly mandating Receivers to (1) obtain Transmitters’ issuer identifiers from trusted sources, and (2) verify that these issuer identifiers use the https scheme. In our model, we assume that these recommendations are implemented (see Section 2.5).

Stream Configuration Management API Endpoints.

The current SSF specification does not mandate the use of https for any of the stream configuration management API endpoints. We note that for SET delivery, [RFC8935, RFC8936] mandate the use of https URLs, and of course recommend mandating Transmitters to use https URLs for all stream management API endpoints and the JWKs endpoint.

In our model, we assume that this recommendation is implemented (see Section 2.5).

Requirements on Additional SET Delivery Methods.

In our model, we only consider the push and poll delivery methods as defined in [RFC8935, RFC8936] (see Section 2.2). This implies that in our model, SET delivery always takes place via TLS-protected connections. However, the SSF 5 specification does not limit allowed delivery methods to these two. Hence, we recommend requiring the use of SET delivery methods that ensure SET confidentiality and integrity.

FragLegs commented 1 month ago

Issuer Identifier Validation

I will address this in an associated PR.

Stream Configuration Management API Endpoints

PR #173 requires TLS for all stream management endpoints

Requirements on Additional SET Delivery Methods

I think this issue might already be addressed. In section 7.1.1, the method field of the delivery object in the Stream Configuration data restricts the delivery options to either push or poll.