Web Apps: APIs’ Nightmare

hello oh I believe it's working hi everyone thanks for joining today it's a pleasure to be here I came all the way from Portugal to be here today uh I would like first of all to thank besid Ahmed Abad for the awesome Organization for the awesome event uh my name is Paul Silva uh the best part of my daily uh work is searching for vulnerabilities I do it either on pent testing or ethical hacking uh but I my background is in Computer Sciences I started as a software developer for 15 years that was what I I did so 15 years is plenty of time to do all sort of mistakes uh then I shifted to security I

started as a wasp volunteer uh and I've contributed to different projects nowadays I'm co-leading the OAS PPI Security project and I've co-authored the OAS PPI Security top 10 that you may have heard about it um I don't have a real agenda for today uh I want to share uh a story with you about the security vulnerability but we should go back a few years in time so in 1989 certain burners Le proposed the HTTP protocol uh in the next year he wrote the first browser and the first HTTP server on the next here he also created the first website this is how it looked like I believe that he was far from imagine how we would use the HTTP

protocol and the web Technologies as we are doing nowadays you can still access the first website using your modern browser and this is how it looks like in 1993 uh the first browser or web browser for non-tech people uh was released and in 1995 uh Netscape came up with the Navigator uh it was a a more polished web browser and and in the next year they added support for a scripting language and we should welcome in 1995 JavaScript meanwhile some folks were uh working uh towards making Dynamic page computed server sit I'm not sure whether PHP was the first programming languages allow programming language allowing to do it but it plays an important role in

the evolution of worldwide web uh recent stats say that PHP is still powering 70% of the known websites uh what I'm going to show now is pretty pretty much what powered theom bubble so we have clients uh back in the days it was a web browser IT issues a request that get through the server that picks the file you want and returns HTML then the client pares the HTML and looks for additional resources the client should request such as JavaScript it goes to the server picks the JavaScript it could also pick stylesheets and then if the user wants to navigate to another page like the login page then it has to go to the server and the server gives you back the

computed HTML and then the client has to do all the heavy lift work to pick up the JavaScript Styles sheet and stuff like that if you wants to really log in send your credentials it's respons is the server is the one responsible to compute again the HTML with your username uh on it so when pretty much every company had already a website running mobile apps became uh the new thing okay and they had to start developing web applications web applications are a bit different from uh websites they have their one presentation layer but the goal was to offer a simulus experience to web uh website users so the info you have available on the web should also be

available on your mobile app and the other way around but as I said uh mobile applications they have their one presentation layer they don't use HTML CSS or JavaScript at least back in the day they they they didn't use it nowadays you have modern Frameworks that allow you to develop using web Technologies but the way they work uh they just need data from the the the backend server so they just send data to the server and they get data Json is the most common format uh you get data from the server server so if you want to log in you post your credentials and you get uh probably an Al token from the server then if you want the user profile you

just uh request the profile with your authentication token and you get data from the server the same for posts so as you see there's no HTML coming from the server to the to the client and then I know that nowadays everyone is uh focused on uh AI but iot is still a thing so we had before web browsers as clients then mobile applications as clients and now we have everything as a client using the same technology the same thing that was built in 1989 okay uh the protocol remained almost the same uh until the http2 no major changes were added so with iot most of the devices they don't have a presentation layer they don't

have a graphical user interface they just exchange data with the server uh they pull data and they fetch data and the data may be created by a mobile application like when you set up your smart bulb at home probably you're going to use your uh a mobile application to do it but then the bulb should uh should pull the data from the server uh the same is true uh if your Bulb Has uh the capability to to uh collect and send to the server the power consumption probably you want to see that data on a web browser on a very nice and fancy dashboard even some devices they have same capabilities uh both a mobile phone

uh tablet or a smartwatch probably all of them have tracking capabilities they can collect your location and probably want the the way these data should be treated server side is the same the same so you don't want to have to implement uh the same Logic the way you treat the data uh on three different uh applications you want to do to treat it the same way on a central location and then we should welcome apis apis allows us to decouple the presentation layer uh from the business logic and the data the data layer so they they work pretty much like mobile applications they don't care about presentation they don't care about HTML CSS and JavaScript it's all about data

so you can can get the device config from the server and you get your data using the Json format or any other data exchange format you you can send data to the server and you get back data you may on the server side this this you should look at this as a a blackbox uh although you may be sending requests to the same server internally probably you're hitting different apis they are very specialized okay uh uh even uh they may require external or third party services for instance to announce some data that you send to the server they need to contact Google Maps to collect additional data on that on on top of that information even the server

