RS must check x-fapi-interaction-id is an UUID or IP address

[Vladimir Dzhuvinov]

In December 2021 when the Log4Shell vulnerability became public we had a sec review and it was discovered the FAPI 1.0 spec has no explicit requirement for the RS to validate the x-fapi-interaction-id header.

For the client we have a clear UUID requirement:

https://openid.net/specs/openid-financial-api-part-1-1_0-final.html#client-provisions

may send the x-fapi-interaction-id request header, in which case the value shall be a RFC4122 UUID to the server to help correlate log entries between client and server, e.g., x-fapi-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a.

However, the RS is not required to actually check the received header is indeed an UUID (or IP address), so a malicious client could potentially send special characters to exploit log injection and other vulns in software:

https://openid.net/specs/openid-financial-api-part-1-1_0-final.html#protected-resources-provisions

• shall set the response header x-fapi-interaction-id to the value received from the corresponding FAPI client request header or to a RFC4122 UUID value if the request header was not provided to track the interaction, e.g., x-fapi-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a;
• shall log the value of x-fapi-interaction-id in the log entry; and
• shall not reject requests with a x-fapi-customer-ip-address header containing a valid IPv4 or IPv6 address.

‌

Our recommendation is to consider addressing this in the next errata so that RSes are informed to perform a check on the header format before processing the request

(

and in FAPI 2 if the WG decides to keep the x-fapi-interaction-id in the next version

https://bitbucket.org/openid/fapi/pull-requests/288/add-initial-version-of-implementation#LFAPI_2_0_Implementation_Advice.mdT98

)

[Dima Postnikov]

@Dave Tonge @Nat Sakimura may be this one needs to go into security considerations? There are plenty of ecosystems that use this header…

[Nat Sakimura]

Related to #290 and conflicting?

[Erick Domingues]

Open Finance in Brazil is currently having the exact same concern as the one mentioned in this issue.

We have identified clients sending the header x-fapi-interaction-id with a value not compliant with RFC4122 which is leading to servers responding in unexpected ways.

Their suggestion would be to also require the RS to perform a check on the header before processing the request.

[Nat Sakimura]

Will discuss this in 2023-06-14 call.

[Joseph Heenan]

I suggest to the first two shalls, namely:

• shall set the response header x-fapi-interaction-id to the value received from the corresponding FAPI client request header or to a RFC4122 UUID value if the request header was not provided to track the interaction, e.g., x-fapi-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a;
• shall log the value of x-fapi-interaction-id in the log entry; and

We could add “if the value provided by the client is a uuid”.

‌

[Dave Tonge]

we discussed adding 2 conditions to an errata for FAPI 1, something like:

• shall set the response header x-fapi-interaction-id to the value received from the corresponding FAPI client request header, if that value is a valid RFC4122 UUID, or to a RFC4122 UUID value if the request header was not provided to track the interaction, e.g., x-fapi-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a;
• shall log the value of x-fapi-interaction-id in the log entry, if that value is a valid RFC4122 UUID;

‌

[Mark Verstege]

The x-fapi-interaction-id is used in Australia so I’d support adding those clarifications to errata.

Just noting that FAPI2 drops mention of the x-fapi-interaction-id because it is a resource-layer concern. I have questions longer term about protected resource provisions and I am proposing a FAPI2 resource profile here: https://bitbucket.org/openid/fapi/issues/607/create-a-resource-server-profile-on-top-of

‌