Hacking OAuth: An Attacker's View of Your OAuth Flows - Sheshananda Reddy Kandula

can speak that much loud if you can't hear maybe you can come little bit far okay thank you thanks everyone for coming for my talk today so it's mostly about the hacking W and like what is the hackers perspective for our W flows before getting started I would like to thank besides Philly uh like organization organizers and as well as volunteers and everyone so why don't we give a a big Applause for them for giving us to give this opportunity for networking and learning something new for today yep thank you yeah there are like around 35 slides I don't know whether I can cover in 25 minutes I I may go a little bit faster

um I'll post the slides later in my LinkedIn or somewhere so you can get through those uh later if you want or else I think recording also in progress so good luck with that so uh it's not working yeah okay let's get started without further Ado so my name is Shand you can see that and uh this is my LinkedIn or whatever if you want you can connect me there and you can ask if you have any questions I have like total 15 years of experience in application security mostly I worked on like web applications mobile apps web apis or like apis or whatever we call and FY client and all those stuff so mostly into the web application part not

into the network other world so yeah I'm I'm part of the isc2 NJ chapter as well anybody is here from isc2 NJ chapter okay yeah that's good so we have a lot of events are going on in NJ chapter if you want yeah we can join and you can have fun so the agenda for today so first we'll try to see like what is authentication and what is authorization then we'll try to see like how what try to provide the solution for that what are the first of all we'll see like what are the challenges we faced before W protocol so then we'll try to learn more about like how the flows works if you

can understand more how the flows works it's easy to try to see like how attackers can try to steal our W tokens or like our w flow whether it's like ours or maybe our companies or like our uh entire the flows like from client to the server how exactly it works so that is this is a typical agenda if I get a chance I will try to see with the uh playground or else like we will jump onto the uh common worth vulnerabilities and at the end we'll try to see like how we can mitigate those as well so so as I mentioned like the first let's see like what is authentication and authorization most of the people has know this like

authentication is like we'll try to see like identify the person by looking his G or like by looking at his whatever the authorization process we do that so by using like username and password usually that's what we do for regular human authentication but for servers we may have like SSH authentication as well we may use public keys and those stuff so but that is kind of a typical authentication to see like whether it's a person or like service or process has access to the uh the server or like the services or not that's kind of like whether he can step into the uh system or not so that is kind of a authentication so when it comes to the

authorization so authorization is like okay you stepped into the network so what kind of resources you can access it so it's not like once you have stepped in it's not like you can go to server and delete whatever you want or like see whatever other people profile so it's not like that so authorization like just to find it out which part you can access that because typically if you log into the any Facebook or Google obviously you can see your own details itself like your own data only so that's validation part we will call it as a authorization so that's a main difference between the authentication and authorization so if you want more details of Wikipedia and

other places we can find more thorough details of like what exactly the authentication and authorization then let's see like what is what so if you see in a simple word like what is like open authorization protocol so whenever like open authorization protocol it's it's kind of like protocol which has developed like last like maybe 10 to 15 years it has continuously uh improved from whatever the stage it was so but if you see what exactly it will provide is like delegated authorization so that's the important word we need to understand like what is mean by delegation like you are going to give permission to the maybe some other service or server or like some other

third party company you are delegating the authorization to uh access your resources like maybe suppose if you have an Instagram or Google or Facebook account where you have your own data so you are the owner of that data but if you want to share that data to the someone else like maybe some other third party website so you are delegating the access to the third party website to get the data from the O provider like maybe whether it's a Google or Facebook we we are doing kind of a delegated authorization we'll try to see like how exactly that works as I mentioned like it's kind of like authorization protocol so obviously protocol means we'll see like a lot of

rfc's like request for comments or like whatever there will be a lot of numbers no need to worry much we'll try to select what kind of rfc's come up and what kind of flows are there how we are trying to protect the uh this delegated authorization so we'll we'll try to see like what slowly like what exactly we are going to do so next is like okay first of all why do we need to share resources securely so because as I mentioned like if you want to share your Instagram photos to some other third party app or like maybe if you want to share your data like maybe it's first name last name your address or email ID

