Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : 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 .
Paragraph (version B):
When processing such a call, the AS MUST protect itself against SSRF
attacks as discussed in security-ssrf.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.