https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-reducing-the-impact-of-toke
>
> Aaron
>
>
> On Mon, Aug 28, 2023 at 8:51 AM Yannick Majoros wrote:
>
>> An XSS compromise would allow an attacker to call the resource server
>> from
t; attacker’s authorization code is being returned.
>>
>>
>> But don't trust me on my words: what about demonstrating our claims with
>> actual code, and as such create a shorter, simpler, but more constructive
>> discussion?
>>
>>
>> I don’t underst
gt;> This obviously doesn't apply to everyone, but it's still common enough to
>> be significant. This is briefly mentioned in the security considerations
>> already:
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#name-reducing-the-i
; attacker to access far more data than the browser app alone, and for a
> longer period of time.
>
> The difference between these threats is extremely significant.
>
> Aaron
>
> On Mon, Aug 28, 2023 at 8:14 AM Yannick Majoros wrote:
>
>> My last comment was rather ironi
ll of this is quite inconvenient, especially if one is
> heavily invested in running browser-only OAuth clients. Unfortunately, it
> is the nature of web-based applications, and doing so requires a complete
> picture of the security implications. That’s exactly what we are working on
> with the specification.
>
>
> Kind regards
>
> Philippe
>
>
> —
> *Pragmatic Web Security*
> *Security for developers*
> https://pragmaticwebsecurity.com/
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
--
Yannick Majoros
Valuya sprl
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
; worker.
>
>
> Once again, I refer back to the start of my mail: *it is not about
> protecting existing tokens (scenario 1)**, *it is all about preventing
> the attacker from running a new flow (Scenario 2).
>
>
> I understand that all of this is quite inconvenient, especially
f
>security measures based on a risk assessment. In some cases their
>conclusion might be that a browser based app is not secure enough for
> their responsibilities.
>
>
> S
>
> søn. 27. aug. 2023 kl. 18:41 skrev Yannick Majoros :
>
>> Yes, but this is
t code running unaltered. ..tom
>
>
> On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros wrote:
>
>> Thanks for taking the time to respond and for the constructive feedback.
>>
>> Still, there is some initial incorrect point that makes the rest of the
>>
iframe src points to the authorize endpoint
>- The AS redirects the frame to the application’s callback with the
>authorization code as a query parameter
>- The attacker can monitor the iframe for a URL that contains the
>authorization code, stop the frame from loadi
Hi everyone,
The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
further explains that it "details the security considerations and best
practices that must be taken into account when developing browser-based
applications that use OAuth 2.0.".
As such, detailing security conside
using-service-worker-as-an-auth-relay-5abc402878dd
>>
>>
> The tokens are obtained from the main application. I quote:
> *getAuthTokenHeader
> method will communicate with js executed in a page to get current token *
>
> https://about.grabyo.com/service-workers-jwt-tokens/
>>
>>
> No mention of how tokens end up in the worker.
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Yannick Majoros
Valuya sprl
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
>
>
> Am 07.03.2023 um 14:25 schrieb Yannick Majoros:
>
> One possible solution: Store the redirect information in a signed JWT and
> place the JWT in the state parameter. I don't think this is written
> somewhere in the security BCP but I think this is a solutions used
> of the legitimate site is shown. The user might not recognize the redirect
> to a different domain and ends up using the phishing website of an attacker.
>
>
> Best regards,
> Karsten
>
>
> On 06.03.2023 23:34, Yannick Majoros wrote:
>
> Hi Rodrigo,
>
&g
read entire document, but, especially, about your
> questions, you may understand the threats about wildcards URL validation in
> section 4.1.1.
>
> This document also addresses some state threats and best practices.
>
> Rodrigo Speller
>
>
> Em seg., 6 de mar. de 2023
er open redirector to accomplish an account
> takeover. It's worth reading the writeup if you're curious about the
> implications of wildcard redirects within and outside of OAuth.
>
>
> https://salt.security/blog/traveling-with-oauth-account-takeover-on-booking-com
>
> Aaron
&
V.
>
> On Mon, Mar 6, 2023 at 09:12 Yannick Majoros wrote:
>
>> *This message originated outside your organization.*
>>
>> --
>>
>> Hello,
>>
>> From my understanding, OAuth 2 as well as 2.1 do not allow for wildcards
>&g
l restrict reuse of the authorization code anyway
What are your thoughts on how to implement that quite common feature?
Best regards,
--
Yannick Majoros
Valuya sprl
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Hello Dominick and everyone,
I contributed to the latest drafts. I do share some concerns about the
organization of the document, which can be improved. OTOH, some care has
been put in the latest drafts about consistency (naming patterns and parts
of systems in a similar way through all parts of t
py to set up some time to talk offline about how to make
> that happen.
>
> Aaron
>
>
> On Wed, Jun 15, 2022 at 4:08 AM Yannick Majoros wrote:
>
>> Hello,
>>
>> >>Best practices according to whom?
>>
>> >This list, and documents such as:
ation? Would it be useful to list and
detail some attacks that are not documented in the *OAuth 2.0 Security Best
Current Practice* document? Would submitting a new draft for frontends be a
good idea?
Best regards,
Yannick Majoros
Le mer. 15 juin 2022 à 04:11, Dick Hardt a écrit :
>
>
> B
f a follow-up or addendum to rfc-6749?
Thanks,
Yannick
Le sam. 11 juin 2022 à 20:55, Yannick Majoros a écrit :
> >> There is a lot of debate around the question. Are these really security
> best practices?
> >The intent of this draft is to document the best practices today. If
> The assumption is that you would also protect against CSRF attacks
> like any typical web application.
>
> > What if the backend is stateless and so doesn't have any session
>
> You would need to use an encrypted session cookie to avoid storing
> server-side state, b
raf)?
Best regards.
Yannick Majoros
Valuya sprl
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
23 matches
Mail list logo