something like that if you want to share with some other app so we need to uh make sure like we are sharing it in a secure manner so that's the reason suppose if you see an example like if you have like some photos on your device and if you are sharing that with the WhatsApp or IM message so that's everything is in your own control because that's your device you can share it with your like wherever you want it you can share it with WhatsApp or you can share it with the iMessages but what happen if it is on the server so because we don't have much control on the server so how exactly we are trying to share it

that's why we are that's where we are trying to understand and that's where we are trying to see the flows then we'll try to uh learn it more so let's see like before going further if you if you remove the word securely there so why why do we need to share the resources first of all so because if you see this is the different sign up pages so whenever I see the some sign up I don't want to write my email ID and I don't want to write my first name and last name so what I'll do like mostly I'll try to use any W like if it is already Google account is there we'll just tap

on it and everything will be do in the back end so our email ID and first name and last name will be shared with the whether it's a chart gbt or Eventbrite or whatever so it will be done in the back end without knowing to us so without knowing to us itself we are trying to share our resources to the some third party this is like maybe it's well known but we are doing for a lot of third party website as well by using the W protocol so that's a kind of example so why exactly we need it for usability purposes or maybe user experience purposes we are trying to share the resources so we are sharing it but how

we can share it securely that's what exactly we are going to see so here I have given only example for username and uh username or first name last name email ID but there are chances to share the files and lot of things as well by using the W so let's see the next one so yeah we have seen like latest great uis but what happened earlier like at least like 10 15 years back how we were sharing the contacts or like how we are doing the uh how we are sharing the resources earlier so what what this is one old website screenshot I took it from the maybe this uh slide share so what exactly we are doing is like here

LP is asking to find our friends concept maybe if you are like using the internet for like 15 20 years back you could ask in this page so what exactly LP is asking here is like it is asking our Gmail Gmail address and password to get our friend contracts maybe in 2024 I don't think anyone will share their email Gmail email ID and password to some random third party website but of course it happened sometime back but whenever the security folks has seen this they thought like it's not a good way to it's not a good practice obviously we don't want to ask the user credential to share the credentials uh to get our context so for that that's a

main reason what come up into the picture so okay we understood like okay this is what happened so this is how we shared it so how exactly W works then only we'll try to uh understand little bit more uh let's see like how works is like uh suppose you have a Google account or Facebook account or like apple or whatever company you have trash you have an account so what will happen is like okay you have an account and everything is registered in your iPhone or Google so then what we try to do is like U you are we went to the some random registration page so what is that is like maybe we have seen chart GPT even

even Bri sometime back right so that regist registration page will show a link like for that okay you want to login with the Google so that's where uh we'll start this flow this entire War flow then what will happen Okay some reg pay registration page show up this then okay once you once you clicked on it so once you clicked on it in the back end without knowing to you so that entire w flow will happen so you may sometimes it may ask to enter your uh email ID and password one more time here the main difference we have to observe is we are not sharing the Google Facebook accounts back to the uh some third party

registration page we are just sharing with our own Google whichever we already trusted Google or Facebook whatever the uh trusted website they will uh validate our credential then what they try to do is like once that validation is done okay they will ask a question let give you consent so we are going to share these kind of details back to the this registration page I'm just giving an example as a registration page that may be something else as well so once the user clicks on that consent then only we move on to the next stage like uh that that that we'll see like what will happen in the back end and so then after that consent that

that party website will get back to maybe whether it's a datab email address so this this is uh pretty much much high level what will happen in the back end so if you see here so some app here registered into the ab here AB is like what server or like what website where where they will register as a one new client so if you see like Facebook these third party website will register as a client so they will get a client ID so by using that client ID whenever we go to the uh user registration page of the third party website so then they will start a w flow us call what uh integration flow so what will what they

will do like once we uh it will redirect to the uh app B and it will provide the consent to the user like do you want to Grant the permission yes or no so once the user approves that then what this third party website will do like it will send any a uh uh o code usually they will provide a kind of O code and it will send a request back to the resource server and they will get back the uh what whatever we have agreed to share so we means here the user has agreed to share the data so this is pretty much high level in the next flow in the next slide we'll see

