This issue is part of the ongoing formal security analysis of the SSF specification. We already created a formal model of the specification, identified and formalized security properties, and described the assumptions (as also agreed upon with the Working Group) upon which the analysis is based here: https://github.com/openid/sharedsignals/files/15014966/2024-04-09_WP4.1a-Report.pdf
Setting
As detailed in our report, we assume that Transmitters identify Receivers by dynamically created nonces which the Transmitter issues when responding to a configuration discovery request. More precisely, we assume that the Transmitters provide different endpoints for each configuration discovery request, with the URLs containing a unique part u, which is also used as the audience value for this Receiver. However, this issue also applies more generally to cases in which the identifier is chosen by the Transmitter for the Receiver out-of-band and transmitted from the Receiver to the Transmitter in a way that both parties agreed upon.
Overview
Let t be an honest Transmitter and r an honest Receiver, with u_r being the audience value assigned from t to r. Furthermore, let att be the attacker, and let u_att be the audience value that t assigned to att.
Intuitively, r should not accept a SET created by t with the audience value of the attacker. As shown in the following, this might happen under the setting described above, breaking the Session Integrity property from our report (see Section 4.2).
Detailed Description
We now give more details, based on the following diagram:
Configuration Discovery
Both the honest Receiver r and the attacker att get the configuration discovery metadata of t (Steps 1 - 4 of the diagram). As noted previously, we assume that the Transmitter assigns the audience values u_r and u_att.
The Receiver r obtains the configuration from att in Steps 5-6. Here, the attacker re-uses the audience value that it obtained from t, i.e., u_att.
The Receivers obtain the JWKS from the corresponding endpoints (not shown in the diagram).
Stream Creation using Poll Delivery
The Receiver r sends a request to att to create a new stream (see Step 7)
The attacker creates a stream at t and receives the polling endpoint pollEP_t and the stream identifier s_att (see Steps 8 - 9).
The attacker responds to the stream creation request with the same stream configuration that it obtained from t in Step 10.
Adding Subjects to Stream (Steps 11 - 13): This is only necessary if streams at t do not contain subjects for the corresponding audiences upon creation. In this case, the attacker sends an add subject request to t for a subject that the attacker is authorized to add to streams. The details of this step are not relevant to this issue.
Polling
The receiver selects a stream configuration (in this case, the configuration that it obtained in Step 10) and sends a poll request to the endpoint_url, i.e., to the polling endpoint of t (Step 14).
The Transmitter responds with a SET in Step 15. As per Section 4.1.3 of RFC 7519 (JSON Web Token), the Receiver must check the audience value of the SET: “Each principal intended to process the JWT MUST identify itself with a value in the audience claim.” In this case, the check of the audience value is successful if the Receiver (1) checks the audience value against a list of all audience values of the Receiver, or (2) checks the audience value against the value in the stream configuration. Furthermore, the issuer value of the SET is the same value as in the stream configuration.
We note that in our report (as described in Section 2.4.1), we assumed that the polling endpoint is protected by a bearer token that the receiver chooses when creating the stream. This is omitted from the diagram and would not mitigate this issue, as the attacker could re-use the token that it receives in Step 7 for the request in Step 8. The Receiver r would choose this token when sending the poll request in Step 14 (as the Receiver associated this token with the stream).
Possible Fix
Upon receiving the stream configuration (Step 10), the Receiver should check whether the stream configuration has the expected issuer value, i.e., the issuer value of the configuration from which the Receiver selected the stream configuration endpoint (in Step 7). (This check should also be done when reading, updating, and replacing stream configurations).
This issue is part of the ongoing formal security analysis of the SSF specification. We already created a formal model of the specification, identified and formalized security properties, and described the assumptions (as also agreed upon with the Working Group) upon which the analysis is based here: https://github.com/openid/sharedsignals/files/15014966/2024-04-09_WP4.1a-Report.pdf
Setting
As detailed in our report, we assume that Transmitters identify Receivers by dynamically created nonces which the Transmitter issues when responding to a configuration discovery request. More precisely, we assume that the Transmitters provide different endpoints for each configuration discovery request, with the URLs containing a unique part
u, which is also used as the audience value for this Receiver. However, this issue also applies more generally to cases in which the identifier is chosen by the Transmitter for the Receiver out-of-band and transmitted from the Receiver to the Transmitter in a way that both parties agreed upon.Overview
Let
tbe an honest Transmitter andran honest Receiver, withu_rbeing the audience value assigned fromttor. Furthermore, letattbe the attacker, and letu_attbe the audience value thattassigned toatt. Intuitively,rshould not accept a SET created bytwith the audience value of the attacker. As shown in the following, this might happen under the setting described above, breaking the Session Integrity property from our report (see Section 4.2).Detailed Description
We now give more details, based on the following diagram:
rand the attackerattget the configuration discovery metadata oft(Steps 1 - 4 of the diagram). As noted previously, we assume that the Transmitter assigns the audience valuesu_randu_att.robtains the configuration fromattin Steps 5-6. Here, the attacker re-uses the audience value that it obtained fromt, i.e.,u_att.rsends a request toattto create a new stream (see Step 7)tand receives the polling endpointpollEP_tand the stream identifiers_att(see Steps 8 - 9).tin Step 10.tdo not contain subjects for the corresponding audiences upon creation. In this case, the attacker sends an add subject request totfor a subject that the attacker is authorized to add to streams. The details of this step are not relevant to this issue.endpoint_url, i.e., to the polling endpoint oft(Step 14).We note that in our report (as described in Section 2.4.1), we assumed that the polling endpoint is protected by a bearer token that the receiver chooses when creating the stream. This is omitted from the diagram and would not mitigate this issue, as the attacker could re-use the token that it receives in Step 7 for the request in Step 8. The Receiver
rwould choose this token when sending the poll request in Step 14 (as the Receiver associated this token with the stream).Possible Fix
Upon receiving the stream configuration (Step 10), the Receiver should check whether the stream configuration has the expected issuer value, i.e., the issuer value of the configuration from which the Receiver selected the stream configuration endpoint (in Step 7). (This check should also be done when reading, updating, and replacing stream configurations).