Wouldn't abandoning the silent refresh and putting csp headers in the auth server responses be able to prevent a malicious script to initiate a new flow in a ? I could see this work with the sw pattern to prevent exfiltration and refresh in the background
Running JavaScript in the context of the page gives the attacker a lot of authority, not capabilities. It might give them both, but the details are really specific to the capability model in use.
This was a fantastic talk and really hit home the point that XSS needs to be both addressed and defended against in depth. Token binding (basically, if i understand it correctly, shifting the responsibility for token use from JavaScript to the browser at the TLS level) would be another way to address that, correct? I'm not sure if that's what the "browser component" discussion at the very end was talking about. But that would result in the same exposure shift from token exfiltration to session riding, albeit with the scopes of the token rather than the scopes of the (presumably) less-privileged BFF (although that's just a problem of granting the client too many privileges, and just using a BFF doesn't solve that as far as I can tell).
He literally even said that the BFF would likely be written as a simple generic proxy script, i.e. that the BFF would be fully equivalent to the full set of APIs. BFF "solution" was nonsense. There is no meaningful security difference between a session key and a Bearer token. If malicious code gets into your app through XSS, you are completely hosed either way.
@@fennecbesixdouze1794The BFF abstracts away the translation between the cookie solution and the standard Bearer header, thus being able to use out-of-the box solutions in the backend without having to teach it to extract the token from the cookie. XSS can make the site perform malicious operations, but it will not be able to copy the token this way.
@@fennecbesixdouze1794 True XSS is game over however the BFF does make it so that it harder to abuse the cookie, the token can be pulled from localStorage and abused whenever the user stops his session => Just keeps refreshing... IDP has no clue, LocalStorage does not have built-in security features like HttpOnly and Secure cookies, so developers need to take extra precautions to protect the tokens. But yeah in the end if XSS occurs you are screwed...
Seriously. No matter what kind of security u put in the backend, if your front end is vulnerable to XSS. You're gone.. So, take away no.3 is your first priority to tackle
BFF - the traditional practice using by "backend" developers before inexperienced "frontend" developers reinvent it with a new name after failure in trying to move everything to browser
If a frontend connects to multiple services on your backend side, the easiest way is probably to use an API gateway like Kong or even NGINX. You can set that proxy up to do the OAuth2 redirection for you and then send the tokens as headers for the subsequent requests...
Whole talk made absolutely less than zero sense. Getting the token and getting the session cookie are the same thing. There is absolutely no conceivable use case why any company would ever expose some "full API" that you cannot access through your session key but somehow can magically access using your OAuth Bearer token. I believe that the BFF pattern does in fact change the security characteristics of the system, but not in the way mentioned in this talk of somehow magically reducing the "attack surface of the API". He literally recommended it being a generic dumb proxy, i.e. the API surface is exactly the same by definition.
Session riding will have some timeframe, after which it will expire in contrast when you can have whole Auth flow being replicated and run with refresh token for indefinite amount of time which was shown in the first half of the talk. Plus with cookie you don't get hold of the token itself so will only be able to attack apis which are exposed via BFFs, it might be dumb proxy but doesn't have to be,. Also having a token generation in full control of the attacker can be leveraged via SSO to carry on attack on other apis / applications. So I think it is fair to say that potential attack timeframe & surface are reduced with BFF implemented right.
use http only cookies and they cannot be accessed by the client js. all attacks now need to be done by the malicious javascript inside the browser. but yeah, malicious js can still do everything the client can do while it's running.
![[LIVE] : ONE ลุมพินี 88 | คู่เอก "ป้อมเพชร vs อัสลามจอน"](http://i.ytimg.com/vi/1ZqTVVbMgbo/mqdefault.jpg)
great talk. it would be great if audience questions are repeated by the speaker for us VOD viewers.
Really eye opening and a bit concerning to be honest. Great discussion and demos.
Wouldn't abandoning the silent refresh and putting csp headers in the auth server responses be able to prevent a malicious script to initiate a new flow in a ? I could see this work with the sw pattern to prevent exfiltration and refresh in the background
Running JavaScript in the context of the page gives the attacker a lot of authority, not capabilities. It might give them both, but the details are really specific to the capability model in use.
This was a fantastic talk and really hit home the point that XSS needs to be both addressed and defended against in depth. Token binding (basically, if i understand it correctly, shifting the responsibility for token use from JavaScript to the browser at the TLS level) would be another way to address that, correct? I'm not sure if that's what the "browser component" discussion at the very end was talking about. But that would result in the same exposure shift from token exfiltration to session riding, albeit with the scopes of the token rather than the scopes of the (presumably) less-privileged BFF (although that's just a problem of granting the client too many privileges, and just using a BFF doesn't solve that as far as I can tell).
He literally even said that the BFF would likely be written as a simple generic proxy script, i.e. that the BFF would be fully equivalent to the full set of APIs.
BFF "solution" was nonsense. There is no meaningful security difference between a session key and a Bearer token. If malicious code gets into your app through XSS, you are completely hosed either way.
@@fennecbesixdouze1794The BFF abstracts away the translation between the cookie solution and the standard Bearer header, thus being able to use out-of-the box solutions in the backend without having to teach it to extract the token from the cookie.
XSS can make the site perform malicious operations, but it will not be able to copy the token this way.
@@fennecbesixdouze1794 True XSS is game over however the BFF does make it so that it harder to abuse the cookie, the token can be pulled from localStorage and abused whenever the user stops his session => Just keeps refreshing... IDP has no clue, LocalStorage does not have built-in security features like HttpOnly and Secure cookies, so developers need to take extra precautions to protect the tokens. But yeah in the end if XSS occurs you are screwed...
Seriously. No matter what kind of security u put in the backend, if your front end is vulnerable to XSS. You're gone..
So, take away no.3 is your first priority to tackle
BFF - the traditional practice using by "backend" developers before inexperienced "frontend" developers reinvent it with a new name after failure in trying to move everything to browser
If a frontend connects to multiple services on your backend side, the easiest way is probably to use an API gateway like Kong or even NGINX. You can set that proxy up to do the OAuth2 redirection for you and then send the tokens as headers for the subsequent requests...
hmm... I'm thinking of using PKCE.
PKCE does not protect against XSS when the browser is the oauth client / SP.
Whole talk made absolutely less than zero sense.
Getting the token and getting the session cookie are the same thing.
There is absolutely no conceivable use case why any company would ever expose some "full API" that you cannot access through your session key but somehow can magically access using your OAuth Bearer token.
I believe that the BFF pattern does in fact change the security characteristics of the system, but not in the way mentioned in this talk of somehow magically reducing the "attack surface of the API". He literally recommended it being a generic dumb proxy, i.e. the API surface is exactly the same by definition.
Session riding will have some timeframe, after which it will expire in contrast when you can have whole Auth flow being replicated and run with refresh token for indefinite amount of time which was shown in the first half of the talk. Plus with cookie you don't get hold of the token itself so will only be able to attack apis which are exposed via BFFs, it might be dumb proxy but doesn't have to be,. Also having a token generation in full control of the attacker can be leveraged via SSO to carry on attack on other apis / applications. So I think it is fair to say that potential attack timeframe & surface are reduced with BFF implemented right.
use http only cookies and they cannot be accessed by the client js. all attacks now need to be done by the malicious javascript inside the browser. but yeah, malicious js can still do everything the client can do while it's running.