while your client are hdle uh they may interact with other services uh to collect data or to do some heavy work uh while you're not using the server of of course uh with the apis playing a central role web application uh development has changed nowadays we have or companies are likely to have uh different teams to handle the front-end development the presentation layer either for web applications and mobile applications and specialized teams on the server s probably some of them they are specialized on apis and they are just developing apis so with the Advent of apis the web applications right now probably if you look on the network they're going to get the homepage they're going to hit the

Slash and they're going to get a small HTML file a very simple HTML file probably the second request you're going to see is a bundle uh JS a Javascript file and after that all you're going to see on the network are just fetching data or pushing data to the server because all the presentation layer is within the build the bundle JavaScript modern web applications are built using modern web Frameworks like react uh Vu uh selt and stuff like that even web applications they they don't have to use a single API they can even directly contact third party apis and this is what you're going to get uh if you look under the wood uh with apis popping up

everywhere uh security folks start looking and finding uh security issues on them uh also attackers they shift to apis because they are uh easier to attack because the interface is predictable it's well defined both well defined and predictable so the learning curve is uh really short and because of that uh we decided to create a an API specific top 10 uh we learned from the past that we cannot let the technology Advance too much uh before starting teaching developers how to address security uh on that technology we start seeing some uh some security issues that were really common back in the days on web applications they start popping up on apis I'm talking specifically about what

you probably know uh by idor in Secure direct object references that we called broken object level authorization on apis it's pretty much the same thing it was really common back in the days on web applications and right now it's really common on apis so we should talk to uh API developers about that so that they can address it and probably we should also fix some misconception about what uh insecure direct object reference is or what broken broken object level authorization is this talk is not about the API security top 10 if you want to discuss it later don't be shy come to me and let's have a shot about it but it's important to keep in mind that

apis uh mean data this is I would say the reason number one why attackers go after apis directly after apis because someone said that uh data is the new the new oil and to be honest on the digital economy in fact it is uh we heard about how much does it cost a data Bridge so if we have to compromise if we are looking after data apis are a good candidate where we're going to find we're going to find loads of data um and this uh with this we we arrive to the second part of this talk ATR 49 uh when we have SP spare time while we're not uh pen testing we uh do

some research look for for bugs on other companies it's not exactly bug Bounty but several companies they have responsible disclosure programs so usually we do it and we decided at some point to do it on car manufacturers see how they handle uh how they secure their digital assets so they I know they they are worried about car safety we decided to to see uh how they handle uh security and porsch was an one of that car manufacturers we looked at they have a responsible disclosure program so we focused on the in scope uh assets uh we we heard it already uh today um if we want to hack something if we want to break something better

knowing how it work how it works how it was built and how it works one of the Assets in scope was this Porche experience website from the user perspective it allows to booking uh tracking days uh manage your bookings create uh virtual garage uh but also manage invoices and stuff like that so it is likely to have uh enough data uh and we decided to to check under the wood we find out this is a single page application uh so do the same the same workflow we saw before it just fetches the the homepage the slash uh endpoint it gets the bundle and then it starts fetching data from a graphql API uh we also heard about graphql today already

um I'm not go going uh into uh depth into graphql that is not the point here today but while looking at the traffic to the graphql API we saw something strange that called our attention we saw that on a single API request they included the authentication token or the authorization out token twice it was available both on the uh as a cookie and in the uh app authorization header so if you're familiar with uh web development and how the web the web browser works it's totally different it's a game changer when you add the out token in the custom or in the authorization Heather because if it's on the cookies the cookies are managed by

the web browser the web browser automatically adds the cookie to the request so uh we came up with the idea so what happens if we don't provide the app authorization header uh does we get it automatically the cookie automatically added to the server and that do we get the same resource and replaying the request without the app authorization just with the out toen the cookie we got the exact same response that means when the app authorization add is not there the server or the API is going to look for it on the cookies so we came up with the idea which is not that brilliant that if we create uh our one page and we issue a request to the

graphql API if the user is authenticated probably we're going to be able to fetch the data so this is called a cross-site request forgery we were not sure but we could just ask the the API whether it was willing to fulfill a request uh started from our page and this is what we have here from a different origin other than porsche.com from my one server a page uh specially crafted for this uh PC the API replied successfully with a 200 okay and doess control allow uh origin and credentials in the response so the API was willing to fulfill our requests so there's another question as I said before uh cookies are managed by the web browser I mean

