Both in the VCI and VP protocols, there are several places where principals must make HTTP requests to URIs controlled by 3rd-parties (i.e. received as callbacks in requests). This is a vector for SSRF attacks, as the URI could in principle point anywhere, while the protocols expect these to point to (somewhat-)trusted services; this could be prevented using an e.g. whitelisting approach. One example of such attack is exfiltration of VPs by manipulating the response_uri authorization request parameter.
Additionally, it is desirable as always to be able to control the set of trusted (root) certificates for the server at the pointed-to address.
The purpose of this task is to implement a reusable HTTPS client component which can be used in all these protocols, that will take care of the aforementioned issues to prevent us from executing potentially malicious requests.
Both in the VCI and VP protocols, there are several places where principals must make HTTP requests to URIs controlled by 3rd-parties (i.e. received as callbacks in requests). This is a vector for SSRF attacks, as the URI could in principle point anywhere, while the protocols expect these to point to (somewhat-)trusted services; this could be prevented using an e.g. whitelisting approach. One example of such attack is exfiltration of VPs by manipulating the response_uri authorization request parameter.
Additionally, it is desirable as always to be able to control the set of trusted (root) certificates for the server at the pointed-to address.
The purpose of this task is to implement a reusable HTTPS client component which can be used in all these protocols, that will take care of the aforementioned issues to prevent us from executing potentially malicious requests.