From b95fa0f5aa663a91ab06193f5c9ae14eb654de7f Mon Sep 17 00:00:00 2001
From: Adam Abdulraheem <61481273+adams9777@users.noreply.github.com>
Date: Tue, 17 Dec 2024 01:50:15 +0100
Subject: [PATCH] Create Hacking OAuth An Attackers View of Your OAuth
 Flows.transcript.md

---
 ...ers View of Your OAuth Flows.transcript.md | 76 +++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 content/sessions/2024/mini-summits/Dec/DevSecOps/Hacking OAuth An Attackers View of Your OAuth Flows.transcript.md

diff --git a/content/sessions/2024/mini-summits/Dec/DevSecOps/Hacking OAuth An Attackers View of Your OAuth Flows.transcript.md b/content/sessions/2024/mini-summits/Dec/DevSecOps/Hacking OAuth An Attackers View of Your OAuth Flows.transcript.md
new file mode 100644
index 00000000000..8da5ef00b7a
--- /dev/null
+++ b/content/sessions/2024/mini-summits/Dec/DevSecOps/Hacking OAuth An Attackers View of Your OAuth Flows.transcript.md	
@@ -0,0 +1,76 @@
+---
+title        : "Hacking OAuth: An Attacker's View of Your OAuth Flows"
+track        : DevSecOps
+project      : DevSecOps
+type         : working-session
+event        : mini-summit
+when_year    : 2024
+when_month   : Dec
+when_day     : Tue
+youtube_link : https://youtu.be/IedhG7EsgPk
+---
+
00:03
Dinis Cruz
Hi, welcome to this Open Security summit session in December 2024 and we're going to have a really cool session by shishan on hacking OAuth. Right. And attack a few of your OAuth flows. And this is kind of really critical because in a way OAuth is now just about everywhere. A lot of Companies insights have OAuth integrations but I think it's really key that we understand these issues and how to address it. So over to you and thanks for presenting at the Open Security Summit. 
+
00:30
Sheshananda Reddy Kandula
Yeah, yeah, thank you. Thanks for inviting me to give a talk at least. So thanks for that and giving this wonderful opportunity. Yeah I think you can see the screen and you can hear my audio clearly if you have any issues in between, you know. Okay. So this is pretty much similar what I have given in besides near in Delaware and so there are slight changes. Those are like into the maybe 25 minutes talk so I just expand a little bit more because we have like around like 45 to one hour today. So yeah without further ado let's get started. So yeah the my topic for today is like hacking the word. 
+
01:16
Sheshananda Reddy Kandula
So yeah what is like pretty big protocol at least I don't think so I can teach you in 45 minutes or one hour at least we'll see like how typical worth works and how we can look into the wath flows and how an attacker can try to tweak around your flows and try to find the vulnerabilities like maybe if it is a bug bounty guy so they will try to reach out to us and we can work on the remediation but if it is going to the attacker or hacker that's too danger. So that's why it's better to understand our overall workflows and try to find the issues. So myself, yeah myself like Shashi so like I'm in like security industry like almost 15 years. 
+
02:05
Sheshananda Reddy Kandula
Mostly I spend my time on application security only so like web applications, mobile and sometimes network and here and there but most of the times I spend my time on appsec. So yeah I'm also part of the ISC to NJ chapter here in US maybe yeah it is like mostly we have the online events so we used to meet sometimes in person to exchange ideas and meet the wonderful people. So that's another one. So when it comes to the agenda so today first we'll try to understand like what is the main reason what came into existence or like what is the need of it. Before that we'll try to understand what is authentication and what is authorization? 
+
02:50
Sheshananda Reddy Kandula
So then once we understood that then we'll try to understand how worth come into the picture and how it solves the issues too related to the authorization. So then we'll see like typical fee flows. How exactly the flow what I was talking earlier. Also then there is a playground oauth playground which we can try to see. Typically most of the organizations will have the workflows but we don't want to play around in the production environment. So we have kind of a playground. We'll try to see how typical request and responses will be there. Then we'll go into the common what vulnerable dislike, what kind of issues will arise during these workflows. And maybe I have a couple of blog posts so I thought of going through that and there is a demo as well for the in the ports figure academy. 
+
03:48
Sheshananda Reddy Kandula
I don't think so I can go through that based on the time we can plan accordingly and maybe at the end we'll see like what are the mitigations or like what are the security controls we need to follow to protect the workflows. Okay, without further ado let's see like first of all as I mentioned like let's see like what is authentication and what authorization. Because without that, without understanding the main difference between these two, it's a little bit complicated to understand what is auth and what so authentication usually like what will like if you see like authentication it's not only like for the regular username and password. So it's like username and password for the like for a human or like for the person to log into the system. 
+
04:28
Sheshananda Reddy Kandula
But sometimes authentication is required for the processes, even for the server to server or service to service communication during that time as well. We need the authentication because we can't allow any system to access our resources. So there we need kind of a different kind of authentication. Maybe it may be like regular username and password or like maybe any bearer token or like if you see in SSH we have seen like a public key certificate as well to provide the authentication. So that's kind of like authentication to prove yourself who you are saying like suppose it's kind of like the overall like the process of verifying the identity of a user process or device or whatever. Like we will try to see like how authentication will work and not how. So that's the mind and then when it comes to the authorization. 
+
05:19
Sheshananda Reddy Kandula
So okay, we have provided authentication. So authentication we understood like we are trying to find it out whatever user or like process or a device, whatever it is Claiming we are validating using the authentication processes. Maybe regular username and password. If it is validated and if it is correct only we'll. We'll push them into the like we'll allow them into the access log into our website and like our services. But what authorization? What is authorization role here? Because suppose you have logged into one web application. It's not like you can access any resources or like anything on that web server like web application. Because if. Suppose if you see like if you logged into the Facebook it's not like you can go on to the any Facebook server and you can modify or you can delete anything. It's not like that. 
+
06:08
Sheshananda Reddy Kandula
So we have to be properly authorized like properly do the kind of a validations in the backend to see like whether the logged in resource can have the access to the to do the whatever the activities whatever the actions they want to perform. So that's kind of like authorization. Suppose you have SSH into the machine by using kind of a public key or like maybe any certificate. So once you SSH obviously like you will have a kind of a role. You can't do the root privileges activity. So because there is a kind of a restrictions there. So this is called authorization. So in authorization check usually like we'll validate like whether the. 
+
06:50
Sheshananda Reddy Kandula
The person who here is climbing he is authenticated but whether he can perform the actions whatever he is trying to do or whatever he's intended to do that is called a authorization. So if you can understand these two in good. So it's easy to understand the OAuth protocol as well. So that's kind of like high level. But if you want to a little bit understand more. Wikipedia has pretty good details, pretty good definitions for the authentication authorization. So those are the details. Okay so we understood like authentication authorization. So okay, what is what. So usually in short we'll call it as OAuth. But OAuth is kind of like open authorization protocol as you see. Like it is a protocol because it's a protocol for open authorization. 
+
07:40
Sheshananda Reddy Kandula
So authorization like if you want to perform any authorization obviously like maybe like in 2005 or 2006 there was no specific protocols or rules to perform it. So earlier people whatever they wanted in a way they were. They were trying to do the things and there were a lot of mistakes happen and several security vulnerabilities also came up. So that's the reason everyone thought like it's better to have a protocol so that then it came into the existence. So okay, open authorization protocol. Okay what it will do. So usually like what exactly OAuth will provide kind of a delegated authorization. So the main reason for highlighting that in bold is like what is kind of a delegating. So we are delegating the authorization. 
+
08:27
Sheshananda Reddy Kandula
So suppose I have some resources in some server, like maybe if it is a Google Drive or like maybe into the Facebook photos or anything. I have few resources. But if some other third party app or some other app wants to access those resources, what we are trying to do is like we are delegating the authorization. So I have the authorization to access the resources, whatever there on the server. But what I'm doing is here is like I am delegating the authorization to the third party website. So here we are giving the authorization to the third party website to go and get the whatever we approve data. So that is kind of a what is delegated authorization. So in short, OAuth will provide delegated authorization. 
+
09:13
Sheshananda Reddy Kandula
So like there are like a lot of companies already implemented the OAuth to give the access to the like maybe any third party application or like their customers or whatever. But we'll see like how exactly they do and what are the different rfc. So obviously if it is a protocol, there are a lot of rfcs will be there. If you see in this image, there are a bunch, okay, among those is like at least initial days they have different flows like implicit and I think this is a password. But because of security best control, like best practices are security, best current practices they were not like these two are deprecated on top of this. The main thing what happened was like once usually like at least they started with the web applications. So but like it is like around 2005 or 2006, right? 
+
10:08
Sheshananda Reddy Kandula
So slowly the mobile applications came into exist in the 2010s at some time. And even we like recently we saw the Apple TV not recently, five years back and all Apple TV and where the devices at least those kind of stuff don't have any browsers. Like browserless devices came into the existence and we want to implement that there as well. So such kind of requirements came into the picture and there are like some tweaks and like maybe kind of a new rules or like new protocol. RFCs come for those as well. So if you see here SPA is like single page applications. Because single page applications like with the Angular JS or like React, sometimes it will be run mostly into the browser. So because of that there are a lot of changes happened. But let's go through those as well. 
+
11:02
Sheshananda Reddy Kandula
Okay, so before going into Much detail into the OAuth. Let's see, like why do we need to share the resources securely? Yeah, if you see like as I mentioned in the earlier, so we want to share kind of our photos which are there in G drive or like Facebook or some other Instagram application. So this is kind of an example not only if you want to share any documents, PDFs or whatever, it will be there in one server and if you want to share it to the other server without creating like how like that is the main reason. 
+
11:40
Sheshananda Reddy Kandula
Suppose if you see an example, like you have a device, like you have your own mobile device and you have few images or files and if you want to share Those with the WhatsApp or images, you can just click on it and share it to the WhatsApp images like iMessages. But if the files are there in some third party server, so what exactly we have to download it and share it again back to the whatever the services we want to share it. But that's kind of like not much user convenience for better user experience purposes we want to share it without much user traction or user interaction we want to do that. So that's the main reason why exactly we need to share the resources. And before going to that let's select why do we need to share the resources. 
+
12:32
Sheshananda Reddy Kandula
First of all, if you forget about the word securely, so why do we need to share the resources? Because if you see here, this is one example kind of like registration page. Because in a day like if you see in your typical mobile, you have hundreds of apps. Maybe if you see like if you go to the Internet you will see hundreds of applications asking for registration. So like usually what users will do, like no, I don't want to enter my first name, last email ID and prefer languages or whatever, I don't want to enter all the time. Maybe if some users are okay, but most of the users will feel like okay, I don't want to enter that. So what they can do is like they can go with the Google or like Microsoft or Apple. 
+
13:12
Sheshananda Reddy Kandula
This is for chargebit I just gave an example. So they can use this login and what they can do like they can share their email address like first name, last name and whatever the required information to the Charge GPT Here it's kind of like convenience, like it's kind of like usability purposes. We are using that. So here what exactly we are doing is like whenever we click on it and we allow the char GP to access the first name, last name and email id. So then we are going to like the Google or whatever the what server is going to share the details back to the charge GPT or whatever. So this is also kind of a. An example where what is going to be helpful here? 
+
13:56
Sheshananda Reddy Kandula
So okay, the main reason is like it's kind of like without losing the user information or like without compromising data without. Without much user traction or like friction we try to use the word. Okay, that's the main. This is just kind of example. 
+
14:14
Dinis Cruz
A quick comment here. I think one of the advantages is that from a user point of view at least it doesn't have a lot of passwords, right? Yes, you have one OAuth that you need to protect, but it does bring quite a lot of security, right? The fact that you don't have user accounts and passwords sprinkled throughout dozens of websites. 
+
14:32
Sheshananda Reddy Kandula
Right. 
+
14:33
Dinis Cruz
And in a way they only have access to smaller amounts of data from you. 
+
14:37
Sheshananda Reddy Kandula
Yeah, yeah. Obviously if you ask the user to create an account every time they will use the same email ID and same password everywhere. 
+
14:43
Dinis Cruz
Exactly. 
+
14:44
Sheshananda Reddy Kandula
That's it, you are done. So if you get one like account, like one credential so you can do like reuse the obviously like if you give the chance to the user obviously, like that's the human tendency or like human mentality to use the same password at least like if you feel like okay, this is not a banking website, why can't you use the same. So that's the other tendency to user to use it. So that's also another reason to use the OAuth. So at least if you can protect you are whatever accounts OAuth accounts in with strong MFA and all those stuff, I think you are good most of the time. So no need to worry about that. So that's also another reason to use the OAuth. So here I have given the only example for the registration. 
+
15:28
Sheshananda Reddy Kandula
But still we can use it for the other purposes as well like file sharing here and there. Okay, so OAuth has solved it. So this image maybe if you are into the worth also you could have seen this image in some few other presentations and a few other areas. So okay, so this is what OAuth has already sharing the information between two servers or like two applications. But what did before OAuth? So if you see here, if you see the help whenever they launch, if they want to find the friends, like suppose you have a few friends or a few contacts in your Gmail. So what this is like around 2005 or before that so what exactly help is asking is like enter your email address, Gmail email address and password. 
+
16:16
Sheshananda Reddy Kandula
I will go to your Gmail account by logging in there and get your contacts. So if this is the same happening in 2024 or 25, most of the people may not give it but still few people have a tendency to give their Gmail ID and password. So that's not a secure way of sharing your contacts. Right? So because here you want to share only the contact from your Gmail but if you give your user like email address and password to the L parasam other registration website what it will not only getting your contacts, they can see your personal emails. Like maybe if you are storing in payslips or whatever is there in Gmail they can access that we can't trust the any third party website as well. 
+
16:57
Sheshananda Reddy Kandula
Maybe they may be not doing intentionally but if their website is compromised or something happened, maybe attackers can take over that they can use your Gmail ID for whatever purposes. So to avoid these kind of issues, these kind of issues will be resolved using the wor. So let's see like how exactly worth flows work. Okay, earlier if you see in the previous screenshot we were sharing the username and password with some random website. But in As I mentioned OAuth solves it. So how. How is OAuth solving that? So let's see like in step by step. So you suppose you have an account with Google Facebook like maybe even any lot of SaaS applications also have the OAuth imp. That's what you trust it. So you feel like Google and Facebook. 
+
17:45
Sheshananda Reddy Kandula
Maybe some people has different opinions as well, but at least we can assume like these websites protect our data. So suppose you have email ID and password. Obviously they use kind of a secure mechanism to store your password like salted hash or like bcrypt or whatever algorithms they're protecting your data so you trust them. So you have an account with them. So suppose some son random registration page come up and you need to sign up. So what exactly we will do here? And it will present with the OAUTH links. One of the options either you can enter with email ID and go through the regular registration step or else you can just use the OAuth. 
+
18:26
Sheshananda Reddy Kandula
So once what exactly will happen is like once you logged into your Google or Facebook or Apple account and you agree to share the data back to the new website, Then only the OAuth server shares the data here. If you see like whenever you maybe in the UI we'll see like we Are logging into the Google or Facebook. But what we are entering the email ID and password. Those are going to the our trusted website only it's not going to the some new website. And from there they are going to get the data. So here we are logging there and we are sharing back the data. So that's like kind of a steps but usually like if you see in better GUI so it's easy to understand. So what will happen in like how like what will happen in typical workflow. 
+
19:17
Sheshananda Reddy Kandula
Like suppose here the new web application so the new web app or like the new the third party app. At least we can call it the third party app. What it will do like it will go to the app B here if you can see like app B as like Google, Facebook or whatever. So what they'll do like they will come configure a they will configure their website in the wor server of Google or Facebook. So once they configure it they will get a client id. So client ID and they get the client secret as well. So this third party app will store this client ID and client secret in its own server and protect it based on like how that we can see that later. 
+
19:57
Sheshananda Reddy Kandula
So by using this client ID whenever the user is trying to register it whenever a user wants to share the data. So it use this client ID and it asks the Facebook or whatever the OAuth server after the username and password validation it will ask for the granting the permission once the user clicks on the yes. So it will get back this third party application will get a authorization code by using that authorization code in the back end. So it will get a access token. By using that access token it will go back to the resource server and it will get the required information like that we'll see like how exactly will happen in little bit more diagrammatic way or like gua or like a flow diagram. So that's easy to understand if you are looking into the OAuth first time. 
+
20:52
Sheshananda Reddy Kandula
But if you are already known, this may be like kind of a recollection of your memory. So so if you select some user agent or like maybe kind of this is a third party app which you want to which you see typical OAuth flow. So suppose you went to some chart GPT website and once you open the like once you click down the Google or Facebook OAuth flow it will start the OAuth process and it will redirect back to like this will happen in the backend. Okay, the user is asking for that. So it will add that client ID and all the client ID stuff and it will redirect back to the authorization server. Here this is the authorization where is our trusted server. So sometimes what will happen Authorization server and resource servers may be on the same server. 
+
21:40
Sheshananda Reddy Kandula
But for better segregation of duties and because of all those security concerns, we can divide into two parts like authorization server. Usually authorization server will validate username and password and generate a authorization code and validate it once it get back in the letter. So okay, so one that present the authorization ui. So it will go back to the user will enter its user and will enter his or her credentials. And then whether it's based on that user, whether he wants to authorize this or deny dms, it will end here. But if he authorize so it will go back to the authorization server. Authorization server will generate authorization code, it will go back to the browser. So since we have sent one kind of a redirect URI here, it will redirect back to the server as well. 
+
22:31
Sheshananda Reddy Kandula
That we'll see like how that exact URL looks like in the next slide. So once that redirection is come back to the web server by using that authorization code. If you see here from here nothing much happening that is visible to the user here because it's mostly it's happening in the server to server or like in the backend. So in the back end it will present the authorization code back to the authorization server. So as I mentioned earlier, so authorization server will validate it whether it's already used, whether this client ID and this authorization code is given to the respective app or not. And those kind of authorization checks will happen at the authorization server. If it is valid, then it will generate a access token and it is give it back to the web server. 
+
23:15
Sheshananda Reddy Kandula
So then by using this access token it is a little better token or durability token we'll call it. So by using the that the web server will get the. Usually so far we are talking like username like maybe email id, first name, last name, prefer language or something. So those kind of data we will get back in the response. Okay, that's the typical flow how it like so like suppose after some time, like maybe after like an hour or so, what will happen if we want to like not the registration maybe for the file access or for other purposes. If that access token got expired usually like access token will be like based on the expiry date it will expire. 
+
24:04
Sheshananda Reddy Kandula
So after that what the server can do is like by using the refresh token it will get one more access token get the to access the resources again. So this is also kind of a regular flow. So okay, we have seen several terminology here. We'll try to refresh or like recollect what we have observed so far in this. Like resource owner. So like usually resource owner is. It's us like user or whoever the information is storing on the different places. So that's the user like resource owner. So what is a resource server? So resource server is like if you see in the previous screen. So that's where exactly the user details are storing. So that's the resource server Authorization server is like which like handles the interaction validations, authentication authorization stuff will be happening at the authorization what is the client. 
+
24:59
Sheshananda Reddy Kandula
So here the client is like kind of like third party app which one which it's registered and which it wants to get the like whatever the resources from the authorization server or resource server. So access token or refresh option. These are kind of like typical tokens which we can use it to get back the resources. Authorization code it is authorization code whenever a user agree to share it. So it is kind of intermediated token which we can use it to the get the tokens like access token under. So as I mentioned. So this is the typical oauth request how it looks like. So usually like maybe authorization server authorize or like OAuth whatever they kept it in the slash. And also response type is code. 
+
25:45
Sheshananda Reddy Kandula
This is the client id the main reason for the client edit just to differentiate between the two different third party apps. And there is a redirect URI as well. So in the previous flow we have seen like in by using this redirect URI only we will share back the authorization code whatever we got it from the authorization server. So what is the scope also pretty much important we don't want to give the overly scope because if it is asked for the only photos we have to share that only. So we don't want to share any another information. So based on that like maybe if it is a first name last name. Okay, only stick to that. So by using the authorization code, if someone is asking for more detail so that scope more scope. So we obviously authorization server has to decline it. 
+
26:32
Sheshananda Reddy Kandula
The next one is the state parameter. The state parameter also pretty much important because it prevents from the CSRF attacks which may happen on any website or like if you are not validating the flow properly that we'll see in the next few slides. So so far we have seen maybe at least that's kind of like typical Authorization code flow. So like here if you see in the involvement so here user is there and one third party app, browser and authorization server, resource server. But if you see in the first few slides when we talk about RFCs there are different application types out there. Like single page applications, mobile applications and even kind of like Apple TV other kind of applications where we don't have much user interaction is possible. Or like maybe there are no browsers also on few devices. 
+
27:25
Sheshananda Reddy Kandula
So for such kind of flows or for such kind of requirements what has implemented different flows? Like we'll see like what exactly that. So authorization flow, client credentials flow with pixie. This is also kind of like important one or at least which will provide better security to our flow. Like this one is this was there in earlier and it got deprecated. Nowadays there no one is suggested to I recommend to use it. Okay, let's see. Like if you see all those flows this is the diagram or like the flow diagram which we can come across. But this is like. Looks like very complicated. But because if you see like this is like mobile app or like JavaScript app. So that is kind of a public and like confidential means like it's mostly like into the back end. So so public and there is implicit. 
+
28:20
Sheshananda Reddy Kandula
I think nowadays we are not using the implicit and explicit consent. Also there the explicit consent is like as I mentioned like if it is browser based app we can ask the user to click on the consent. But if it is kind of a where there is no user interaction is there not there? So we can it should be like implicit consent. And based on that. So let's see like how exactly this is kind of a. As a reference I have kept it for to explain different client types and different workflows. But let's see. So in the next slide I thought of going through kind of a word playground. So this I'll just quickly go through. So suppose this I have already used it. So open. I'll open it in the incognito mode. So what will happen in the typical authorization code? 
+
29:17
Sheshananda Reddy Kandula
So as I mentioned in the first the third part application has to register a client. So what it will do like whenever you do the client registration. So the third party app will come to the Google or Facebook and they will try to register it. So during the registration we'll get a client ID and client secret. So if we like we means like the third party app. So this should be use it to exchange the data later. So let's keep this one in another screen or another tab. So basic authorization flow. So before authorization begins. So it first generates a random string to use for the state parameter. As I mentioned earlier, state parameter is important because it will protect against the CSRF attacks Because we need to make sure who started it and who is ending the flow. 
+
30:08
Sheshananda Reddy Kandula
Because in between if someone has take over your oauth flow and if. If you're not able to validate it that properly there is a kind of like CSR of attack. So your account may be linked to some other. Let's see here. Try to log in. Yeah, if you have any questions in between, let me. Yeah, would like to access our photo. So what exactly we do like we'll click on up. If you see here response code is code client ID so react URL it will go back to the oauth playground, all the stuff. Okay, so we have approved it. So if you see that state parameter and it is the same whatever we have done earlier. So if it is matches only the authorization server like our third party application will continue it. So exchange authorization code here. 
+
31:08
Sheshananda Reddy Kandula
So if you see here, this is the code. We got it. Let's go and exchange it. And these are the access token. We got it. This is kind of a simple example at least like because everything has developed already so it's simple. But in the back end it may require several validations, all those stuff. So this is one flow and we have several flows as well. So whenever you get a chance, if you want you can play around with that. And let's go back to our flow. So we have like when we see in the playground. So this is a typical auth request we have seen. So if you see closely here we can at least guess like we can predict kind of a attacks here. Like if you see here in the redirect URI whenever we are doing kind of a redirections. 
+
32:09
Sheshananda Reddy Kandula
So what's the main issue with this is because this URL looks like pretty big obviously like. So suppose you have like it's kind of if it is kind of a phishing attack if user got a URL or like kind of a HTML page if he clicks on it looks like a valid only because authorizationserver.com it's google.com or whatever. So it looks like a valid only but in the redirection. So usually I don't know, most of the people may not observe the entire URL. So if you are not validating the redirect URL and if you have any open redirect vulnerabilities then there are chances of your token maybe get late once Your token is leaked so that attacker can use that token and get back your resources. Whatever. We are trying to get the access right. 
+
33:01
Sheshananda Reddy Kandula
So that's my drawback of having a open redirections or like maybe kind of not validating the redirect URI in a proper way. So let's see like few examples which like how that what misconfigurations in the redirect URI can lead. Okay. Okay. So if you see like common what vulnerabilities. So at least we can cut categorize it into the three like actually if you see in the RFCs there is the RFC for security best practices as well. It has like lot like maybe around 10 to 12 categories and trying to explain you how you better protect your workflows and as well. So that's. I kept it as a reference until last. But at least we can categorize into the three major categories at first. The first one as I mentioned in previous slide. So redirect the URIs if you're not validating the redirecting the URI. 
+
34:00
Sheshananda Reddy Kandula
So then there are chances to leaking your code. The one set code is go to the attacker hand so they can directly get the resources as well. So even the authorization grants also like whenever you are granting the operations if you are not validating between one client ID to another client IDL a differentiate between the both there are chances for the account ecosystem Also the weak client authentication. Also this is also pretty much similar to the previous one. So but yeah we have to be careful. Redirect URI misconfiguration so how exactly this redirect URI misconfigurations will happen is like open redirects. Like if you are not validating the redirect URL and you are just sending back. Like suppose if you are given google.com in the redirect if you are sending it. 
+
34:48
Sheshananda Reddy Kandula
So attacker can react to his own server and he can get the authorization code. So some examples is like if you see like some site example.com you have given like kind of a res access and if you are using star and star are there and usually what will happen like this looks like pretty good because we are validating the domain correctly. And but what will happen is like if you are using this kind of validation so what attacker can do is like attacker dot example slash dots. But if you see in the reject so this will also get passed and attacker can get back your authorization code. Also this is also another example Sometimes what attackers can do they can do the Double submit the redirect uri. 
+
35:33
Sheshananda Reddy Kandula
Maybe if you are validating the redirect URI in the first shot it may looks good like let's some site example. But in the second redirect URI he has his own attacker website. So it may go back there and even this the next URL also like kind of example based on the parsers validations. The how the browser is doing that. So what do you call attackers can bypass our redirections validations as well. If there is a good URL validation bypass cheat sheet available in the Burp Suite Aleppo website we can try to use that and play around with that to see like whether someone can bypass our workflows and all. So this is also another one. The next one is. This is kind of like maybe due to this some parser validations. I think this could have fixed it, but it is kind of. 
+
36:27
Sheshananda Reddy Kandula
It serves as a good example for server and browser validations for the parser. So how typically the validation will happen. If you see here in this example first here if you see the parser does not treat forward slash as a path separator while browser does. So if you see here forward slash here in this backend. So parser does not treat this as a path separator but the browser will do this. So here if you use this kind of redirection this looks like a valid only. But when it comes to the browser side it will we are sending the authorization go back to the attacker.com but if when it validated in the back end it looks like a valid. Okay, this is some like Benning.com so it looks like a valid only. 
+
37:17
Sheshananda Reddy Kandula
But the parser misconfigurations or parser validations will allow the attacker to send the token back to the some other attacker website. So if you see this one, this is kind of like different means browser is treating the forward slash in a different way. And parser like the backend parser is treating in different ways. So by using these kind of techniques also attackers can bypass it. These are the two examples I thought of explaining like going through. So if you see like this is maybe a couple of years back, more than a couple of years back what happened Researcher like bug bounty hunter. They have found out a contactor for the Facebook. 
+
38:11
Sheshananda Reddy Kandula
If if you are using a if you are using Gmail or a Google account to log into the Facebook the researcher has found out multiple bugs and he chained into it and found a way to the take over the Gmail account. This is mainly happened if you are using Gmail account to login into the Facebook account. So this is a kind of a good example for how like how multiple bugs can be chained into. So it's kind of a one click account takeover. So this is a good example of that. So what exactly researcher has done is like he performed like logout CSRF then login CSRF then he has used the open redirect to the get the auth token and take over the account. So that's one example. And another example is like even for the in the booking.com as well. 
+
39:15
Sheshananda Reddy Kandula
So here booking.com has doing multiple redirections. During the redirections the redirection validations the account has happened. So that's another example. So authorization grant vulnerabilities. Look how exactly we are granting the vulnerabilities and how we are validating the grants in the backend. That's also important because if you see like as an example during the earlier discussions I have we have discussed like state parameter is important because by using the state parameter we are going to validate whether it is originating from like the entire flow is happening in the proper way or not. Because if state parameter is not validating someone can initiate that and they can if user clicked on it. So they can take over the authorization flow as well. 
+
40:11
Sheshananda Reddy Kandula
So that's also another one and attacking the weak client authentication sometimes what will happen like whenever we give the client ID and client secret back to the third party application or client app. So if they're not storing the secrets in a proper way like if they're leaking this secrets in the source code or somewhere else so there is a chance for the attacks as well. So we can't differentiate because once they lose the client identity so the authorization server will feel like okay, it is coming from the validation user only. So I'll validate app only and we will proceed with that further as a mitigation that we can use the mutual TLS select sign jar tokens to validate it and we can implement proper access control and monitoring what exactly going on. 
+
41:01
Sheshananda Reddy Kandula
So at least the better way is like by using the pixie protocol for your regular authorization code flow that will help to protect the like oauth flows. So these are few best practices at least I can say enforce the strict redirect URI validations because like nowadays if you see like typical oauth flow become like too much complicated because of like several integrations like maybe front end, back end or like mobile applications here and there. So Based off that redirections validation sometimes may be loosened or like maybe not doing properly. So it's better to do the proper redirect validations and strength like strengthen your client authentication. 
+
41:50
Sheshananda Reddy Kandula
So how exactly you are doing the client authentication as well Even robust authorization grant violations like even we need to see like what kind of scopes they're asking are we user agreed to this share the same scope or not. So such kind of violations also we can perform it in the next slide. I think we have the overall RFC for security best practices. What are the different attacks may happen on what and how we can protect our flows. If you see the first one is itself URI validations and even sometimes credentials leakage will happen in the reference headers as well. Even in the browser history and authorization code injection. If someone suppose if user lose the authorization code how we can protect it. So how we are doing that validation. So that's also can be important. 
+
42:44
Sheshananda Reddy Kandula
So these are the best practices and few references and few like the talks which I have helped me to put this one and yeah this is as a reference I just kept it like at the end. So yep, that's it from my side. So any questions so far and stop sharing. Hello. 
+
43:21
Speaker 3
I think Denise has dropped off so I'm here. 
+
43:24
Sheshananda Reddy Kandula
Oh yeah, that's fine. 
+
43:25
Speaker 3
Yeah I think yeah I was going to ask obviously some of the ATTCK vectors are available. How do you spot them? For example, you've got the unvalidated redirection. You know how would you know that your implementation is vulnerable to that? Are there tools that you know team can use to check and validate their implementation? 
+
43:54
Sheshananda Reddy Kandula
Mostly like the tools. This is kind of like a little bit complicated. Right. So all the redirections and also mostly the manual validation should be the good part. Like to see like to play around with the like how the server is responding back to our different react uri. Suppose we are giving like some example com. So suppose they change the little bit here and there. So how exactly we are validating at the back end are we validating properly or not and such kind of things mostly at least like yeah we can play around with the different maybe automation tools but I don't think so they will find it because it's usually the pen tester knowledge how exactly the workflows works and also that will help a lot. 
+
44:45
Speaker 3
Yeah, thank you so much. I'm not sure if Adam is still there. He's still on call. 
+
44:52
Sheshananda Reddy Kandula
Yeah, that's fine. I'm here. Yeah. Thank you so much for the presentation. I actually don't have questions, so if you. If you're done, we can end it. Yep. Thank you. I. I don't think so. I'll keep you like a guest to the sleep. 
+
45:13
Speaker 3
All right?