We're basically on the same page, I think.
I Was just coming from the perspective that once you've solved the iframe
problem (say via a library), then it's six and one, or half a dozen and
another, so to speak. Of course if the spec were redone today, it would look
different and able to take i
What you call pessimism I call stating fact! 😎
This has nothing to do with SPA apps. Like Neil says any XSS in play and token
binding, HTTPOnly and similar do nothing to protect you. This is any web app.
And XSS defense in a complex app is rough. Take the time to study it! I’m happy
to presen
100% and that’s a good point. Stolen tokens will no longer work under token
binding but XSS that does “stored request forgery” is still the bane of all web
based apps.
No web app with XSS vulnerabilities is safe from “stored forged requests”,
which means you really need to be bulletproof from X
Ha! Well it was Jim Manico’s pessimism about http-only cookies that started it!
:-)
I agree with Jim about http-only, and I agree with you that token binding has
lots of other good advantages. But pretty much all security is lost if XSS is a
possibility. Even storing secrets on the server does
> On May 18, 2018, at 11:55 AM, Brock Allen wrote:
>
> > I don’t believe code flow today with an equivalent token policy as you have
> > with implicit causes any new security issues, and it does correct _some_
> > problems. The problem is that you immediately want to change token policy
> >
> I don’t believe code flow today with an equivalent token policy as you have
>with implicit causes any new security issues, and it does correct _some_
>problems. The problem is that you immediately want to change token policy to
>get around hidden iframes and special parameters.
Hidden frames
You cant extract a token bound cookie or AT and use it in a different user
agent.
You could still force the user agent to use a token bound cookie itself.
For the AT and refresh they are not cookies so they need to sent by the JS so
may be harder to trigger?
I thought I was the pessimistic o
I don’t believe code flow today with an equivalent token policy as you have
with implicit causes any new security issues, and it does correct _some_
problems. The problem is that you immediately want to change token policy to
get around hidden iframes and special parameters.
Once you start tryi
I might be missing something here, but aren’t bound tokens exactly as
vulnerable to the XSS attacks you describe as http-only cookies are?
— Neil
> On Friday, May 18, 2018 at 5:43 pm, Jim Manico (mailto:j...@manicode.com)> wrote:
> A few notes:
>
> > The session cookie should also be flagged as
And I agree, Brock. CSP-3 policies that use strict-dynamic and nonces are
fairly straight forward to deploy and provide backwards compatibility down to
CSP 2 and 1. I yearn for a world where token binding and CSP are commonplace so
I can sleep again! Until then, these solutions are fragile at be
> However moving the token used for refresh from being a HTTP only cookie to a
> refresh token available in the DOM makes me uncomfortable without having
> sufficient mitigations against XSS.
My conjecture is that it does not matter >>at all<< where you store tokens in
relation to XSS. There is
This is really fantastic news. Thank you for sharing that John. I’m a lot more
optimistic about timely adoption.
Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
> On May 18, 2018, at 12:53 PM, John Bradley wrote:
>
> Token binding was just approved by the IESG (one mor
Fair enough, and I'm happy that this discussion has started.
For now, IMO, CSP is a big help in protecting these types of apps. Token
binding will of course help too, once it's available/practical.
-Brock
On 5/18/2018 12:47:49 PM, John Bradley wrote:
There are lots of issues with the current
Token binding was just approved by the IESG (one more editorial pass to include
some non normative input then on to the RFC editor) .
It is enabled by default for Edge and IE on win 10. It is configurable on
Chrome but currently defaulted to off.
I expect that to change in the near future.
There are lots of issues with the current implicit flow around fragment
encoding as well.
However moving the token used for refresh from being a HTTP only cookie to a
refresh token available in the DOM makes me uncomfortable without having
sufficient mitigations against XSS.
The current flow i
A few notes:
> The session cookie should also be flagged as http only to protect it.
This provides no real protection. If I get XSS into your site I don’t need to
steal the cookie. I can just force requests that will automatically send it
(client side or stored request forgery). So while it’s
+1. I think this would be good to have.
Phil
> On May 17, 2018, at 9:23 AM, Hannes Tschofenig
> wrote:
>
> Hi Brock,
>
> there have been several attempts to start writing some guidance but so far we
> haven’t gotten too far.
> IMHO it would be great to have a document.
>
> Ciao
> Hannes
It sounds to me as if you're hesitant to recommend code flow (at least for now)
then for browser-based JS apps.
-Brock
On 5/18/2018 12:27:48 PM, John Bradley wrote:
Yes that was the original intent to have the AT be short lived and refresh the
AT via the authorization endpoint based on the ses
Yes that was the original intent to have the AT be short lived and refresh the
AT via the authorization endpoint based on the session cookie.
The session cookie should also be flagged as http only to protect it.
Having a refresh token in local storrage may introduce new security issues
unless i
I am not against having "as" as REQUIRED.
While we are at it should we recommend that rfp be single use?
This draft hangs around as a ID and probably is not read by most people.
We may also want to mention it in security topics if we haven't.
I need to update this in the next couple of weeks to
Hi all,
Looking at draft-bradley-oauth-jwt-encoded-state-08, I see in Section 2
(https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-08#section-2)
that all contents of the JWT that would bind the specific state value to
the AS are optional. This means that the following attack is pos
One thing I maybe should have listed in the pros/cons in my original email is
session management and token lifetime considerations, keeping in mind the
original intent of the implicit flow.
What I mean is that with implicit grant type, the client's ability to get new
access tokens is limited to
I have written some guidance already (in non-RFC format) on preferring code for
single page apps, and other security practices (CORS, CSP). From the AS point
of view, it aligns well with the native apps BCP. There are benefits of
thinking about native and SPA apps just as ‘public clients’ from a
23 matches
Mail list logo
