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

[Brian Campbell <[e-mail]>]

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 <
[e-mail]> wrote:

> Hi Brian,
>
> Am 20.03.2018 um 15:37 schrieb Brian Campbell <[e-mail]
> >:
>
> +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/dr
> aft-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 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 <[e-mail]
> > wrote:
>
>> 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 <[e-mail]>
>> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> 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
> [e-mail]
> 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.*