> On Jul 24, 2019, at 3:03 PM, Aaron Parecki <aa...@parecki.com> wrote:
>
> On Mon, Jul 22, 2019 at 2:14 AM Dominick Baier
> <dba...@leastprivilege.com> wrote:
>
<snip>
>> I would rather say that ANY JS app should use CSP to lock down the browser
>> features to a minimal attack surface. In addition, if refresh or access
>> tokens are involved - further settings like disabling inline scripting
>> (unsafe inline) and eval should be disabled.
>
> I'm not sure what to do with this suggestion. It feels like a blanket
> recommendation of enabling CSP will likely be ignored since it's too
> broad, and recommending disabling inline scripts is overreaching
> unless backed up by a specific threat it's protecting against. Did you
> have a particular threat in mind?
I would say that browser applications should take measures to harden their
applications again code injection and arbitrary code execution. Examples
include eliminating inline script (and limiting embeddable objects as much as
possible) via CSP, and versioning third party resources via techniques like
subresource integrity. Mechanisms such as augmenting the codebase to make sure
all appropriate user input, data storage, and output properly sanitize data may
be used - although they may be more expensive to implement and audit.
The AS should likewise take into account an application’s overall security
posture when deciding appropriate policies around delegated authorization
scopes and token lifetimes.
Best current practices include turning the screws tightly around CSP. But it is
(theoretically) possible to accomplish the same with brute-force sanitization,
which has been made simpler with framework support. It is still ultimately the
AS job to decide which clients have which capabilities.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
