Security considerations around both "bad" icon URIs and "bad" names

[xmlgrrl]

RSR Sec 4 talks about how "A malicious resource server could register a bad icon URI at an authorization server, "infecting" the authorization server either when the icon is retrieved or by confusing a human resource owner about the nature of the resource set being protected." However, the same is true for a scope or resource set name, not just an icon_uri. This should be mentioned as well.

[mmachulak]

Very good comment Eve. We should generalise because it refers to the
resource type as well - e.g. if a default policy is set for a particular
resource type. This is more likely to happen than for a particular icon or
name or scopes (although my last statement is debatable).

On Mon, 8 Jun 2015 20:25 Eve Maler notifications@github.com wrote:

RSR Sec 4 talks about how "A malicious resource server could register a
bad icon URI at an authorization server, "infecting" the authorization
server either when the icon is retrieved or by confusing a human resource
owner about the nature of the resource set being protected." However, the
same is true for a scope or resource set name, not just an icon_uri. This
should be mentioned as well.

—
Reply to this email directly or view it on GitHub
#151.

[xmlgrrl]

Come to think of it, only a URI would have the infection vulnerability (which icon_uri would have explicitly, and perhaps a resource type could have implicitly if the string is a URI that the application tries to dereference). A resource set name, scope name, or resource set type only explicitly have the confusion vulnerability. I suppose we should put some thought into the angle of a resource set type confusing somebody other than a human resource owner, since its point is presumably to be machine-readable...

[jmandel]

I'm not sure I understand the distinction -- this is, effectively, a vulnerability on the part of the AS's frontend system. If an RS registers a resource set called <script>alert('p0nwed');</script>, and the AS is foolish enough to render that name without proper escaping, that's a security problem. But this is cross-site-scripting 101.

(Actually I'm not sure what the direct threat is with an image URI -- other than the wrong image being displayed -- since the AS would presumably render that image inside of an img tag.)

[jricher]

Some context: https://tools.ietf.org/html/rfc7591#section-5, paragraph 6.

 In a situation where the authorization server is supporting open
   client registration, it must be extremely careful with any URL
   provided by the client that will be displayed to the user (e.g.,
   "logo_uri", "tos_uri", "client_uri", and "policy_uri").  For
   instance, a rogue client could specify a registration request with a
   reference to a drive-by download in the "policy_uri", enticing the
   user to click on it during the authorization.  The authorization
   server SHOULD check to see if the "logo_uri", "tos_uri",
   "client_uri", and "policy_uri" have the same host and scheme as the
   those defined in the array of "redirect_uris" and that all of these
   URIs resolve to valid web pages.  Since these URI values that are
   intended to be displayed to the user at the authorization page, the
   authorization server SHOULD protect the user from malicious content
   hosted at the URLs where possible.  For instance, before presenting
   the URLs to the user at the authorization page, the authorization
   server could download the content hosted at the URLs, check the
   content against a malware scanner and blacklist filter, determine
   whether or not there is mixed secure and non-secure content at the
   URL, and other possible server-side mitigations.  Note that the
   content in these URLs can change at any time and the authorization
   server cannot provide complete confidence in the safety of the URLs,
   but these practices could help.  To further mitigate this kind of
   threat, the authorization server can also warn the user that the URL
   links have been provided by a third party, should be treated with
   caution, and are not hosted by the authorization server itself.  For
   instance, instead of providing the links directly in an HTML anchor,
   the authorization server can direct the user to an interstitial
   warning page before allowing the user to continue to the target URL.

[mmachulak]

BTW, what does it mean "URIs resolve to valid web pages."? Is there a definition of a "valid web page"?

[xmlgrrl]

As discussed on UMA telecon 2015-08-27: "We shouldn't have the AS check for URI host/scheme matching, so the second part of the third paragraph in RSR Sec 4 should come out. We don't want to add any SHOULDs." We can close this, presuming Maciej has already implemented amendments made on the call.