 Hello, everyone. Thanks for joining. Just starting at the hour, our Indian Security Meetup. So I'll just give one or two minutes to everyone who get the notification to join. So this is our normal edition. I'm going to just start with the code of conduct and get started. So this is 21st November. This is our monthly meetup that happens every month. So this is November. So welcome all, welcome everyone. A couple of announcements. We operate on a strict code of conduct. You can read the conduct in this. We also have a privacy policy which is detailed posted here. Our event is recorded and a streamed live. So this video can be repurposed, can be used by Okta. You can read further instructions in the privacy policy. As always, as with any meetups, we are always looking for speakers. So if you are someone who is interested in Indian security and wanted to participate in our meetup, please submit your title, abstract and description at A0.20 ISAM CFP. We will slot you in for in our upcoming meetups. This is our newsletter, the QR code that is being shown. So all the DevDell events, where we are, where the workshop is happening, what are all the new announcements in the product, all these things that appears in your inbox every month. So if you'd like to sign up, please sign up for this newsletter. You have amazing information coming in your email box. And with that, I think we have two minutes past the hour. So this is the time to start our session, the insecurity of what 2.2 in frontence. This title is, this talk is being presented by our amazing speaker, Philippe Derac. He's a founder of Pragmatic Web Security. I'm going to invite him on stage and then I'll let him introduce himself. All right. Hi, Pradeepa. Thanks for having me on the show. First trick schedule, two minutes behind the hour and here we go. So let's make this happen. I'm Philippe Derac. I'm from Belgium. I'm a security expert and I basically run my own company called Pragmatic Web Security. And through that company, I help developers and architects and whatnot understand security and also build more secure applications. And I do that through training, online workshops, consulting, things like that. And every now and then I do conference and meetup talks like this one. And I'm excited to be here. Thank you. I also know that you're one of the OZIRA ambassadors. Yes, absolutely. I'm one of the first actually. I've been with the OZIRA ambassador program from the beginning. I'm an OZIRA user myself as well. And I quite often work with OZIRA. And yeah, I kind of like what you have there and absolutely. Okay. Thank you. I mean, when you're not solving entity and security, I know you'd like to have a PhD in security and you work exclusively on security and identity stuff. So what's your hobby? What do you do other than, you know, the idea and security stuff? Right now it's construction. So we're actually building a new house. And it takes quite a lot of planning and following up and getting your hands dirty with doing stuff as well. So yeah, I would say that's my current hobby. All right. You're the best. Yeah. I'm just going to disappear and then leave you here. Please get on with your talk. All right. Awesome. All right. I can just talk about construction for about an hour now. Let's talk about OAuth in front lens. I have about 40, 45 minutes to talk about the insecurity of OAuth in front lens. And to give you some insights in the talks, I'm going to first talk about why OAuth in front lens, like web applications is maybe not the bestest of ideas contrary to what you often find in practice. We'll talk about how to solve this problem for high security sensitive applications. I'll have some demos in between and we'll see where we get towards the end, but it should be a pretty interesting ride. So when we talk about front-end, so what are we really talking about? When we talk about front-ends, we're talking about JavaScript-based applications, right? Front-end web apps, Angular apps, React apps, native JavaScript, whatever you're writing, it's going to involve JavaScript running in the browser. And as you know, these type of clients have become first-party OAuth clients, as in they're full citizens in the OAuth landscape, a single-page app. There's like a separate specification for browser-based apps and so on. So this has become quite a big deal. The problem with JavaScript-based applications is that when you say JavaScript, then the word malicious is not far off, as in there's this class of attacks that results in malicious JavaScript executing in the application. And one way to get to that point of problem in this case to get to that issue is a cross-site scripting vulnerability, where the attacker would provide some data to the application and it gets rendered in a user's browser and all of a sudden the browser considers part of that data to be executable code, JavaScript code, and starts executing that. That's a cross-site scripting vulnerability. Other ways to get to the point of executing malicious JavaScript are loading a vulnerable dependency or a compromised file from a CDN. There's just kind of a whole bunch of ways that things can go wrong in front-ends. But the end result in these types of attacks here is the same. We have malicious JavaScript running in the application. Just to show you how dangerous this really is, I have a couple of slides with statistics, if you want to call it that, to indicate that this cross-site scripting problem remains a significant issue in front-ends. Here's a graph from Hacker One, a bug bounty platform, and this graph shows that about 23% of the vulnerabilities that they get reported are cross-site scripting vulnerabilities. So that's a quarter, that's quite a bit. And just to give you an idea of how things go in recent times, I did a search on the CVE database for cross-site scripting, and I did the search in August when I built the updated version of this presentation, full disclosure here. And when I did this search in August, you could find like dozens and dozens of cross-site scripting vulnerabilities reported in 2023 alone. You can see it by the IDs in the CVE list. And on August 22, actually, I counted them, I had 1,372 cross-site scripting entries for 2023. That's this new vulnerability reported just this year until August 22. And if you want to know what that amounts to, that's about six per day, six of these cross-site scripting vulnerabilities per day. And that's just the reported ones, the ones that end up on the CVE. There's so many more that are silently discovered and fixed and so on and so on. And that kind of highlights the problem of cross-site scripting and, by extension, malicious JavaScript. This is a real threat, a real problem that we have to account for in front-end applications. So what does that mean for your OAuth tokens? That's kind of the question. I'm going to go and answer in this talk in a high amount of detail. I have a very short slide to give you an idea of what it means. That means fire. I think the house is on fire basically. There's a significant amount of issues with this and it's really, really hard to protect your application against an attacker if the attacker already has the ability to execute that malicious JavaScript. So when that problem happens, our OAuth tokens are in big trouble. That's essentially the very short takeaway, and I'm going to dig a bit deeper into what that means specifically in the next 30-ish minutes. I had a slide about myself. I kind of told most of it about me already. If you want to know more, just visit my website, programmaticwebsecurity.com, and you can definitely find out a bit more if you want to, and reach out to me if you have any questions. All right. So what are we going to talk about? We're going to talk about OAuth OpenID Connect. I have this slide I use in all of my training classes and presentations to kind of sketch the landscape. Given the audience here, the identity, security meetup, I'm kind of guessing that you have a very good idea of what this means. I'm going to give you a very brief overview anyway. In case you aren't following along and then we'll dive into details. So we have OAuth and OIDC, the landscape, and part one is user authentication. That's OpenID Connect. That's a client interacting with this OpenID provider authentication server, getting information about the user. And then we have API access, access to protected resources. That's essentially where OAuth comes into play. And that picture is a client asking for tokens from the authorization server. Then we have the client accessing APIs in most cases with access tokens and APIs figuring out if access tokens are valid through a very explicit process like token introspection or a very implicit process like token signature verification and using claims in tokens. That's essentially the very high level view of the OAuth landscape. All right. We're going to focus on the left part of the presentation where the client is getting these tokens and then handling them somehow and we're going to focus on front-end specific applications. So what's the best practice for front-ends today? Well, a front-end web application if it wants to run the OAuth flow, best practice today is the authorization code flow. And we're going to use that authorization code flow as an example throughout the presentation as well. So what does that mean? This means that if the user wants to use a front-end and the front-end wants to access APIs on behalf of the user, the front-end will have to run a redirect-based code flow to get tokens. And that would go like this. If you want to schematically display it on a slide, the front-end will redirect the user's browser to the authorization server. And the message of that redirect is basically like, hey, I would like to do this on behalf of the user and so on. And the authorization server, if you're not authenticated as a user, will ask you for authentication in step four and you would authenticate with a username password or with a pass key or whatever you're doing. And by the way, that's not my real password. It's maybe a good password, but not my real password. So don't go try to hack my LinkedIn account with that password. It's not going to work or it shouldn't work, just to make this clear. Anyway, that stuff, so much going on, but the real value here for the OAuth flow becomes step six, because if everything checks out, if the authorization server, if your Auth0 instance or your Octa instance or whatever you're running is happy with that, it will issue a temporary value, the authorization code. And that authorization code goes back to the front-end application through a redirect-based mechanism and the front-end will bootstrap again, the JavaScripts start executing, reads that code from the URL and now exchanges that code for tokens. That's essentially the authorization code flow, goes to the authorization server, exchanges the code and gets tokens in response and that token can be an identity token telling the front-end who the user is, which is, well, okay, but not very useful. The real value is that access token because now the front-end can go to the API and access the API with that access token. The API in turn will take the access token and be like, okay, who's this? Oh, this is a token for Philip. I know, Philip, under this ID, I'm going to perform whatever operation I support and so on and so on. That's in a nutshell, on a high level view, the authorization code flow. There's a whole bunch of details I'm skipping over altogether, like client registration and redirect your eyes and a pixie proof gift for code exchange and so on and so on. These details do matter. There's plenty of other resources where you can find more information on that. I want to focus on the security aspects of this flow for now. All right, good. Sounds good. So what's the problem? The problem in this whole flow is the malicious JavaScript or the presence of malicious JavaScript and I'm going to use an example app for this. My app is called RestoreGrade, restaurant reviews. That's essentially what I use in all my trainings and our application is running in a certain domain like app of restoregrade.com and the application is perfectly fine until something bad happens, until we have that malicious JavaScript executing in the application. Cross-excripting, primary attack factor that can cause this or the loading of a malicious dependency. Like I said before, there's a bunch of ways that this can happen. So the question is what happens in this case? What can the attacker do? How problematic is this and what do we need to do to secure our application? And this is kind of a well-known concept. As in if you would read specifications on OAuth, they will talk about this problem, things like token exfiltration where the malicious JavaScript could exfiltrate tokens. So they talk about an issue like this. What's the token exfiltration problem? That malicious code runs and that now runs inside the application, meaning it can do the same things that the application can do. One of the things that the malicious code often does is reading locally stored data. Things like local storage and session storage are accessible from JavaScript and the application code, the malicious code, would go in there and steal whatever is in there, like tokens for example. In this case, the malicious code will read local storage, will serialize that into a string value and send that with a request. So it just sends a request to a server controlled by the attacker and sends the data to that server. It can be as simple as loading an image from a remote server and then including the values from local storage in the URL or in the query parameters to load the image and the data just flies away from the browser to the server of the attacker where of course malicious code can extract the values from the URL and abuse them any way they see fit. In this case, if it's an access token, they can abuse that token to access an API. Again, not an earth-shattering revelation here. If you've been working with frontends, if you're reading an OAuth spec or watched one of my previous presentations, you're probably well aware that this is possible and so is the entire community basically. So we have countermeasures for this. We have tokens that can be stolen in step two and one of the countermeasures you'll find as a best practice today is to keep access tokens short-lived to reduce the impact of stolen tokens. So if your access token is only valid for five minutes, then we can reduce the window of abuse for that token to five minutes. So if somebody steals it and they want to abuse the token, they can do that for at most five minutes because after that, the token will become invalid anyway. So that's a good best practice. All right. But if the token is only valid for five minutes, how do we deal with that in the frontends? Well, we deal with that by using a refresh token and refresh tokens allow the client, the frontend application in this case, to go back to the authorization server and say, like, hey, I need a new access token for another five minutes and you'll get a fresh access token. Of course, that refresh token can also be stolen in step one and two. So for refresh tokens, we have an additional security measure called refresh token rotation which is designed to stop or to prevent the abuse of stolen refresh tokens. All right. What's refresh token rotation? What is that all about? Well, if you dig into refresh token rotation, you'll find that the concept works as follows. Here's a scenario for a legitimate use case, a legitimate application, no malicious code, anything going on. So what happens? The application runs that flow, that authorization code flow, exchanges the code for tokens and we obtain two tokens, access token one and refresh token one. And access token one expires, for example, after five minutes. Good. All right. What does the application do? Well, after about four minutes, the application is like, yeah, my access token is about to expire. You know what? I'm going to get a new one and it uses refresh token one, goes to the authorization server says like, hey, here's a refresh token. Can I get fresh tokens? And if everything checks out and the token is valid and so on and so on, the application receives access token two and a new refresh token for next time, refresh token two. And the dance starts again, access token two expires. So a couple of seconds or minutes before it does, the application goes back with refresh token three and it gets access token, refresh token two, sorry, and it gets access token three and refresh token three. And once again, if the tokens is about to expire, we use refresh token three to get tokens at four. And well, my slide is full, but you kind of get the idea this keeps going and going until the refresh token reaches kind of an absolute lifetime. And then this flow stops and you have to run a new redirect-based flow with the user presence. That's the concept of refresh token rotation. How does this prevent the abuse of a refresh token? Well, let me rerun this scenario, but now with an attacker presence. So what's the idea? The idea is that we can detect when a refresh token is being abused because the legitimate application will do the refresh token rotation dance, but it's not supposed to use the same refresh token more than once. However, when the attacker steals one, in this case, the attacker executes that malicious JavaScript at this step in time. It steals refresh token two. And the attacker is like, yes, I have a refresh token. I'm going to go to the authorization server and I'm going to get fresh tokens. And the attacker does that. And the authorization server sees refresh token two. It's like, oh, yeah, that's a valid token. I gave that to this restogate application for Philly before. So here's the fresh access token, 83, and also a new refresh token for next time. So far, not good, I would say. As in we have an abuse scenario, this is not good. However, the application doesn't know that this happened. Otherwise, it would have fixed the problem. This is happening unbeknownst to the application. So after a couple of minutes, the application is going to be like, you know what? I'm going to get fresh tokens and it uses refresh token two. And at that point, the authorization server and not zero and octa is going to be like, what's going on here? Why are you doing that? That's not what you're supposed to be doing. And this is called reusing a refresh token. And this is considered to be an abuse case. As in the authorization server will be like, hold on. That's a problem. And it will stop issuing tokens for this interaction. And it will also revoke future or tokens that have already been issued related to this refresh token. So in this concrete scenario, the authorization server will not give out fresh tokens and it will also revoke RT three refresh token three because it's a descendant of RT two. So that's the idea of refresh token rotation. And this is kind of the consider to be the best practice for frontend applications to secure or prevent token abuse. And to be honest, this is a very simplistic view of malicious JavaScript. And that's what I've been working on in the past two years basically in trying to illustrate and prove that this approach is insufficient. And that's also what this talk is about. And trying to give better and more secure advice to developers. But we'll get there. Let's dive into this for a second in this scenario. What everything hinges on the fact that RT two, if you look on the slide that RT two is used twice. I can actually draw the slides. So the attacker is using RT two here. And the application is using RT two here. And that's what is being detected. And that's why the authorization server blows up this interaction says like, no, no, no, there's something wrong here. We're going to stop. So my question is what if that refresh token, the stolen refresh token is never used twice. In that case, there's no reuse. There's no detection and we might be in trouble a little bit. And how would that work? And here's a scenario that actually sidesteps refresh token rotation. So the premise is the same. We have an application. We have malicious JavaScript and the application is stealing our tokens one way or the other. And when it steals tokens, it sends them to the server controlled by the attacker. That step doesn't change. However, the attacker keeps doing that over and over and over again. And notice it. The attacker doesn't use the tokens here. The attacker just sits on the data and nothing happens. The attacker keeps stealing it and then they wait until the application goes offline until you close your laptop, port your airplane, your internet connection is gone, you close up shop for the day, whatever. Anyway, the attacker will be able to detect that your application, if you're the victim that your application has gone offline. And when your application is offline, guess what it's not going to do? It's not going to use that latest refresh token. So at that point, the attacker is like, aha, that's interesting because I know you're not going to use the latest refresh token. Yes, who has it? I have it because I've been stealing your tokens. And at that point, the attacker is going to abuse the latest refresh token, refresh token 17. And the authorization service is like, yeah, that's the last one. Here's access token 18 and refresh token 18. And the attacker is like, thank you very much. Bam, bam. And you now have an active attack going on. And the attacker can impersonate the user for the foreseeable future until the absolute lifetime of refresh tokens is reached. This is a problem, by the way. This is a massive problem. We kind of assume that in case malicious JavaScript happens or an attack with malicious JavaScript happens, refresh token rotation can stop the abuse and that turns out to be incorrect. And that's why one of the takeaways, and I'm going to get to that in a second on the slides. One of the takeaways is that just focusing on token exfiltration severely under-represents the capabilities of the attacker. Because the attacker can do anything that a legitimate front-end developer can do. And that includes detecting activity or even closing the application forcibly and so on and so on. Leaving a lot of room for the attacker to come up with creative scenarios. And I know that seeing this in action is much more interesting and effective than seeing some arrows on PowerPoint slides. So what I'm going to do is I'm going to attempt to demo gods and try to show you refresh token rotation or sidestepping refresh token rotation in a live demo. So let's see how that goes in practice. All right. What I have here is I have a very ugly demo. So my apologies for that a very simplistic demo that doesn't doesn't too much. So in this demo we have, let me just show you have across the scripting vulnerability. So let me first show you the vulnerability. It's basically the application has a just a second. I can show you right here. The application has a search parameter and the search parameter is how you would link send links to a friend, including a search for a certain restaurant. So the search for test and it doesn't yield any results because it doesn't actually search anything. It's a very simplistic demo. But basically the value from this URL parameter ends up in the page and that is a potential attack factor for cross-site scripting. If this value is inserted into the page in an insecure way that can result in cross-site scripting. And an insecure way. Let me skip back here would be you can test this by giving like benign HTML tags, the italic tag. And you can see here that our search term is now made italic, which means some markup makes it into the page and is being seen by the browser as markup. And there's still a way to secure it. If you would sanitize this value, it's probably still fine. But this is already a sign that there might be something going on. And then we can we can start adding a payload as the attacker. So I can now copy this link, run it through a link shortener and send you the link in the chat for this presentation. Everybody's like link from flip click. And you would open something like this in your browser. You search for test SVG, like let's create a new SVG image. Let's make it hidden so you don't see it. And when it loads, let's execute a piece of JavaScript. And that would be a prime cross-site scripting attack. The piece of JavaScript here, we're going to load something from my evil domain. My evil domain is malicious food just because it's pretty funny. And we're going to load a piece of JavaScript from there. And that's going to be inserted into the application at runtime and it will start executing a certain attack. What's the attack? I can show you it's hosted right here. The attack in this case is we're going to read session storage using JSON stringify to make it a string and then load an image from our evil server with that data. That's basically it. Super simple payload. And every three seconds, we're going to steal whatever data is in session storage and send it to a server controlled by the attacker. All right. Let's see this in action. So I'm going to copy this here. And I'm also going to log in, which is going to run that authorization code flow. You can see that we're using out zero here, which kind of makes sense given the context. And you can see that we're now logged in. And that's I also have set up the application, the front end to do very aggressive refresh token rotation. So we would actually see something happening. Typically you would do that only after a couple of minutes or even half an hour or an hour or something like that. But here it's going to do that every every 10 or 20 seconds something. So what you can see here in the console is that we're basically running a refresh token rotation. All right. Next step across that scripting happens. The user watches a review that contains some harmful data or follows a link that contains this whatever at some point in time. The attacker has the ability to execute malicious JavaScript code and we're going to mimic that same behavior right here. So if you do this, the application is still logged in. Everything is still fine. And you can see on the right, this is my malicious server right here. You can see in the terminal that we are already stealing tokens. Like, oh, here's a new refresh token. And we're doing that every couple of seconds like bam, bam, bam. Oh, here's another refresh token. And we're not abusing them. We're just stealing them. And you can see that the application gets them and the attacker steals them. Next step is I'm going to make my application unload, which mimics going offline. So I'll just open a new tab or do something else. And at that point, the attacker might be able to abuse that token. Let's see what's going on when we do exactly that. All right. So I'm going to log out. Application is closed. No more refresh token rotation. You'll see on the right that the attacker at some point in time is the server is going to be like, hey, hold on. I haven't seen this application in a while. See here, Klein is gone getting ready to abuse tokens. Very dramatic. And you can see here that we're abusing the latest refresh token. The one we stole right here is being abused and the attacker is getting a fresh access token and a fresh refresh token. You can see that this just keeps going and going and going. I'm very certain that people at Azure love it when I run this demo because I'm very aggressively hitting the refresh token endpoint here. I'm going to kill this, by the way, before Azure kicks me off. But that's how you sidestep refresh token rotation. All right. Let's hop back into the slides here. What does that mean? Well, as I've shown you on paper, refresh token rotation seems nice. But in practice, it's not a security measure. In practice, it just shows that people very often underestimate malicious JavaScript. It's not just about stealing the token and shipping it off somewhere else and then abusing it. It's about being smart, stealing tokens and then only abusing it when you know it's very likely to succeed. That is why refresh token rotation is not really the security measure that it's often described to be. I have to be careful here. I would say it's not very useful altogether. That's essentially the conclusion. All right. As I kept working on this, I started thinking more and more about ways to abuse the application and to abuse OAuth for that matter. Because what you'll see is that people realize that this is a problem and you'll find very creative solutions to hide tokens from JavaScript when possible. For example, Azure SDKs do a very good job of using a web worker to encapsulate a refresh token in a separate environment, an isolated environment, so you can't really access it. There's no way to steal it when you would be using the Azure SDK, which is a good job. It's really good. It's awesome to remove tokens from the main browsing context if you can do so. However, and that's where things get a bit tricky. If you think about that authorization code flow and how the security in that flow works, it turns out that it doesn't matter that you can hide tokens because the attacker will always be able to get new tokens. So even if the application that we're using here, if our victim application has the perfect token storage mechanism, which doesn't exist by the way, but imagine you can find something where you can put tokens in and they can never be extracted. It doesn't matter because the attacker still controls the application and the attacker can still do the same flow that the application does to obtain tokens in the first place. And here's how that scenario would work. And this is really where the shit hits the fan if you want to call it that. So what are we going to do? Well, in this scenario, the attacker, the malicious code sets up a handler to receive an authorization code from a silent flow running in an iframe. All right. And the attacker starts a silent flow in the iframe, which is a well supported feature and used by almost all SDKs to run a silent authentication flow. And the attacker runs that flow now with the authorization server. And the browser already has a cookie from before. This cookie in step two has been established when the user first authenticated and that cookie gets sent along with this request. And the authorization server is like, oh, it's the front end application. And here's cookie. Yeah, that's for Philip. I know who this is. Here's an authorization code that you can use to exchange for tokens. And the attacker receives that authorization code from the iframe, ships off the authorization code to their server, exchanges the code for tokens in step five and will now receive a completely new set of tokens. The application is running access token one and refresh token one. And the attacker has obtained access token a and refresh token a completely independent. There are two sets of tokens that have no relationship to each other, meaning that there will be no reusing refresh tokens and so on because there are two independent sets of tokens. That's essentially the attack scenario here. And this is a bad one. This attack scenario completely circumvents all potential token, token protection mechanisms that you can think of because the attacker is in full control of what's happening. And I can also illustrate how this would work in practice. All right, let me start my second demo. There we go. Same setup as before, same application as before, just a different backend because this backend does something else. So let me show you what we're going to do. The attack code for this is a bit more complicated. The attack code for this exchange is going to run that iframe. So we have some code somewhere that inserts the iframe. It's been a while since I looked at this. Run flow here. We're going to create an iframe, put it into the page, hide it, of course. And then we put it in the page here and we steal the code from the iframe and exchange the code for tokens. So forward authorization code. This line would send it to our malicious server right here. And on the malicious server, we would get that data. It's being posted right here. And we use the authorization code. We exchange it for tokens basically by calling the token endpoint on our authorization server, exchanging the code for tokens and we get an access token and a refresh token. All right, let me show you the payload is the same. By the way, we loaded SVG with that malicious JavaScript and off we go. All right, let's take a look at what happens in practice. We're still at the application. It's the same frontend, by the way, doing a refresh token rotation. Let me see if that, yeah, that fails because the attacker has used the latest refresh token. So that one is no longer valid. So let me log in again. That was refresh token rotation at work, by the way. All right, so we have a fresh set of tokens, fresh user interaction, and we are doing refresh token rotation in a second. There we go. All right, the application is up and running. Very happy our client here, our malicious server is not doing anything. So let's load the application with our payload. All right, the payload is being inserted. It has a small delay to run things. But here we go. On the right, you can see things happening. So we have, we're basically exchanging an authorization code for tokens. So the code that we exchange is this and we get an access token and a refresh token. And you can already see that this refresh token is different than the one you see in the browser. This is MCK something and the in the browser are NM something, something. And you can see that both parties, the malicious server and the browser are using their latest refresh token to obtain fresh tokens. And this illustrates that both parties have an independent set of tokens and the attacker is now being able to impersonate the user without much chances of being detected. And the attacker can do this until the refresh token hits the absolute lifetime, which is probably in about eight-ish hours or longer in that matter. And that's how you sidestep all these protection mechanisms altogether. All right. By the way, if you're thinking about advanced security mechanisms, like using things like refresh token rotation, sorry, things like Deepop demonstration of proof of possession. That wouldn't work here either because the attacker would be able to use their own secret to bind to the tokens and so on. So there's nothing you can do to stop this attack scenario. As in, well, no, there's something, but in a front-end alone, none of the security measures work because everything that the front-end can do, the attacker can do. And the takeaway here is that you cannot secure browser-only flows. If this scenario is an important scenario for your application, if you're like, hey, if malicious JavaScript executes, we do not want the attacker to obtain tokens for the user, then there is no way to stop this. It's game over. As in, you cannot do this in the browser alone, which brings us to a very important question. What do we do then? What's the solution? Well, if you want to protect flows like this, if you want to stop the abuse in scenarios like this, you need to involve a back-end component. You cannot do this in a front-end alone. You need to build an application that uses what we call a back-end for front-end. And a back-end for front-end is a completely new architecture, which sounds a lot more complicated than it really is. And I'm going to walk you through the conceptual idea in this presentation, give you enough context so you know how to dig deeper into the PFF principle. So take one step back. This is our application as we've seen so far, right? We have a front-end application interacting with the authorization server. And one of the problems is that there's no client authentication. This is a public client. There's no authentication on these steps between the front-end and the authorization server. It's not a confidential client. And that means once you have an authorization code, it can be abused easily by the attacker. That's the problem. And we're going to fix this by adding a component in the middle, and that component is the BFF, the back-end for front-end. And our back-end for front-end is a server-side component that belongs to our front-end. So it's part of our front-end application just running on a server. And the BFF will resume or will consume all of the OAuth responsibilities. And it's a server-side component making it a back-end component, a confidential client. So in step one, you can see that we're now using client authentication. That means that the flows from the BFF with the authorization server are secure. And you cannot just exchange an authorization code without stealing also or without knowing that client ID and secret. That's a major step forward. The BFF and the front-end, they keep track of tokens with cookies. So they just set up a constant, well, they typically, it's a client-side session containing the tokens and better than the cookie. That cookie is inaccessible from JavaScript. As in the front-end sends a request and the cookie is there, so the back-end can read it, the BFF can read it, but the attacker in JavaScript would not be able to extract anything from that cookie because the cookie is not accessible. And when the front-end wants to call an API, this, the front-end, just sends a request to the BFF, saying like, hey, I want to get a list of reviews from that API, the BFF will forward the request with the access token. So the BFF will translate this cookie into the access token here in step three, so that the API can handle that request as before. That's essentially how this would work in practice. Sounds, again, this sounds like, whoa, that's a lot of work, but that BFF is actually fairly straightforward to build. So what would change in the application from before? Let's walk this step-by-step. So let's say we have a front-end directly interacting with the authorization server. What do we do to modify it to use the BFF? Well, first of all, you remove all OAuth stuff from the front-end. Like you rip out the SDK, you remove the OAuth client.d and redirect all of that stuff, just goes away. You can drop it. On the API, no changes. Literally nothing has to change. The API accepts an access token, it will still get an access token, so you just verify the claims in that token just like before. No changes. Authorization server, minor changes, a conflict change, basically. You now use a confidential client instead of a public client. So that means in an L0, you would have to change the type of client, basically, so it can use a secret and it has to use a secret, and that's it. And then, of course, the BFF, that one is a new component. It has to do three main things, three responsibilities. It runs OAuth flows. So you use a server-side OAuth library, a Node.js library for that, something like that. It does session management, so you have a cookie library that you have to use, and it proxies requests from the front-end to the API and back, so it has a proxy library. Three core building blocks where you'll find libraries in virtually any language to handle these responsibilities. So you don't really have to implement much if you want to build a BFF yourself, and you can find libraries that even provide full BFF functionality. This solves most of the issues we had. Seriously, because the attacker, able to like abuse stolen refresh tokens, there's no more refresh tokens to steal, there's no more access tokens to steal, that's good. The attacker running like a silent flow in an iframe, they can get an authorization code, sure, but they can't exchange it because it would require client authentication, and that is not possible. So in essence, all of the attacks I discussed before have been solved, which is a massive step forward. The BFF adds in a lot of security benefits. However, and this is a very important disclaimer, the BFF doesn't solve your crosshead scripting problem. If the attacker had the ability before to execute malicious JavaScript, moving towards the BFF architecture doesn't magically solve that problem. It just limits the damage that the attacker can do, but the attacker can still control the client, and the attacker can still send requests through the BFF in the name of the user. There's nothing you can do to stop that from happening, apart from fixing your crosshead scripting vulnerabilities. However, the scenario is a bit better, because before the attacker could steal tokens and call any API that would accept a token, now the attacker can only access endpoints exposed by the BFF. So if the BFF says like, yeah, I'm only going to give you access to like three of the 17 endpoints on the API, the attacker can only access three of the 17 endpoints, not all 17 anymore. And if you really want to, you could also implement additional features in your BFF to do things like anomaly detection or rate limiting or stuff like that. So with a normal frontend, since you're like five requests per minute, and all of a sudden you get like 50 or 500, the BFF could be like, chill out dude, let's not do this, and let's stop you from accessing me altogether. Don't have to, but you can. And that's what the BFF really brings to the table. It significantly increases security, and for security sensitive applications, business applications, or applications handling any kind of personal or sensitive data, this should be the default. BFFs are already heavily used in financial scenarios, banking scenarios, healthcare scenarios, where the sensitivity of the data is not questioned, where it's like a given, where the impact of a breach is significant. In those fields, a BFF or a backend for frontend is already, or it's rapidly becoming a best practice. All right. Like I said, I've been working on this for quite a while. I've been talking about this for quite a while as well. And in the end that has kind of resulted in me stepping up instead of just ranting like old man yelling at cloud. I was like, yeah, this is, people need to understand this. We need to properly document this. I started doing that, started working with Aaron, Aaron Parakey on improving the OAuth for browser-based apps specification. So everything I've talked about right now, we've updated the spec to accurately reflect these risks, these dangers, the scenarios, the different options, the trade-offs, and so on and so on. So if you want to know a bit more, I recommend you check it out. It's the latest draft from October 23. And if this one is well received by the community, this will become the final version as well. So if you want to know more, definitely check it out. And you can read up on what I just talked about here. All right. Key takeaways. What do we have here? Securing OAuth in the browser alone is not possible. This is a very important realization. If you're building like a recipe website for your grandmothers recipes, then doing OAuth in the browser is probably fine. If you're building any kind of a business application, my first piece of advice would be already moved to a BFF. Don't expose it to later. Just do it because a BFF avoids making things worse when a malicious JavaScript base attack happens. It's still bad, but with normal OAuth, which in front of clients, it becomes a lot worse with a BFF. We maintain the status quo of just being in trouble of the malicious JavaScript being there, not because it expands or escalates to full on token theft. And then the third takeaway is kind of a follows from that. And that basically says that you have to follow secure coding guidelines to fix cross-site scripting. This is not a joke. I mean, this is a problem. And the only way to really solve the problem is fixing cross-site scripting combined with architectural measures like a BFF and so on and so on. And if you're interested to learn how to fix cross-site scripting in applications and how to deploy CSP and a bit more depth on the BFF, I'm running a Angular security course or just a, well, it's Angular oriented, but it's also relevant for all kinds of other frameworks. I'm running that one in December. So if you want to join that, be my guest and check it out. You can find the link here. You can find my website, prigmaticwebscruiter.com, find a lot of information there as well. And if you have questions about this, I think we have a couple of minutes to dive into those. And otherwise, well, watch, if there's a recording, watch recording, you can find other talks. All right, go ahead. Hey, thanks, thanks, Phillip, for the insight. So I think it never ages in respect of the, you know, how old the cross-site scripting is. I started where I was like 15 years back. We were doing the testing for cross-site scripting, but I can still see the still fresh and new attacking the applications irrespective of whatever the landscape we are operating on. Thank you so much for your insights. And we don't have any questions in the live chat, but some questions are asked relevant to the Words 2.0 vulnerabilities in the field when I go to the conferences and talk to the developers. So I'm going to take this opportunity to ask the question to you. The first one as a developer, I expect to have like, I make, you know, effort to not expose my app to vulnerabilities. What is the measure that I can test? Like, if there are any test frameworks that I can pass through to make sure, you know, my app is immune to all those, especially the vulnerability. Yeah, I wish I had a really easy and positive answer. Like, oh yeah, just run this and you're done. Unfortunately, it's not that easy. Otherwise, I guess the problem would have been solved for a long time already. So the longer answer then, there are some automated tests that you can run. There are some scanning tools and so on that have some models that says in finding certain types of vulnerabilities for certain types of problems. So that's definitely something you could do. However, the absence of any findings doesn't really tell you much. It says like, hey, at least you reach a certain level where you can't automatically find issues. But it doesn't really mean that there aren't issues. It's just that they might be a little bit more advanced than what a tool can find. That's the scanning part. Things that are making headways these days is a concept called guardrails for developers. And the concept of that, that idea is that instead of trying to find vulnerabilities, what if we just try to guide developers in following secure coding guidelines all the time instead of just where it might be vulnerable and just do it all the time and try to avoid known dangerous patterns? Like this pattern can lead to that vulnerability. So why don't we try to avoid it altogether and then the problem kind of goes away as well. And that in that area tools like super fast scanning tools like SEMGRAP or something similar is definitely very useful to find these dangerous patterns and suggest better and more secure patterns instead. So it's a combination of things basically. I see one question from the EW live chat. Isn't that basically the concept of authorization code flow and cookie based session I've used like 15 years ago when building an app with example PHP. Tokens are only known to the back end. Yes. Conceptually, you're absolutely right. So the type of client we use in a BFF would be the exact same type of client you would use in a PHP app. The only difference is that with the PHP app from 15 years ago you would create your views on the server and you would send HTML back to the browser and modern architectures today prefer to use JavaScript based applications like an Angular app or React app, a few app or whatever and that one runs in the browser. So back then you had your PHP app which is like this one blob that does everything and what we're doing today is we're basically pulling them apart where you get your BFF part here and your frontend part here but in essence there are one whole application it's just with a boundary in between one component running in the browser and one component running on the server but yeah, the concept is absolutely the same. You're right. Thank you. Thank you Andrea for the question. Thank you Philip for taking this time. I know you're so busy. This is the last minute I reached out to you and then you kindly accepted our invitation to present this. So for those of you who are joining us Philip is having a decade of experience and security. So do reach out to him if you have any questions on LinkedIn and other socials. Well, this stream is going to stream and record it so you can watch it later. Thank you Philip. Thank you for joining. You're very welcome. Thanks for having me and thanks for organizing this awesome meetup. You've been going for a while so it's absolutely awesome to be here. See. So I'm going to turn to the next part of the meetup which we introduced in the last three sessions which is asking our IT experts. There are some questions that are lingering in the developer's mind. Am I doing the right thing? What is this? So many terminologies. Can someone give more clarity on that? So to answer this, we created this session where we pick up on some topics which are confusing to the developers and to make a better decision and give more clarity on it. So we bring our in-house IT expert John Lim to answer some of the IT experts questions. So I'm going to introduce John and hey John, how are you doing? Hey Pradeepa, glad to be here. Hi everyone. I'm going to ask you to introduce yourself. Yeah, sure. So my name is John Lim. I'm a Senior Solutions Engineer at Okta and I've had over probably 16 years as a developer experience before joining Okta. And my role at Okta is actually pretty exciting. It's to help customers be successful when they embark on their identity journeys. So really looking forward to help walk with all of you here on this journey some day as well. Thank you John. John is my go-to engineer for all the NT questions. So I know he is like spending a lot of time solving the NT problems out there for different industries. So I'm going to repeat the same question which I asked Phillip. What's your hobby and what's the identity problem out there in the world? So I think it's basically trying to apart from trying to do the best there in the world is reliving my childhood through them actually. So for example my recent childhood experience where I felt to grow sea monkeys when I was young I bought my son one so I could like I said relive my childhood through them so that's what's happening. So this time I see monkeys grew so that's good but there's left one only so I'm not sure if it's a success or not. Maybe I'll try the next one with my grand children or something. That was a nice okay so I'm going to start the session so I have some questions that are asked out in the field when we go to the conferences and some questions that are already asked in the social so I'll start with the first one there are though we are talking about a lot of protocols that is one which is SAML can you explain what is SAML can you just give an overview of in layman terms how I can understand better SAML. Right so like Philippe mentioned he talked about OpenERD Connect SAML is similar in the sense that it is an authentication protocol right and as with all protocols you can think of them having their own rules governing how data has exchanged the data format the security around it as well so in a nutshell SAML is just an authentication protocol and the way that I usually describe to people is that they are always like if you think about traditional applications or if you're building an application today likely you start off with just your application handling that authentication as well when you're just logging in so when you think about SAML and trying to explain to people like pull apart and say okay now you've got an application but there's a separate entity called an identity provider here and so what happens is that SAML governs between this application talking to the identity provider here where the identity provider is really storing all the user credentials in the authentication so how can you now pass information back and forth to know that the user has successfully logged in that's what SAML does it governs the protocol between the two applications so the user can securely log in now to your question how can I play it back a little bit so that layman terms there the example we usually cite that is that if you're logging the app you have an identity provider so kind of assume that identity provider is like a bouncer at a club so when a user tries to log in it goes to the bouncer the bouncer will check your credentials and if let's say you're above 18 years old for example it gives you a special digital ticket now you can this digital ticket in SAML is called a SAML assertion so it's like a note from the bouncer saying hey this person is okay now you can take this ticket go back to the application there present it at the entrance and the application will check it and then if it's okay the bouncer trusts you come on in and you've granted access without the need to actually re-enter your username and password so in simple terms SAML is like a digital ticket that vouchers for you unless you move between different online places without the need to repeatedly prove who you are and so it's a way for websites and services to kind of trust each other's verification of your identity making your online experience that much smoother and that much more secure okay so this sounds somewhat similar to so SAML is nothing but an authentication protocol is that what you mean like proving my presence my identity so essentially you know proving who you say you are obviously in a secure way and it's designed primarily for web based app applications okay so in one of her previous sessions we talked about OpenID Connect which is also an authentication protocol so how is SAML different from OpenID protocol because this sounds so similar so as a developer what should I look forward look to you know use between these two so one of the biggest difference I'll go to the history a little bit but if you've got time but essentially SAML is that it uses SAML to pass information back and forth and OpenID Connect uses the concept of JSON web tokens for example now usually when I first started I was really confused as well and the simple way that I kind of connect the dots there the difference between them is largely SAML was I think if I'm not wrong like 2001-2002 that's when it was standardized or maybe standard and during that time it was mainly for web applications and if we look at OpenID Connect it was really around 2013 or 2012 somewhere around there and it was really designed like I said SAML was really designed for traditional web applications so they were really suited for modern web and mobile applications and when this event of all these single-page mobile applications that's when kind of how OAuth was being conceived and it solves the use cases centered around that so the I guess in a nutshell SAML continues to be widely used that's because since 2001 really in the enterprise environment that's why you still see it but OpenID Connect has become kind of the go-to standard for modern applications particularly those leveraging like APIs and adhering to OAuth for secure access so you know there is at the end of the day it's kind of the same thing but it really solves different use cases the tech was different then and so that's why you have kind of two there because they're all in the market still so is it safe to say that OpenID Connect is the super set of SAML or it has a it's two different entities to solve two different problems I would say they're both different authentication authorization protocols right so if I'm not sure if it's good analogy but you have a USB and you might have your way back then the serial communications it's still communicating between devices in the laptop but they do it differently in four different use cases oftentimes I get asked this question like do you support SAML because I see all the modern antiproviders they still support SAML so what I'm asking is like would there be any use case or would there be any scenario where people who are currently using SAML would have to migrate to OpenID Connect for any reason or they can still say the same and then use the exchange whatever they're doing are they missing something with OpenID Connect well I guess can answer the question we can have to look at the industry and like I said SAML was way in 2001 and so many enterprise applications today still use the SAML for several reasons right even though there's OpenID Connect so some of it may be that all the years there companies have invested in ecosystems that use the SAML so they might not have so legacy like industry that's still using it so there's still a market for it and so that's why SAML is still prevalent and relevant today and SAML itself is also established standard that's why the adopted has a mature ecosystem and so can answer your question I guess like are they missing anything I guess all of them where the industry now is heading towards but because given the legacy and the white ecosystem support it's relevant you'll probably see it there what you might miss out in terms of developing applications using one over the other like I said it would be just a use cases where OOS really designed all those modernization which makes things a lot easier for you to do okay thank you I think that provides more clarity but when you are explaining something about SAML this is a common confusion here among the developers this sounds more like SSO so could you explain more about that so SAML is like you prove yourself you have some ticket you go like you mentioned to the bouncer you prove you are and then you go but doesn't that sound something similar to SSO could you please explain a bit more about that yeah so I guess the easiest way to kind of or rather I kind of understand where it's coming from is because it's a close association between the two concepts right SAML and single sign on like I said SAML is a protocol right it's just handled by how they really an application in the identity provider kind of governing how it communicates and how a user authenticates single sign on again might be an overloaded term but single sign on essentially just means I sign in once to my identity provider I don't have to sign in again to use multiple applications that's kind of like in the if you google apps like we kind of used to like a consumer based as an employee typically I login into you know login once or to my when I start my day I login once and I get access to all my company's applications right so now in that context right like I mentioned enterprise me when it comes to enterprise right there's a lot of SAML applications still in use so when you do that single sign on typically you know in the enterprise space is using the SAML protocol right so they're kind of like a result in like misunderstanding or confusion that SAML is single sign on and whereas it's just essentially just an authentication protocol and it has the ability to do single sign using that has the ability to do single sign on because you really only login once and the identity provider has the information for the other applications when you try to login again and if you sign it not then you don't have to sign it again does that make sense yeah it makes sense so it's just SAML is the enabler for SSO is that right correct yes you're right oh yeah so I know we are out of time but I just wanted to ask the final question that I have which is also related to the SAML SSO Federation Federation also sounds similar to all this stuff so I want to put this on the table and then you know explain more about this in the context of you know SAML and SSO what does what does Federation mean does it mean the same thing it's a different terminology or it has its own perks yeah so the way I view this is we talked about single sign on right and single sign on is really a user signing in once and getting access to many applications with Federation if you kind of flip it around like if you're is it kind of in the same context there right where you have you create a trusted connection between different organizations so if you flip it around like if you develop a SaaS app right and you want multiple organizations to support multiple organizations being able to use your application through single sign on kind of from that perspective as that vendor and you know I use a term Federation because I allow multiple different kind of organizations to login into my application right so single sign on it's like the end user in the company that I just signed in once to get access to the applications Federation is really coming from the other side of the vendor if you want I do Federation we allow multiple different organizations the ability to kind of a single sign on into my application so again you know gets confusing there a little bit okay so just that the Federation makes sense that you know when you look at the organization perspective you're letting integration of different apps is that what you mean the Federation so so single sign on a Federation often going hand in hand right so single sign on simplifies the user experience for a single organization while Federation extends this convenience across different organizations in domain okay thank you for clarifying all the confusing terms thank you for taking your time and then you know answering all these questions I hope our viewers caught you know get the clarity about what all these things I have one question from what is the difference between GIT provisioning and SCIM provisioning which provisioning technique needs to be used in which scenario like okay so maybe just quick one JIT provisioning just means just in time provisioning and scheme is really a protocol so that you know different applications can come back to your identity provider kind of to do user updates deletion cleanups etc the difference is there right the difference is that if you're developing an application and you have for example Federation enable which means that an organization can just single sign on it to your application well what you don't want to do or typically is that well I have to import all my users in the organization into my kind of my application before they can start using so really in that case just in time provisioning just say well I just login with my employee credentials the employee gets provisioned within the app kind of just in time provisioning every scheme comes well what happens if you know the user leaves I want to deprovision him most of the time applications probably wouldn't matter because that user can no longer login but there might be situations where you want to inform back to the you know the identity provider to do cleanups etc so that's the scheme really allows a mechanism so which technique to be used in which scenario do you need to talk back to your identity provider do you kind of synchronization happening then you probably need scheme else if you can just use just in time provisioning thank you thank you Jonathan Mahindra and I think hope this answers your question let me know if you still have questions so we can answer it so thank you John thank you for taking the time and then see you again maybe in another our expert series thank you play to play to help good night everyone and we're going to reach the end of the meetup so I just wanted a final shout out thank you everyone for joining but it would really be helpful that if you sign up for a newsletter you can get updated on what's happening in the devil side of odd zero by doctor you will get to know what like this meetup is happening and we have similar events happening in all around the world so you may catch up with one of our advocates and ask your questions in another conferences or meetups so do sign up for a newsletter and as I mentioned in the start of the meetup you're looking for speakers so if you're someone who has experience in using Indian security in your own project or you know in your work and if you'd like to share please submit your pack title or abstract I'll get in touch with you and then you can do a demo or give a talk about your experience last but not the least this is something that will keep us growing we can restructure or you know revisit how we are presenting so please give a feedback about the streaming on the meetup talk if you want to see more about specific talks you can just leave in the survey as well so please provide us a feedback last but not the least and thank you so much for delivering the stock and joining our Indian expert series and thank you all for joining online and asking an amazing question so if you have questions if you wanted to address us please leave it in the chat we will try to answer it in our next meetup also our next meetup would also be online it's December it's a festive season so planning to do it online as well December 20 is the date which we have in mind but we'll confirm it we'll publish in our meetup groups and also stream in youtube please do subscribe to our youtube channel and then subscribe to the notification so you will get notified thank you all for joining and see you again in another meetup