Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata
The security reason for exclusion of error codes and other information is that the data helps the attacker subvert the app. I continue my attempt to avoid helping the attacker. thx ..Tom (mobile) On Sat, Aug 26, 2023, 7:58 AM Dick Hardt wrote: > Jaimandeep: Do I understand your objection to adoption is that providing a > resource discovery endpoint increases the attack surface as an > attacker gains knowledge about the resource? > > If I understand that correctly, then you are suggesting security through > obscurity. > > As mentioned by Aaron, there is no requirement for a resource to support > the resource metadata, and the metadata itself could be protected. > > Practically though, I believe the argument that security is improved by > not having a resource discovery endpoint is false. Most resources have > publicly available documentation which will contain the same information, > and while the docs are not necessarily machine readable, LLMs can make it > pretty accessible. > > Even if you wanted to keep it secret, if applications that use the > resource are readily available, how the applications interact with the > resource can be discerned through reverse engineering. > I think that a security consideration calling out that a malicious actor > more readily has access to the protected resource metadata is an adequate > response. > > For my use case, the protected resource metadata is required for the > functionality I plan to implement. The AS has no prior knowledge about the > protected resource, and when a request is made, the AS learns about the PR > and presents the user with an experience based on the metadata for the user > to make a decision to grant access. > > /Dick > > > > On Fri, Aug 25, 2023 at 8:29 PM Jaimandeep Singh 40nfsu.ac...@dmarc.ietf.org> wrote: > >> Hi Aaron, >> >> Thx for your suggestions. I have reviewed the recordings and I would >> suggest following: >> >> 1. Design Consideration: The two components of the OAuth 2.0 ecosystem >> authorization server (step 1) and protected resource server (step 2) may >> appear independent, but from systems perspective there is a linear >> dependency between them. Directly engaging with step 2, even in a limited >> capacity, threatens the established sequence and poses substantial security >> and architectural implications. >> >> 2. Information Disclosure: Say I have my HIPPA record stored on a >> protected resource server, I don't want any app to even know that I have >> such a resource available with a protected resource server in the first >> place. The concept of exposing the mere existence of such data raises a >> glaring concern. Looking at Google, it has a fine-grained authorization >> strategy that meticulously limits access for its RESTRICTED scopes only to >> apps that meet certain security benchmarks. Once, the malicious apps come >> to know of the prized data at the resource server, it will lead to targeted >> phishing attacks, as was highlighted during the 117 meeting, underscoring >> the fragility of this approach. >> >> 3. The Imperative of Gradation and Minimal Exposure: Even if we have to >> go down this path, there is a definite need to mitigate the perils of >> overexposure. Instead we can look at gradation strategy, wherein the scopes >> could be categorized into levels, spanning from generic (Level 0) to >> tightly controlled (Level 5) access. There is no requirement of >> secondary URI in this appch. For instance, the sensitive scopes like level >> 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no >> need to divulge if a particular resource is present or not and not even the >> address of the authorization server. >> >> Thanks >> Jaimandeep Singh >> >> >> On Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki > 40parecki@dmarc.ietf.org> wrote: >> >>> Hi Jaimandeep, >>> >>> As with many OAuth extensions, this is not obligatory to implement >>> unless you need the functionality it provides. Many of the concerns you >>> mention are referenced in the security considerations section of the draft >>> already, and we would of course be happy to further expand that section as >>> appropriate. >>> >>> As we presented during the last two IETF meetings, there are many use >>> cases that would benefit from this draft that currently don't have an >>> interoperable solution. I would suggest you review those presentation >>> recordings so better understand the use cases. >>> >>> Aaron >>> >>> >>> >>> >>> On Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh >> 40nfsu.ac...@dmarc.ietf.org> wrote: >>> I do not support the adoption because of following: 1. Increased Attack Surface and Information Disclosure: The proposed draft inherently expands the attack surface by allowing the retrieval of detailed information about the protected resources held with a particular resource server, as outlined in section 3.1. We are inadvertently exposing the resources supported by the protected
Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata
Jaimandeep: Do I understand your objection to adoption is that providing a resource discovery endpoint increases the attack surface as an attacker gains knowledge about the resource? If I understand that correctly, then you are suggesting security through obscurity. As mentioned by Aaron, there is no requirement for a resource to support the resource metadata, and the metadata itself could be protected. Practically though, I believe the argument that security is improved by not having a resource discovery endpoint is false. Most resources have publicly available documentation which will contain the same information, and while the docs are not necessarily machine readable, LLMs can make it pretty accessible. Even if you wanted to keep it secret, if applications that use the resource are readily available, how the applications interact with the resource can be discerned through reverse engineering. I think that a security consideration calling out that a malicious actor more readily has access to the protected resource metadata is an adequate response. For my use case, the protected resource metadata is required for the functionality I plan to implement. The AS has no prior knowledge about the protected resource, and when a request is made, the AS learns about the PR and presents the user with an experience based on the metadata for the user to make a decision to grant access. /Dick On Fri, Aug 25, 2023 at 8:29 PM Jaimandeep Singh wrote: > Hi Aaron, > > Thx for your suggestions. I have reviewed the recordings and I would > suggest following: > > 1. Design Consideration: The two components of the OAuth 2.0 ecosystem > authorization server (step 1) and protected resource server (step 2) may > appear independent, but from systems perspective there is a linear > dependency between them. Directly engaging with step 2, even in a limited > capacity, threatens the established sequence and poses substantial security > and architectural implications. > > 2. Information Disclosure: Say I have my HIPPA record stored on a > protected resource server, I don't want any app to even know that I have > such a resource available with a protected resource server in the first > place. The concept of exposing the mere existence of such data raises a > glaring concern. Looking at Google, it has a fine-grained authorization > strategy that meticulously limits access for its RESTRICTED scopes only to > apps that meet certain security benchmarks. Once, the malicious apps come > to know of the prized data at the resource server, it will lead to targeted > phishing attacks, as was highlighted during the 117 meeting, underscoring > the fragility of this approach. > > 3. The Imperative of Gradation and Minimal Exposure: Even if we have to go > down this path, there is a definite need to mitigate the perils of > overexposure. Instead we can look at gradation strategy, wherein the scopes > could be categorized into levels, spanning from generic (Level 0) to > tightly controlled (Level 5) access. There is no requirement of > secondary URI in this appch. For instance, the sensitive scopes like level > 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no > need to divulge if a particular resource is present or not and not even the > address of the authorization server. > > Thanks > Jaimandeep Singh > > > On Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki 40parecki@dmarc.ietf.org> wrote: > >> Hi Jaimandeep, >> >> As with many OAuth extensions, this is not obligatory to implement unless >> you need the functionality it provides. Many of the concerns you mention >> are referenced in the security considerations section of the draft already, >> and we would of course be happy to further expand that section as >> appropriate. >> >> As we presented during the last two IETF meetings, there are many use >> cases that would benefit from this draft that currently don't have an >> interoperable solution. I would suggest you review those presentation >> recordings so better understand the use cases. >> >> Aaron >> >> >> >> >> On Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh > 40nfsu.ac...@dmarc.ietf.org> wrote: >> >>> I do not support the adoption because of following: >>> >>> 1. Increased Attack Surface and Information Disclosure: The proposed >>> draft inherently expands the attack surface by allowing the retrieval of >>> detailed information about the protected resources held with a >>> particular resource server, as outlined in section 3.1. We are >>> inadvertently exposing the resources supported by the protected resource >>> server. The secondary URIs which correspond to each of the protected >>> resources further expands the potential attack vectors. To illustrate, if a >>> protected resource server supports resources from 1 to 10, and a client >>> requests metadata for all these resources, it leads to 11 requests (1 + >>> 10). This exposes a total of 11 URIs to potential attackers with >>> information
Re: [OAUTH-WG] WGLC for Browser-based Apps
Right Philippe - there really is no way to create a secure client as a web app. You would need access to the trusted execution environment, which is not available. ..tom On Sat, Aug 26, 2023 at 5:21 AM Philippe De Ryck < phili...@pragmaticwebsecurity.com> wrote: > My responses inline. > > > 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 considerations is important. I share the point > of view that basing web applications on proven concepts is important. The > approaches detailed in the document have all their advantages > and disadvantages. > > > We have discussed the topic of browser-based apps in depth at the OAuth > Security Workshop last week. I am also working with Aaron Parecki on > updating the specification to more accurately reflect these advantages and > disadvantages. Updates will go out in the coming days/weeks, so we more > than welcome concrete feedback on the content there. > > There are 2 main approaches to browser-based applications security. One of > them is to store security credentials at the frontend. The other one is to > use cookies and a BFF. Though common practice, there is nothing > fundamentally more secure about them in a demonstrable way. Different > approaches, different characteristics and security assumptions. Nobody can > prove that either approach is better, just that there are different > concerns. > > Handling security in BFFs relies on cookies that cannot be read by the > javascript application. This mechanism provides some reliable protection > about the cookie itself that is used as a kind of credential to access > confidential web resources. It obviously demands some additional layers in > the flow (proxy or light server). You also need a mechanism to share > session information, either at the server side, or for example by having > the cookie itself hold that information. A bigger concern to me is that you > basically give up standard mechanisms for securing the flow between the > frontend and the backend: the security between the two is a custom solution > (based on cookies, in a specific, custom way, this part being in no way > OAuth or standard). This solves the problem by not using OAuth at all in > the browser part of the application, basically making the client > application purely backend. However, the fact that browser-based > applications cannot be secured with OAuth isn't universally true, and > strongly depends on one's definition of "secure", and basically comes down > to what the security issue is. > > > The updated specification will clearly outline the security considerations > when making the browser-based application a public OAuth client. > > *The main problem with a browser-only client is that the attacker with > control over the client has the ability to run a silent Authorization Code > flow, which provides them with an independent set of tokens.* These > tokens give the attacker long-term and unrestricted access in the name of > the user. A BFF-based architecture does not suffer from this issue, since > the OAuth client is a confidential client. Regardless of one’s definition > of “secure”, this is a clear difference on the achievable level of > security. > > Of course, as stated multiple times before, the use of a BFF does not > eliminate the presence of the malicious JS, nor does it solve all abuse > scenarios. > > > > Storing tokens at the frontend has advantages: it solves my concern above > about a standard based flow between the frontend and the backend. > > > The use of cookies is a core building block of the web, and is quite > standard. > > It's simpler from an operational point of view. And it's been used in the > wild for ages. > > > Anyone using a browser-only client should be informed about the clear and > significant dangers of this approach, which the updated specification will > do. > > > Both flows have been compromised numerous times. This doesn't mean they > are not right by design, but that the specific security concerns have to be > addressed. > > > If you have specific security concerns about a BFF, I’d suggest raising > them. Until now, I have only seen arguments that highlight the additional > effort it takes to implement a BFF, but nothing to undermine its security. > Plenty of highly sensitive applications in the healthcare and financial > industry opt for a BFF for its improved security properties and consider > this trade-off to be favorable. > > > Now, the concerns we are really discussing is, what happens in case of XSS > or any form of malicious javascript. > > In this case, for all known flows, session riding is the first real issue. > Whether the injected code calls protected web resources through the BFF or > using the stored tokens, is irrelevant: the
Re: [OAUTH-WG] WGLC for Browser-based Apps
My responses inline. > 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 considerations is important. I share the point of > view that basing web applications on proven concepts is important. The > approaches detailed in the document have all their advantages and > disadvantages. We have discussed the topic of browser-based apps in depth at the OAuth Security Workshop last week. I am also working with Aaron Parecki on updating the specification to more accurately reflect these advantages and disadvantages. Updates will go out in the coming days/weeks, so we more than welcome concrete feedback on the content there. > There are 2 main approaches to browser-based applications security. One of > them is to store security credentials at the frontend. The other one is to > use cookies and a BFF. Though common practice, there is nothing fundamentally > more secure about them in a demonstrable way. Different approaches, different > characteristics and security assumptions. Nobody can prove that either > approach is better, just that there are different concerns. > > Handling security in BFFs relies on cookies that cannot be read by the > javascript application. This mechanism provides some reliable protection > about the cookie itself that is used as a kind of credential to access > confidential web resources. It obviously demands some additional layers in > the flow (proxy or light server). You also need a mechanism to share session > information, either at the server side, or for example by having the cookie > itself hold that information. A bigger concern to me is that you basically > give up standard mechanisms for securing the flow between the frontend and > the backend: the security between the two is a custom solution (based on > cookies, in a specific, custom way, this part being in no way OAuth or > standard). This solves the problem by not using OAuth at all in the browser > part of the application, basically making the client application purely > backend. However, the fact that browser-based applications cannot be secured > with OAuth isn't universally true, and strongly depends on one's definition > of "secure", and basically comes down to what the security issue is. The updated specification will clearly outline the security considerations when making the browser-based application a public OAuth client. The main problem with a browser-only client is that the attacker with control over the client has the ability to run a silent Authorization Code flow, which provides them with an independent set of tokens. These tokens give the attacker long-term and unrestricted access in the name of the user. A BFF-based architecture does not suffer from this issue, since the OAuth client is a confidential client. Regardless of one’s definition of “secure”, this is a clear difference on the achievable level of security. Of course, as stated multiple times before, the use of a BFF does not eliminate the presence of the malicious JS, nor does it solve all abuse scenarios. > Storing tokens at the frontend has advantages: it solves my concern above > about a standard based flow between the frontend and the backend. The use of cookies is a core building block of the web, and is quite standard. > It's simpler from an operational point of view. And it's been used in the > wild for ages. Anyone using a browser-only client should be informed about the clear and significant dangers of this approach, which the updated specification will do. > Both flows have been compromised numerous times. This doesn't mean they are > not right by design, but that the specific security concerns have to be > addressed. If you have specific security concerns about a BFF, I’d suggest raising them. Until now, I have only seen arguments that highlight the additional effort it takes to implement a BFF, but nothing to undermine its security. Plenty of highly sensitive applications in the healthcare and financial industry opt for a BFF for its improved security properties and consider this trade-off to be favorable. > Now, the concerns we are really discussing is, what happens in case of XSS or > any form of malicious javascript. > > In this case, for all known flows, session riding is the first real issue. > Whether the injected code calls protected web resources through the BFF or > using the stored tokens, is irrelevant: the evil is done. Seeing different > threat levels between token abuse and session riding is a logical shortcut: > in many cases, the impact will be exactly the same. Stating that using stolen tokens is the same as sending requests through a compromised client in the user’s browser (client hijacking)
