Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt

From: Joseph Heenan <[email-masked]>
Date: Mon, 19 Mar 2018 22:16:21 +0000

Hi Torsten,

As we briefly spoke about earlier, "3.8.1. Authorization Server as Open Redirector" could I think be made more explicit.

Currently it explicitly mentions the invalid_request and invalid_scope errors must not redirect back to the client's registered redirect uri.

https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several more potential errors that appear to fall into the same category. I understand to block the attack fully we need 'must not redirect's for all the kinds of error that could cause an automatic redirect back to the client's registered redirect uri without any user interaction - 'unauthorized_client' and 'unsupported_response_type' seem to fall into that category. 'server_error' also seems dodgy (I would wager that on some servers that are known ways to provoke server errors), and I would have doubts about 'temporarily_unavailable' too.

Thanks

Joseph

---

From: Travis Spencer <[email-masked]>
Date: Tue, 20 Mar 2018 12:48:24 +0100

I read through this doc and would like to share a bit of feedback in
hopes that it helps:

* There is no mention of Content Security Policy (CSP). This is a very
helpful security mechanism that all OAuth servers and web-based
clients should implement. I think this needs to be addressed in this
doc.
    - No mention of frame breaking scripts for non-CSP aware user agents
    -  No mention of X-Frame-Options
* There's no mention of HSTS which all OAuth servers and web-based
client should implement (or the reverse proxies in front of them
should)
* The examples only use 302 and don't mention that 303 is safer[1]
   - Despite what it says in section 1.7 of RFC 6749, many people
think that a 302 is mandated by OAuth. It would be good to recommend a
303 and use examples with other status codes.
* 3.3.1 refers to client.com in the example. This is a real domain.
Suggest client.example.com instead. Same issue in 3.1.2 where
client.evil.com is used
* 3.1.3 (proposed countermeasures) - native clients that use a web
server with a dynamic port should use dynamic client registration and
dynamic client management rather than allowing wildcards on the port
matching of the OAuth server.
* 3.8.1 says "Therefore this draft recommends that every invalid
authorization request MUST NOT automatically redirect the user agent
to the client's redirect URI" -- This is gonna break a lot of stuff
including other specs! I don't think that's warranted, and I am not
looking forward to the fallout this could cause.

Anyway, my $0.02. Hope it helps.

[1] https://arxiv.org/pdf/1601.01229v2.pdf

On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan <[email-masked]> wrote:
> Hi Torsten,
>
> As we briefly spoke about earlier, "3.8.1. Authorization Server as Open
> Redirector" could I think be made more explicit.
>
> Currently it explicitly mentions the invalid_request and invalid_scope
> errors must not redirect back to the client's registered redirect uri.
>
> https://tools.ietf.org/html/rfc6749#section-4.1.2.1 defines several more
> potential errors that appear to fall into the same category. I understand to
> block the attack fully we need 'must not redirect's for all the kinds of
> error that could cause an automatic redirect back to the client's registered
> redirect uri without any user interaction - 'unauthorized_client' and
> 'unsupported_response_type' seem to fall into that category. 'server_error'
> also seems dodgy (I would wager that on some servers that are known ways to
> provoke server errors), and I would have doubts about
> 'temporarily_unavailable' too.
>
> Thanks
>
> Joseph
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Brian Campbell <[email-masked]>
Date: Tue, 20 Mar 2018 15:37:29 +0000

+1 to what Travis said about 3.8.1

The text in 3.8 about Open Redirection is new in this most recent -05
version of the draft so this is really the first time it's been reviewed. I
believe 3.8.1 goes too far in saying "this draft recommends that every
invalid authorization request MUST NOT automatically redirect the user
agent to the client's redirect URI."

I understand that text was informed by https://tools.ietf.org/html/
draft-ietf-oauth-closing-redirectors-00 but it takes one of the potential
mitigation discussed there in section 3
<https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#section-2.3>
(the one which happens to contradict RFC 6749) and elevates it to a "MUST".
I don't think something that drastic is warranted. I think there are other
mitigations - like strict redirect_uri matching, referrer-policy headers,
and appending a dummy fragment on error redirects - that can protect
against the more serious redirection issues without -security-topics trying
to introduce normative breaking changes to the behavior from the original
OAuth 2.0 Authorization Framework.