whether they are included on the request so uh the next question is is the web browser uh is is U willing to add the cookie if we start the request from a different origin and that we can answer looking at the cookies uh settings and the GWT token is the one we care we can see that the the HTTP only flag is set to false which is not a good idea but the one we uh really care about is the same site which is set to LAX the same site uh is a security mechanism because cross site request forgery attacks were really common on the web web browser vendors starting adding some security features uh to mitigate some of the risks and the

same it is one of those cookies attributes security uh attributes uh that controls whether the browser should include automatically incl include the cookies on cross- site requests and Lex means no so uh we could gave up or try harder and we used to say that hackers or Bad actors they're going to always try harder so we know that the cookie won't won't be automatically included on our uh cross origin request the point is we just need a way to make uh porch.com or a subdomain of it uh to make the request and we know that this is not a typical feature this is not something that we should uh expect to find on the website

but then there's cross site scripting I I'm expecting that most of you are aware of cross CR cross-site scripting but just to put every run at the same page crossy scripting allows you to inject JavaScript code that's going to run on the page as it was there before that is as it was code written by the developers okay and we found one on porsche.com in fact we found two cross side scripting the second one was a content. E.P porch.com and there was a third one at campaigns. porch.com I brought this today because uh not always we can we can not always Target the API directly sometimes we have to abuse or exploit an API client to Target

or to reach our goal uh so this I brought this because um sometimes you have to manage two different things to achieve your goal and this we were not uh we were not looking specifically for vulnerability we are we had a an attack scenario in mind our our goal was to fetch data access other users data no matter what so we first looked at the API we found a way to move forward and then we ended up needing to uh exploit the web application to Target the API uh and we decided to move forward with this cross-site scripting campaigns. porch.com sounded catchy for a fishing campaign because this was our our scenario we know that we we deliver

some malicious URL to a victim and it is a Porsche experienc um user we're going to fetch the data so right now our goal is to let's say create a fishing campaign send the malicious uh URL our victim is a Porsche experienced user it and he has a valid session and what we want to accomplish is to make an API request fetch his personal information and exfiltrate it to a remote server so this is the starting point about the cross-site scripting on the this parameter this was just to confirm that the cross side scripting was there just popping up the same alert we have here but we need uh more uh logic to fetch data from make an API request and

exfiltrate the data to a remote server so it is not practical to put all the logic on the on the URL so we decided to go with a loader this is just a simple script to load at a second script from a remote location so we create a script element we set it to our remote server to a file that we put on a remote server and then we will We append the script to the document body this means that the browser is going to load the script and execute the code in there to avoid some issues encoding issues in the URL we did the common technique based 64 in code on our payload and then the the the the payload

the we decode it first and then we pass it to the Evolve function to read and execute the JavaScript code on the remote server this is the file we put there first we have we prepared the query to get the user details authenticated user details we fetch the data we actually make the the graphql query we send and then we send the data to a remote location then we are we were kind enough to redirect the victim to the homepage to make uh Mo the the attack almost unnoticeable and then we finally used AI we asked chat GPT to write uh a catchy fishing email he said no and then we with a few other prompts we got a catch

email from sh GPT we just had to add the URL uh with the campaign sport.com if you want you can even you could even uh hide the payload to make it even look nicer and this is the P we sent to

Porsche so right now our victim is really excited to have a Porsche track

experience and we got happy with their

data so there's nothing fancy here uh the point is we were not looking for a specific vulnerability uh we discussed it earlier today uh doing recon uh no the assets that are in scope how they work how they were built uh and then make your one scenario and try your chances with your with your scenario so this is what we did here and we accomplished our goal this is fixed uh so there's nothing new here I've put together some resources uh for you on the left side you have a API resources our es from oasp you have goats and stuff like that uh that will allow you to learn API security several uh OAS sheet sheets uh that are um

relevant for API security how to develop how to how to secure and some uh coding guides on the right side you have General resources to allow you to better understand the HTTP protocol uh how it works uh how the cross origin resource sharing policy works um and also to understand the different API protocols rest uh graphql RPC uh at the end of the day they all work the same they have specific features but at the end of the day all of them work on top of HTTP some of them they can work uh uh on top of other protocols uh but at the end of the day all of them work on top of HTTP uh then you have several several

graphql articles uh and specific issues you Al have a specific graphql sheet um and at the end on the right side you have mind API if you're going into API hacking it's a a good resource uh that helps you to cover the OAS BPI security top 10 from an attacker perspective or a security guy perspective uh this should make your life easier to use your Mobile phones and get the resources