Original text:
The entity message body is a JSON object consisting of the following two fields:  When receiving the request, the client instance MUST parse the JSON object and validate the hash value as described in interaction-hash. If the hash validates, the client instance sends a continuation Alternatively, an attacker could start a GNAP request with a known and trusted AS but include their own attack site URL as the callback <del> for the "finish" method.  The attacker would then send the </del>  interaction "start" URL to the victim and get them to click on it. Since the URL is at the known AS, the victim is inclined to do so. The victim will then be prompted to approve the attacker's The details of this attack are available in HELMSCHMIDT2022 with additional discussion and considerations.  13. The privacy considerations in this section are modeled after the list

Reviewer comments:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: ba30f871d34a7516b6402d161b2c9a5924eafe68 Inspect the deploy log: Browse the preview:
If the client instance can cause the AS to fetch a URL, especially if that URL is dynamic, this can be used as a means to make the AS call URLs within its own protected domain and cause errors. Will need to be addressed in new security considerations paragraph.

Revised text:
The entity message body is a JSON object consisting of the following two fields: <ins> When processing such a call, the AS MUST protect itself against SSRF attacks as discussed in security-ssrf. </ins> When receiving the request, the client instance MUST parse the JSON object and validate the hash value as described in interaction-hash. If the hash validates, the client instance sends a continuation Alternatively, an attacker could start a GNAP request with a known and trusted AS but include their own attack site URL as the callback  <ins> for the redirect "finish" method.  The attacker would then send the </ins> interaction "start" URL to the victim and get them to click on it. Since the URL is at the known AS, the victim is inclined to do so. The victim will then be prompted to approve the attacker's The details of this attack are available in HELMSCHMIDT2022 with additional discussion and considerations. <ins> 12.28. There are several places within GNAP where a URL can be given to a party causing it to fetch that URL during normal operation of the protocol.  If an attacker is able to control the value of one of these URLs within the protocol, the attacker could cause the target system to execute a request on a URL that is within reach of the target system but normally unavailable to the attacker.  For example, an attacker sending a URL of "http://localhost/admin" to cause the server to access an internal function on itself, or "https://192.168.0.14/" to call a service behind a firewall.  Even if the attacker does not gain access to the results of the call, the side effects of such requests coming from a trusted host can be problematic to the security and sanctity of such otherwise unexposed endpoints. In GNAP, the most vulnerable place in the core protocol is the interaction-pushback, as the client instance is less trusted than the AS and can use this method to make the AS call an arbitrary URL. While it is not required by the protocol, the AS can fetch other client-instance provided URLs such as the logo image or home page, for verification or privacy-preserving purposes before displaying them to the resource owner as part of a consent screen.  Furthermore, extensions to GNAP that allow or require URL fetch could also be similarly susceptible, such as a system for having the AS fetch a client instance's keys from a presented URL instead of the client instance presenting the key by value.  Such extensions are outside the scope of this specification, but any system deploying such an extension would need to be aware of this issue. To help mitigate this problem, similar approaches to protecting parties against security-front-channel can be used.  For example, all URLs that can result in a direct request being made by a party in the protocol can be filtered through an allowlist or blocklist.  For example, an AS that supports the "push" based interaction "finish" can compare the callback URL in the interaction request to a known URL for a pre-registered client instance, or it can ensure that the URL is not on a blocklist of sensitive URLs such as internal network addresses.  However, note that because these types of calls happen outside of the view of human interaction, it is not usually feasible to provide notification and warning to someone before the request needs to be executed, as is the case with redirection URLs.  As such, SSRF is somewhat more difficult to manage at runtime, and systems should generally refuse to fetch a URL if unsure. </ins> 13. The privacy considerations in this section are modeled after the list