Perhaps there are some error cases not mentioned in RFC 6749 where
returning an HTTP error code to the browser would be better or more
appropriate than redirecting back to the OAuth client (my opinion on this
has gone in circles and I'm honestly not sure anymore). But saying that
authorization requests never automatically redirect back to the client's
redirect URI is excessive.

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 20 Mar 2018 16:44:08 +0000

Hi Brian,

> Am 20.03.2018 um 15:37 schrieb Brian Campbell <[email-masked]>:
> 
> The text in 3.8 about Open Redirection is new in this most recent -05 version of the draft so this is really the first time it's been reviewed. I believe 3.8..1 goes too far in saying "this draft recommends that every invalid authorization request MUST NOT automatically redirect the user agent to the client's redirect URI." 
> 
> I understand that text was informed by https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 <https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00> but it takes one of the potential mitigation discussed there in section 3 <https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#section-2.3> (the one which happens to contradict RFC 6749) and elevates it to a "MUST". I don't think something that drastic is warranted. I think there are other mitigations - like strict redirect_uri matching,

In the attack described in https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 <https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00> section 2.1. the attacker dynamically registers a client with the AS. So exact redirect URI matching won’t stop the open redirection attack since the attacker uses the correct URI. The problem is with the change in the underlying trust model. RFC 6749 assumes every configured client to be legit. This might have been ok at the time RFC 6749 was published. Open dynamic client registration collides with this assumption.   

We could distinguish between cases where the AS is confident the client is legit and other cases. But how does the AS determine it?

> referrer-policy headers, and appending a dummy fragment on error redirects -

Can you please explain how this protects from open redirection? 

> that can protect against the more serious redirection issues without -security-topics trying to introduce normative breaking changes to the behavior from the original OAuth 2.0 Authorization Framework. 

> 
> Perhaps there are some error cases not mentioned in RFC 6749 where returning an HTTP error code to the browser would be better or more appropriate than redirecting back to the OAuth client (my opinion on this has gone in circles and I'm honestly not sure anymore). But saying that authorization requests never automatically redirect back to the client's redirect URI is excessive.

Probably. Let’s discuss in detail. 

I think the AS should not automatically redirect the user in case of the following error conditions because an attacker could cause this errors via request parameters or its configuration:
- unsupported_response_type
- invalid_scope
- unauthorized_client
- invalid_request

kind regards,
Torsten. 

> 
> 
> On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer <[email-masked] <mailto:[email-masked]>> wrote:
> * 3.3.1 refers to client.com <http://client.com/> in the example. This is a real domain.
> Suggest client.example.com <http://client.example.com/> instead. Same issue in 3.1.2 where
> client.evil.com <http://client.evil.com/> is used
> [1] https://arxiv.org/pdf/1601.01229v2.pdf <https://arxiv.org/pdf/1601.01229v2.pdf>
> 
> On Mon, Mar 19, 2018 at 11:16 PM, Joseph Heenan <[email-masked] <mailto:[email-masked]>> wrote:
> > Hi Torsten,
> >
> > https://tools.ietf.org/html/rfc6749#section-4.1.2.1 <https://tools.ietf.org/html/rfc6749#section-4.1.2.1> defines several more
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Tue, 20 Mar 2018 19:38:37 +0000

The strict redirect_uri matching, referrer-policy headers, and appending a
dummy fragment on error redirects are things that protect from token
leakage/interception resulting from redirection on error, which is the
threat in section 2.2 of -closing-redirectors-00
<https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#section-2.2>.
It's true that they don't protect against the kind of open redirection
based on malicious client registration that's described in section 2.1
<https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00#section-2.1>.
But I don't believe that abuse (as that document calls it) is serious
enough to warrant trying to introduce a breaking change to the original
behavior of RFC 6749 <https://tools.ietf.org/html/rfc6749#section-4.1.2.1>
in this security topics document.

On Tue, Mar 20, 2018 at 4:44 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> Hi Brian,
>
> Am 20.03.2018 um 15:37 schrieb Brian Campbell <[email-masked]
> >:
>
> believe 3.8..1 goes too far in saying "this draft recommends that every
> I understand that text was informed by https://tools.ietf.org/html/dr
> aft-ietf-oauth-closing-redirectors-00 but it takes one of the potential
> mitigations - like strict redirect_uri matching,
>
>
> In the attack described in https://tools.ietf.org/
> html/draft-ietf-oauth-closing-redirectors-00 section 2.1. the attacker
> dynamically registers a client with the AS. So exact redirect URI matching
> won’t stop the open redirection attack since the attacker uses the correct
> URI. The problem is with the change in the underlying trust model. RFC 6749
> assumes every configured client to be legit. This might have been ok at the
> time RFC 6749 was published. Open dynamic client registration collides with
> this assumption.
>
> We could distinguish between cases where the AS is confident the client is
> legit and other cases. But how does the AS determine it?
>
> that can protect against the more serious redirection issues without
> -security-topics trying to introduce normative breaking changes to the
> behavior from the original OAuth 2.0 Authorization Framework.
>
>
>
> I think the AS should not automatically redirect the user in case of the
> following error conditions because an attacker could cause this errors via
> request parameters or its configuration:
> On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer <[email-masked]
> > wrote:
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Jim Manico <[email-masked]>
Date: Tue, 20 Mar 2018 09:41:48 -1000

If you plan on adding these web layer security suggestions into the OAuth standard I can think of 100-200 more requirements to add. I thought “do web security right” was an implied recommendation?

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Mar 20, 2018, at 5:37 AM, Brian Campbell <[email-masked]> wrote:
> 
> I understand that text was informed by https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors-00 but it takes one of the potential mitigation discussed there in section 3 (the one which happens to contradict RFC 6749) and elevates it to a "MUST". I don't think something that drastic is warranted. I think there are other mitigations - like strict redirect_uri matching, referrer-policy headers, and appending a dummy fragment on error redirects - that can protect against the more serious redirection issues without -security-topics trying to introduce normative breaking changes to the behavior from the original OAuth 2.0 Authorization Framework. 
> 
>> On Tue, Mar 20, 2018 at 11:48 AM, Travis Spencer <[email-masked]> wrote:
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 21 Mar 2018 07:36:36 +0000

Doing redirection in error conditions relates to OpenID Connect flows too.
There's been some related discussion recently about it in this issue:
https://bitbucket.org/openid/connect/issues/1023/clarify-
that-returning-errors-to-the

On Tue, Mar 20, 2018 at 7:38 PM, Brian Campbell <[email-masked]>
wrote:

>> In the attack described in https://tools.ietf.org/html
>> /draft-ietf-oauth-closing-redirectors-00 section 2.1. the attacker
>> We could distinguish between cases where the AS is confident the client
>> is legit and other cases. But how does the AS determine it?
>>

---

From: Travis Spencer <[email-masked]>
Date: Wed, 21 Mar 2018 12:28:43 +0100

> Doing redirection in error conditions relates to OpenID Connect flows too.

Also Mobile Connect. Those folks will be very upset by this change, I'm sure.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 21 Mar 2018 19:34:33 +0000

Hi all,

thanks for your feedback. Here is my text proposal for section 3.8.1. 

——

Attackers could try to utilize a user's trust in the authorization
   server (and its URL in particular) for performing phishing attacks. 

RFC 6749 already prevents open redirects by stating the AS
MUST NOT automatically redirect the user agent in case 
of an invalid combination of client_id and redirect_uri.  

However, as described in [I-D.ietf-oauth-closing-redirectors], an
attacker could also utilize a correctly registered redirect URI to 
perform phishing attacks. It could for example register a client
via dynamic client registration and intentionally send an 
erroneous authorization request, e.g. by using an invalid 
scope value, to cause the AS to automatically redirect the user
agent to its phishing site. 

The AS MUST take precautions to prevent this threat. 
Based on its risk assessment the AS needs to decide whether 
it can trust the redirect URI or not and should only automatically 
redirect the user agent, if it trusts the redirect URI. If not, it could
inform the user that it is about to redirect her to the another site 
and rely on the user to decide or just inform the user about the 
error. 

——

kind regards,
Torsten.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 22 Mar 2018 08:16:29 +0000

That works for me

---

From: Justin Richer <[email-masked]>
Date: Thu, 22 Mar 2018 14:36:23 +0000

I like the new text, it frames the error better and puts it in the context where it’s likely to be exploited. IE, newly dynamically registered clients shouldn’t be trusted as much as others.

 — Justin

> On Mar 22, 2018, at 8:16 AM, Brian Campbell <[email-masked]> wrote:
> 
> That works for me
> 
> On Wed, Mar 21, 2018 at 7:34 PM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi all,
>

---

From: Travis Spencer <[email-masked]>
Date: Fri, 23 Mar 2018 14:28:01 +0100

> inform the user that it is about to redirect her to the another site

The "...and should..." and "...it could inform..." don't directly line up
with the MUST at the beginning of that paragraph. It makes the MTI
precautions only and the rest is optional. If that's desired, OK, but I'd
suggest using all caps to make that clear -- MAY/OPTIONAL or MUST/REQUIRED
or SHOULD/RECOMMENDED