Wallet Request Forgery

[FabriceBIT]

The Pre-Authroized Code Flow relies heavily on URI's sent by the Issuer. The Wallet then makes (normally web-) requests to several endpoints during the issuance process. During the flow the wallet will make requests to the URI in the credential offer, credential Issuer metadata, token request endpoint, and possibly more when using the notification endpoint or when "vct" is defined as an URI.

In the Security Considerations it is stated that we cannot assume the Credential Issuer to be trustworthy. We can therefore also not trust the URI's provided by the Issuer to be trustworthy.

We have a situation where the Wallet does arbitrary web requests to URI's specified by the Issuer. Even though the Wallet is not a server in our case, this sounds pretty similar to OWASP's Server Side Request Forgery attack:

The attacker can supply or modify a URL which the code running on the server will read or submit data to, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like http enabled databases or perform post requests towards internal services which are not intended to be exposed.

In the normal case this is no problem since the Wallet is actually expected to make request to any Issuer on the web. However, the Wallet should be restricted to make requests to internal services that are not intended to be exposed.

Attack 1: Leak Content If the malicious Issuer does have access to the victim's Wallet, there is nearly no way to extract the content of the data. There is some special case if the victim hosts an internal web service that returns a JSON file that matches the exact format of the Token Response. In this case an attacker could leak the access_token from this JSON document because it will be included in the Credential Request later.

Another possibility to leak content is when going over vct as URI with vct#integrity enabled. A malicious Issuer could set the vct to an internal URL of the victim Wallet and specify a vct#integrity to perform an equality check of an internal file. The response of this check can be leaked through the error message sent to the Notification Endpoint.

Attack 2: Change Internal Services The Token Request and Credential Request are POST requests and fully provided by the Issuer. They therefore qualify perfectly to the definition from OWASP:

perform post requests towards internal services which are not intended to be exposed

Questions How should these attacks be mitigated when during Implementation of the Wallet? Blacklisting is inherently hard[1],[2]. It is also not possible to filter out the entire local network since every network has different IP's. However, this seems like the best one can do. Would you have any better suggestions or thoughts related to this? Is this written down as a Security Consideration somewhere or does it make sense to add this?

[Sakurann]

yes, we have a security considerations section on pre-authorized code flow https://openid.github.io/OpenID4VCI/openid-4-verifiable-credential-issuance-wg-draft.html#section-12.3

[FabriceBIT]

Thanks for your help. Could you go a little more into detail on how a wallet should protect against such SSRF attacks? In the security consideration section I saw that due to a different topic (Transaction Code Phishing) it is recommended to only interact with trusted Credential Issuers. Is this the only intended way to protect against such attacks? How would you suggest to protect the wallet if trusting the issuer is not possible?

[jogu]

The easiest mitigation is to always send / only accept credential offers by value. Then the wallet can probably at worst only be tricked into fetching /.well-known/openid-credential-issuer which should be fairly harmless.