Hey Aaron,
*> There is a huge difference between being able to access resources
through the user's browser while it's online vs being able to access
resources without the browser's involvement.*
While there are operational differences, the end result is compromission of
the exposed resources for
Hello Philippe,
Thanks for the new details. This new information let me indeed reproduce
the exploit, which seems different from the January one, that I wasn't
able to successfully reproduce against my current implementation.
*> For someone who is more than eager to demand that we prove them wron
Link for WIMSE list https://www.ietf.org/mailman/listinfo/wimse
On Mon, Aug 28, 2023 at 11:12 AM Justin Richer wrote:
> Hi all,
>
> Back at IETF116 in Yokohama, Evan Gilman presented information about
> SPIFFE, a workload security platform. At IETF 117 in SF, we presented a set
> of questions an
Hi all,
Back at IETF116 in Yokohama, Evan Gilman presented information about SPIFFE, a
workload security platform. At IETF 117 in SF, we presented a set of questions
and possible new work, to lots of positive feedback. Now we’ve set up the
Workload Identity in Multi System Environments (WIMSE)
> Again, there is something fundamentally misunderstood here: Philippe's
> exploit will not work with a correctly implemented service worker. Also not
> in an iframe. Also not if you unregister it and you start a new iframe.
For someone who is more than eager to demand that we prove them wrong
That's outside of the responsibility of a BFF. That's what web application
firewalls are doing, with disputable results. They are another tool that
can be used, for any of the described flows btw.
Le lun. 28 août 2023, 18:14, Dick Hardt a écrit :
> While a breach of a BFF may be as catastrophic
While a breach of a BFF may be as catastrophic as an exfiltration of an
access token, the BFF may also be more secure against a breach.
For example, a BFF could detect a possible compromise by the API usage
pattern becoming unusual to the app, that a RS is not able to detect as the
general usage p
I agree we should continue to explore service workers — but it does not
seem that using them is a best current practice — and on that basis and
assuming that is correct, I think the SW approach should be dropped from
the document.
On Mon, Aug 28, 2023 at 8:31 AM Yannick Majoros wrote:
> I think
> An XSS compromise would allow an attacker to call the resource server
from the browser context through the BFF, which would lead to the same
catastrophous result as doing it from another context.
There is a huge difference between being able to access resources through
the user's browser while i
An XSS compromise would allow an attacker to call the resource server from
the browser context through the BFF, which would lead to the same
catastrophous result as doing it from another context.
Cookies are sent automatically, potentially to resources which shouldn't
get it. Same threat level as
Something is deeply flawed about this thread. Consider that the following
quote from Steiner talks about information in the client as though the
client were actually the client is the resource owner. But the resource
owner should view the client as just another attacker. Somewhere the
interest of t
> BFFs are not any safer, XSS or any successful malicious javascript
execution has the same end effect
As described in the draft as well as in this email thread, this is
incorrect.
An XSS compromise of the BFF architecture results in the attacker being
able to make requests to the BFF with the le
I think we should discuss facts and demonstrations rather than show and
call to authority. I really want a constructive discussion on this. I'm
perfectly fine with service workers being seen as an unfit solution, if
it's backed by facts and proofs. We've not reached that point.
Le lun. 28 août 202
Again, there is something fundamentally misunderstood here: Philippe's
exploit will not work with a correctly implemented service worker. Also not
in an iframe. Also not if you unregister it and you start a new iframe.
There is no "need to explain yourself several times" and nobody has
"already de
My last comment was rather ironic: user-facing applications are dangerous
(security is hard, which I say nothing with), and that is true for any
scheme.. BFFs are not any safer, XSS or any successful malicious javascript
execution has the same end effect (=game over, complete compromise of
authenti
I think, by far, Philippe’s perspective on web security and the threat modeling
of BFF vs SPA based implicit flows is accurate and astute.
His perspective should be the driving force for any standard in this area.
I also think it’s dangerous misinformation to claim that BFF has no security
bene
*applause*
Sucks you need to explain yourself several times but this is very helpful for
the community.
> On Aug 28, 2023, at 7:52 AM, Philippe De Ryck
> wrote:
>
> Responses inline.
>
>> Still, there is some initial incorrect point that makes the rest of the
>> discussion complicated, and
Responses inline.
> Still, there is some initial incorrect point that makes the rest of the
> discussion complicated, and partly wrong.
I believe the key to make the discussion less complicated is to acknowledge
that there are two separate issues:
1. An attacker can potentially obtain tokens f
I think this is a great discussion, and it seems to me that Yannicks last
comment is basically what Phillippe is trying to point out..
I just wanted to remind the authors about a couple of things that we
briefly discussed during OSW in London.
Although it might not be directly relevant for this di
I support adoption.
In the past, when considering the encryption of JWT access tokens, I
learned that the draft regarding the metadata of the resource server had
expired, which was disappointing. For an authorization server to encrypt an
access token with an asymmetric algorithm, it must obtain a
+1
Am 28.08.23 um 10:33 schrieb Joseph Heenan:
I support adoption.
Joseph
On 23 Aug 2023, at 20:01, Rifaat Shekh-Yusef
wrote:
All,
This is an official call for adoption for the *Protected Resource
Metadata* draft:
https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
P
I support adoption.
Joseph
> On 23 Aug 2023, at 20:01, Rifaat Shekh-Yusef wrote:
>
> All,
>
> This is an official call for adoption for the Protected Resource Metadata
> draft:
> https://datatracker.ietf.org/doc/draft-jones-oauth-resource-metadata/
>
> Please, reply on the mailing list and
22 matches
Mail list logo
