Re: [GNAP] security concerns / issues with data in URLs

[Aaron Parecki <[e-mail]>]

You asked specifically what work in the OAuth group I was referring to.

While it’s true that those two concerns I pointed out in OAuth are more
specifically about the use of the front channel than the fact that the URL
contains data, there are still concerns with putting data in URLs as
pointed out already in this thread.

The most straightforward issue is that in practice there are often gateways
or reverse proxies in front of servers and they may not be aware of what’s
behind them or that they should avoid logging certain things. While it’s
certainly possible to deploy this in a way that *is* secure and properly
configure it to avoid logging where possible, or encrypt data in the URL
instead of sign it and such, these seem like just additional concerns that
we’ll need to spell out in a security considerations section and are
additional ways that an implementation may end up with security issues.

Since we have the opportunity to recommend the best path for new
developments right now, it feels like we should be taking a more secure
stance on this and avoid creating situations that we need to explain our
way out of while we can.

Aaron Parecki



On Wed, Nov 18, 2020 at 5:05 PM Dick Hardt <[e-mail]> wrote:

> Got it, thanks!
>
> As we know, there is no certainty of who the originator of a redirect was,
> and there is no assurance about the integrity or secrecy of the URL
> contents.
>
> Those are not the case in GNAP with the client calling the AS -- so what
> is the risk of having information in the URL?
>
> You had mentioned the information leaking into logs -- but the AS controls
> those logs -- and the logs are a concern, the AS could put an encrypted
> token in the URL.
>
> ᐧ
>
> On Wed, Nov 18, 2020 at 3:38 PM Aaron Parecki <[e-mail]> wrote:
>
>> I was referring to the work being done to reduce the reliance on the
>> front channel:
>>
>> * Dropping the Implicit grant
>> * Adding PAR to initiate an OAuth request from a POST request instead of
>> GET
>>
>> ---
>> Aaron Parecki
>> https://aaronparecki.com
>>
>>
>> On Wed, Nov 18, 2020 at 3:04 PM Dick Hardt <[e-mail]> wrote:
>>
>>> Hey Aaron,
>>>
>>> In the WG meeting you referenced work in the OAuth WG about removing
>>> data that is in URLs for security reaasons. Would you elaborate on what you
>>> were referring to?
>>>
>>> /Dick
>>> ᐧ
>>>
>> --
---
Aaron Parecki
https://aaronparecki.com