like in little bit more detail so here like this is what we have seen so far right so what user has entered a URL like maybe he go to the some registration page so that browser or like user isent it will open a URL so that that will start the W process so that W process will redirect the user back to the authorization server here this authorization server will initiate the authorization UI okay so some third part appalation is asking for your data so what what I have to do so can I can I provide it or not this authorization will server v l so if he say that so okay he will validate your credentials

and it will generate authorization code that authorization code will go back to the browser so this like during this redirections this authorization go code will go back to the web server this is the The Client app like third party registration app this app will send the this authorization code in the back end if you see here there is no user involvement here so this authorization code will back send back to the authorization server in the back end so whenever this will happen by using that authorization code they will get a access token by using that access token uh it will make a call to the resource server so here authorization server will do the all kind of okay this

is authorization code is the valid or not whether it's already used or whether it's tagged to the this uh this client app or not whether it's coming from the some other app or else expired on all those kind of authorizations will happen at this side so one that authorization is done so then we'll move on to the resource server to share back the uh required like whatever the agreed resources so this is pretty much high level not high level it's a detail so let's see like this is another flow like like not another FL it's existing flow so what will happen like after some time the we have given access to the server but after like 1 hour or two hours like

after some time if user wants to access the resource again so we don't want to uh like we don't want the ask the user to enter the credential and provide the authorization one more time because that will be like user experience issue so we'll have like one more token like kind of a refresh token by using the refresh token we'll get back the access token again we can get the resources so this is mostly will happen without knowing to the user in the backend like in the browser or like in the back end so we have seen like several flows or like several terminology so if you see in the high level so who is the resource owner

so user is the resource owner so we are the owner of our own data so that's going to be stored in the resource server resource server may be like what whoever is providing that so resource owner authorization some authorization most sometimes it will be two different Services if they want to segregate the duties or seate the duties but sometimes few organizations will keep the in the same server but that should be fine because until unless they doing in the back end that should be fine so who is the client here this client is like a third party app who will be like in the back end um back in the back end they will register their app and they will get the

client ID and client secret so this client secret also kind of feel like important because they use that client secret to sh the authorization code get back the access token or refres tokens so this is the uh overall like what what is what and all so let's see like um so we can see like another sample request if you see like this is like typical what request how it looks like maybe if you have observed any one of the in your regular web application contest like mobile pest you could have seen this but maybe slight differences will be there in the authorization maybe some people will keep like V2 something but mostly it looks like these are the

typical uh query parameters we can call it as so it will be there so we have seen like uh uh if you see in the first slide we have seen several rfcs so whenever the W has started it's mainly concentrated only uh maybe at least on the web web applications but when the technology evolves dayto day uh mobile application comes and single page applications or like even the you can see the Apple TV or Netflix or Roku lot of stuffs come up so but still uh users wants to use their one like already existing they don't want to create another credential and they don't want to so to provide the better uh better usability purposes they come

up with the different solutions and different what code flows usually like at least in the starting they used to use the only authorization flow but whenever the uh like mobile applications others comes up so they started using the different uh uh the flows so let's see like maybe in the next slide I will try to explain so if you see like the high level this is may be very uh broad diagram or like it maybe little bit confusing if you see in the first hand because W itself it's big um protocol and it has to solve a lot of issues so that's the reason it has started with the different flows and different authorization codes and implicit flow

and all this is at least not required for at this level so I just gave it for a reference uh since we are running out of time if I don't think so I can cover the what uh playground that we can uh if you want you can play around with that later so we have seen this in the previous slide if you see this is the W request so if you see closely into this maybe Whoever has done uh typical web applications pentesting they can at least guess few attacks uh that possible on this uh flow if you see like this is the main important one redirect URI if you see this one so whenever we are redirecting

the the authorization code so there are chances of attacks here because if someone has inserted his own attacker domain or attacker controlled URL the our access code or authorization code will go back to them and if you see the state as well so because uh maybe people have seen like csrf attacks because if the cookie values is not validated properly at the server side so there are chances for the U csrf attack as well so let's see like how exactly happen so these are the typical at least there are several attacks but at least we can categorize into the uh three broad categories of like Commonwealth issues uh what so far people have seen and

maybe still there are chances of uncovered vulnerabilities also there at least the first one is like as we have seen in the previous Slide the misconfigurations in the redirections URI so if you see like that entire flow we are sending the registration page back to the W server and once again coming back and we are directing the authorization code back to the uh the the the third party side if you are not redirecting that in a proper way and attacker can send the uh send a URL which will it's kind of like fishing URL which if the user clicks on it without knowing like what exactly is in the redirect Ur because if you see in a URL

that looks like a valid URL only for related to that third party website but if you are not validating the redirect Uris there are chances of attacks because if you clicked on it our Au authorization code may go back to the uh attacker contr rolled uh domain like website so then he can take the token it's kind of like if you see like in regular uh any hotel scenario so you will get the your uh token so you can access any room like suppose if you lose your token so if someone got it so they can open your room and they can do it it's kind of a similar scenario if you lose your authorization code so someone

can take it they can use it so that that's M for the that's a main disadvantages with the uh misconfigured redirect URL so we have to be very careful and BR broken authorization grants also it's kind of like if you are granting the like suppose say what server so if if it is granting the uh uh without validating the authorization grants properly and if it is granting the resources back to the uh someone like attacker or some third party website so someone can spoof it so for that what we have to do we have to maintain proper client validation whether it's a valid one or not and so that's kind of things we can see that

and we client authentication also will be there so we we show you so as I mentioned the main important one is like redirect uh URI misconfigurations yeah so these are the main uh what exactly we need to do during the redirecting the uh Ur Mis configuration so what we have to we have to look for the any open re are there or else like any validations are we doing properly or not if you see in this site so usually we have kept like some rejects like Star do some site example do uh like example SL star but in plain site it looks like pretty much good because we are validating for our own website but some

attacker what he can do like some site instead of that he can redirect that flow back to the attacker domain so even if you see in the double submit the redirect so even though we are validating properly if there are two query parameters is there for the same name with the redirect Ri so there are chances to get the authorization code as well so that then there is a good um website as well with the ports figure where we can do the URI validation by bypass cheat seat so we can try to see like maybe if you have seen any in your regular pentest or web application pentest you can try to play around with

the redirection URI to see like whether uh the server is leaking the authorization code so there is a like I think this is like maybe some time back because of some parer issues with the Chrome and uh the server how exactly they are treating the uh URL so the are chances to bypass the validations as well so I think this is fixed for now but this is kind of like an example where like if you are validating a uh if you even though if you doing the validation properly but if the paral interpretations is not doing great like if you see browser side interpretation interpretation is different and server side interpretations are different there are chances for the uh bypassing the

validations also so these are the few maybe at least I just kept couple of examples what happens in the recent like uh multiple Bo like if you s like r u with the accesss if you combine these both it's too danger so there are chances for like one click account take over chances are there so this is happen for the Facebook and happen for the booking.com due to the multiple redirections and uh not validating the uh URL so even as I mentioned uh there are chances for the authorization Grant vulnerabilities like whenever we are granting a vulnerability like granting the authorization code we should be very careful whether it's coming from the expected person or not

so for that reason we need to validate the state parameter properly because that will prevent the uh unauthorized access because uh in what typically it will have it so and attacking we client authentication because usually uh once we provided the client ID and client secret back to the uh third part applications we never know like how they are exactly storing it they may be doing the hard coding or they may be by mistake sending back to the user itself so because if if it is coming back to the user if it is there in the browser like local storage or like session storage there are chances for other attacks so we have to be make sure like

the the third party application whoever is using our services what services make sure they are not losing their client ID and client secret because if they lose it someone can misuse that as well so we have to be educate them to use the uh different uh mechanism to protect their keys uh one of them is like Mutual TLS we can use it and they can use like signed jwt's a jots to make a communication from server to server instead of doing from browser to the server at least this we client authentication should happen in the back end so another one is like uh uh insecure stoken storage so we have seen several uh tokens flying around in the

this entire floor right maybe yeah maybe it's like uh whether it's like authorization code or like access token or refresh token we have to be like pretty much careful with those tokens how exactly we are storing and how exactly we are sharing back to the user so I think we are running out of time so actually RFC for security best practices this is the best place to get started if you want to learn more about R else like trying to protect your uh applications so you can search for RFC security best practices for war you can find it out and these are the few references and I kept it as a reference yeah thank you

thanks everyone [Applause]