OfCORS! How To Do Cross Origin Resource Sharing (Im)Properly

right uh well thanks very much everyone um can you all hear me okay Grand okay getting some from the back um so um I'm going to do a uh presentation on something called cross origin was all sharing today um and misconfigurations in them um from a pentesting perspective but hopefully if you're on the blue team side of the fence or um your dev then hopefully you'll find this interesting and a bit um useful as well um so um this's going to be structure of our talk um so I'm going to go through uh sort of the basics of um the tech behind cross origin resource sharing um it is going to be a bit theoretical for a little bit of time

um sorry about that you're just going to have to power through it I'm afraid um but um it really is necessary to um the rest of presentation and informing us how we actually find these issues in real life um and understand consequences of a misconfigured cause policy as well um so before we begin uh in depth um Everyone likes a good uh classic Who Am I slide um so I'm pentester at KPMG in our cyber defense Services team um I uh I'm a check team leader um did the infrastructure exam with cs um because um I JavaScript um essentially um so officially sort of on the infrastructure side of the P testing realm um but

uh that doesn't always end up happening with all all my work so work across applications as well um as well as a variety of other things um haven't always been in offs SEC um or even in cyber security really um before as pester I was um in some of our um othered services at KPMG um sort more Assurance type work and moved over on to affect security um and read a social science in my undergraduate degree so um not your typical s ksky Affair um so that's the relevant bits of me and why I'm talking um so why a talk on Cross origin is all sharing well um if actually you could have a brief show of

hands how many people here are either pentesters or have pent tested or somewhat familiar with the field few hands but not everyone Grant okay that's good um so if you are one of those people you may or may not have seen statements like this in a report um either from a vendor or um just online um which can look sensible at first but then when you get into the into the deps of what cause is they start to make less and less sense um as we'll see later um but this talk in particular has been prompted by me reading one too many reports with these kind of statements um which sort of betray a lack of

understanding of what cause is and the context in which uh we should view a quote unquote misconfigured cause policy um and out of that frustration I built this to counts um so hopefully um we'll get a bit of an understanding um as we go through as to why I've been a bit frustrated with this um but there are some common pitfalls as you can see here um with how you can see cause findings that have been raised previously and that is partly because there's been uh sort of somewhat disperate um and in some cases incorrect resources out there online um about uh Call's issues um so this talk aims to address that so why do we actually care about

cause issues what's the impact right um ultimately it's all about gaining unauthorized access to senstive information or to protected resources or data in a web application um it can also result in account Takeover in some cases it can lead to a bypass of um security controls especially if their location or IP address based um so things like internet sites um from um from the public internet um and it can be at full on thises as well so like cash poisoning um which can then form part of a much wider um attack path um so it cause misconfigurations can be quite fiddly quite annoying um to deal with to find and then exploit um but once you do find

them you can get yourself some really nice findings um and write a very impressive report to your client hopefully rather than just here's a 1.0 CVSs score my report and I'm just going to leave it to that so um going have to go through the foundations of cause and same origin policy um I know that a lot of people here will be quite techy people and uh you know the one thing that techy people love is theory of course um but I do promise it really is necessary um so not the most exciting start which is always how you should start a talk um but uh it is it is really necessary um so let's start with what is an origin

right we're talking about cross origin resource sharing U well An Origin consists of three parts uh a protocol or scheme so your HTTP or https um your domain which is inclusive of subdomains um and your Port um so essentially when your is when we talk about issuing a cross origin request what we're talking about is one application or one origin making a request via a user's browser to a different origin so we have a sending origin and a receiving origin which will be our um Target um to make a cross origin request essentially one of these three components your protocol your domain or your port number has to be different between the two Origins if all of these

are the same this isn't cross origin request um and so that's a really important thing to take note of um a change in the URL path does not count as a change in origin um so that's something to bear in mind what it say origin policy and why is it relevant here um so the S is a it's a part of the web standards that we sort of take for granted today um it essentially applies to uh web browsers um and by default it prevents uh a browser from issuing a cross origin request um so that's baked in um that is highly restrictive and it's designed to be so um and it's essentially intended to um prevent scripts from ascending

origin to access sensitive data from um your from another origin um this will include restricting scripts from accessing data um from any other origin so that includes um authentication information such as session cookies or other credentials um sensitive data in uh your application responses or malicious scripts hosted on an attacker control domain um among other things um so the swap is designed to essentially stop cross origin requests from happening um So that obviously can be quite restrictive if you've ever done any web dev work um so we want some way to relax that while allowing us to restrict what Origins uh can um send across origin uh requests back to us um and that's what

causes it's a relaxation or controlled relaxation we say of the uh same origin policy um and essentially this we need this essentially so that a web application that we've developed um can access data from any other origin be that an API um from a third party a subdomain or some other system it might reasonably need to retrieve some other resource um to do its job and that's what Co allows allows us to do um and uh this is essentially implemented by specifying the origins that can make cross origin request back to us um so we specify the origin or Origins um in our application configuration um and we specify which resource those Origins can um send those requests to as well um and

we also specify whether those requests can be credentialed so I can it access all um resources or data that should normally require authentication um so yeah I'm going to use the terms site b or evil.com or site a um throughout um so uh our site B is going to be our retrieving or sending origin and I'll say is going to be our receiving origin in practice uh call looks like this um so um a key component of um cross origin resource sharing is the users browser um if there is no if there is no web browser involved then you you're not going to be to uh to um exploit a a cause Mis configuration um we get into

this specifics of why a bit later um but essentially user via web browser has to visit um your ascending origin or your evil.com um and that data needs to be permitted by the receiving origin or your victim site um to access some uh protected resource or protected data on there um that can happen by either simple cross origin request or via VIA a pre-light request followed by a cross origin request um again we'll get into specifics of the differences between those and why that's important in a bit um but suffice to say um looking at the the configuration of our receiving uh origin is really important so more Theory I know you've been waiting for it um we are almost there um

onto the more exciting stuff but uh we're going to let get through the last little bit of theory before we do um so in order for a origin to send a cross origin request um it need this has to involve something called the cuse header exchange um the reason why we care about this is that essentially we don't uh when we as pentesters or as offensive Security Professionals um what we're really interested in is is sensitive protected data that should require authentication On Target website right or Target origin uh more accurately um we don't really care about some generic homepage that you can send across origin request to because that would reasonably not uh not

host anything too sensitive right um so we uh need to take a look at the header exchange and whether we're the application configuration allows us to send a proper cross origin request um end to end um there are two types of uh cross origin request um that I mentioned earlier so simple and pre-lighted um we'll go through the process of a simple cuse request first and this is essentially what it looks like so we have our victim browser um our evil.com which is our malicious domain um that we are hosting as uh as penor and our victim.com so in a uh simp uh simple request um it will consist of either a get a head or an options request no

other method is allowed for a simple cross origin request um and you have to use uh one of a small number of um content types for the for the request as well um so either you encoded or text plane um or multiart form data uh content types as well um if it's any other um content type then you're going to be sending a pre flighted request um and essentially what happens in this uh in this simple calls exchange is that um the malicious domain that we are hosting um will direct the users browser to send uh after initial request to send a cross origin request over to our victim um and if permitted if the

origin that we have specified in our origin request header is permitted then it will send back an access control all our origin um header spe reflecting back dynamically uh the malicious domain that we have specified um and an access control allow credentials with the value of true um both of those components are necessary um the credentials uh header essentially tells our browser whether um whether it can send a follow send a request um uh with credentials to a protected area of the site um and the origin determines which origin is allowed to do that pre flighted requests are a bit more complicated um but the first couple of stages are the same um what does

change is that before the main cross origin request um and options request is sent via the user's browser um and what this does is it essentially solicits the Target website um on whether it whether it is permitted to send that second uh Quest um so again we have a dynamically generated dynamically reflected um AAL header specifying our evil.com um and allow credentials header as well um we also get two other headers with allow methods and allow headers um which uh specify obviously which methods and which headers are allowed to be sent in the following request and then the rest of the flow is just like a simple um simple cross origin request um these pre-f flights occur when you have um

other content type values um so for instance when uh you um you send Json for instance in a post request that's going to induce a pre-lighted cause request um and so essentially you have a solicitation stage and then the actual request um so I mentioned a few of those it's just a rundown of what those headers are um our malicious domain is what is going to instruct the browser to to specify um its own origin in uh in the cross origin request or in the pr pre-light um and then what we're really looking for is for that to be reflected back dynamically and not statically um if it's static then it's you essentially don't have an issue um because the

target application needs to essentially respond um to the specific specific data that you're sending so if if you're finding that you're putting in evil.com and it's still sending an asterisk that's uh you're not got an issue essentially um and that's one of the common pits that we'll see later um so again so these are the response headers that we saw earlier um allow credentials and allow origin are really the most important um but you will need a valid method for or you follow on request if you have sent a pre-flight um and you'll need valid headers in there as well um those that specifies any additional headers that will need to be sent for instance

authorization um if uh the credentials that need to be sent over to the Target um require something um like U like basic authentication for instance so now a bit more to the fun part um so what are credentials uh I was talking about this earlier um so there are a few different types the most common you'll probably find is Obsession tokens um in in your cookies um but you can also um have cross origin requests that specify HTTP basic digest or nlm credentials as well and there also other ranges um such as client certificates as well um but these will be the most common um essentially what you need is a credential that will automatically be sent by the browser um

without the user having to essentially interfere with um the the cross origin process um and this is just to emphasize as well that the users web browser is a critical component of this um because otherwise there's no method for our um malicious origin to send that request to our Target in the first place um so what I commonly see in uh in Vendor reports is that uh we have somebody who has been very excited uh while they're WR writing the vulnerability um they're testing an app to app API um that uses something like bar authentication um or something that simply isn't going to be accessed VI a web browser um but instead by a thick client of some sort um and

they've said well that's responded dynamically to my request and therefore there's a c configuration highis finding um but there's no web browser involvement at all so it's not actually exploitable so worth reporting but it's not going to be um a very high risk finding [Music] um yes uh so um this is what pre-light looks like so as you can see um we have uh the target uh the malicious domain um specified in the origin header um with a specific port number and then the victim application is sending that back dynamically with allow credentials true and then in the F on request after the pre- fight what we can see here is that a session uh cookie has been included in

that request so that second uh request is now credentialed because it's been permitted to send the browser has been permitted to send that um after the solicitation um and then we get our API key or whatever sensitive data that we're targeting um this is essentially what uh it looks like with basic authentication most of us will be aware of this um but for those those of us who aren't when you have HTTP basic authentication with an application um and you you're first going to get a response uh Forum unauthorized with a www authen uh authenticate um header um specifying uh the type of authentication you need the user will then um will then provide their credentials to the Target

application and that will get sent on uh in an authorization uh basic header um and then subsequently when when the user uh submits request to the website um to protect it resources that will automatically be sent um via the browser the user doesn't need to intervene um anymore and provide their credentials again um in the same way um that does differ with other types of authentications so um for instance beer tokens um so you can have uh your authorization Bearer and then often a JWT um though a bearer token is not going to be sent automatically by the browser um that's something that the user has to specify in the request essentially manually um so um when you have bar Authentication

you're not going to have an exploitable vulnerability in this in this way um because essentially you the attack relies on uh the victim's browser automatically sending those credential those credentials in the request um otherwise the attacker you as the attacker have to know and be able to retrieve that token which you're very unlikely to be able to do um so I approve concept this is very very basic um but approv of concept would look something like this and then attack um so you would create a malicious web page um and put some JavaScript in it specifying your target um and for instance here API secret key for example um you would need to specify the method that you're going to send

that that your malicious web page is going to instruct the users web browser to send to the victim um you're going to need to instruct it to send it as with credentials so credentials in um and as well the headers that are required for that um request um particularly important for uh when it might require a pre-flight um so if it's AJ on data for example um so very brief but that's is actually what the kind of script you're looking for will look like um have a very short video here which shows what that does look like if it will work will it work [Music] uh no I don't it does work okay so this is baby's first flask

[Music] application and what we can see here is a request to an API key which requires authentication to retrieve uh that's our Pok uh pork website little button that sense but in this case what we see is that our pre-light hasn't worked for some reason um and that hasn't worked because of the specific browser that we're using and controls that are applied to that browser so if you've ever used the B browser before you'll know that's um chromium uh but when we switch to Microsoft Edge we see that it has worked suddenly um and we can see here um the pre-light has received a positive

response so we can see the correct

headers and then we can see the f one request is also receiv receiving positive response because it's passed the solicitation and it's sent the browser sent the request with with the session

cookie good to stop that okay so why did we observe that strange Behavior between two different browsers doing two different things um essentially it's down to how cookies are treated between different browsers um so certain cooking attributes can throw a bit of a spanner in the works when we're looking at call requests and cause issues um so we'll all most of us will know what H HTP only does but essentially if it is set on a cookie it will prevent JavaScript um from on the web page from accessing it so key secured control you also have the secure cook key which aims to prevent transmission over unsecure protocols um and you also have the same site cookie

um which gets very annoying very quickly um and essentially um the important thing to note is that in the absence of application specifying um what same typ policy is going to apply most modern browsers these days will enforce The Lax policy um what does that mean well there are three different types of policies you can apply so either none LAX or strict um with uh none um the secure flag will always be required um and with uh LAX uh essentially what this means is that the um cookie is not going to be sent in uh in background requests um but essentially the what this acute is sent to will um change how the browser um whether the

browser allows you to send a cross origin uh request and that's why you end up with errors looking like this if you're web dev sorry for the PTSD um but um you will find us a lot um essentially since 2021 um Chrome and chromium which includes the bir browser sorry um will apply The Lax restriction by default um which is what we observed earlier so we saw that the Bert browser wasn't actually sending the cross origin request but without any change to Microsoft Edge it was um and that's because um Microsoft Edge just doesn't do this by default at the time of speaking um but chromium does block it block it by default um so that's

something as tester that you're going to have to make sure that you check you double check your tools and how they're configured um and don't just assume that because your Pok isn't working therefore there is no issue um make sure you go into your browser settings and uh modify the configuration as need be to allow third party cookies to be sent in Cross origin requests um annoyingly as I found out in exitor a month or so ago um about the day before um Chrome changed it changed uh a policy that it was going to implement to drop support for third party cookies by default it's u-turned on that uh so for now this is the way

that Chrome and C behave um but that will not necessarily be the case forever um so just as a bit of a warning and you see there in the bottom right um that's the um uh the behavior that you will see when you open the butt browser usually it will tell you actually I am blocking third partic by default and you want to basically tell it allow me to send these in Cross origin [Music] requests um so this is uh same thing as earlier um but rather than using the same site non-attribute we're using the same site

LAX and what we see here in our browser if you simply press this [Music]

button and suddenly it's working again literally that simple something that can be very easily missed when you're in a russal test

oh there we go right so um as we close out some common pitfalls and things to avoid um the first thing um is not checking that the application responds dynamically to our origin requests so according to the actual web standard um this is uh this is what it says so when responding to a credential request the server must specify An Origin in the value of the AAL header instead of specifying the wild card so if you're just seeing a wild card no matter what you send in the origin request any origin has you've not g exploitable issue so make sure that you avoid um just raising the finding that's high risk just because you saw uh the header in the first place

uh that's not good um another Pitfall can be um not checking that the resource requires authentication don't just do it on generic homepages um and not testing outside of BP so as we saw earlier um in order to demonstrate an attack path we need to work with our browser um don't just send origin payloads in B and then stop uh then make sure that you try things end to end it'll be much more interesting and much more impressive to your client um don't be F by this um and uh do just double check the type of credentials that you are sending um so bear in mind the difference between beer um beer tokens and other types of

credential request um and check your cookie attributes as well so I will leave you with this checklist um so it's very simple really when it comes down to it um check that your a headers are dynamically generated in responses um make sure that they are projected resources that you are targeting um check the authentication method that's actually been used and the controls that may apply to it um determine whether the requests require a pre-flight because that will um require a change to your P um and confirm that everything actually works outside of purposly um there is more to the world of and B I promise you um and make sure you double check your browser settings as well when you're

um when you're exercising the B um so thanks very much for listening um I hope it's been interesting for you as the last Talk of the day I know that's the last thing we want to hear the end of the long day uh web apps um but um if you want to reach out to me uh I'm not very present online but there I am that is the best picture KPMG could do I can't explain it clearly their fault um but yeah thanks very much for listening and um [Applause] yeah questions how many minutes got four

[Music] minutes so Cory what do you like JavaScript [Music] there was once there was there was a great man that once told me that JavaScript was made by uh by drunk Engineers uh so that's probably the reason why I think I need to be at certain level of inebriation to sort of understand job script reason come on any other questions

all great talk by the way uh looking back at uh what you presented there so if you got a web application that's got cookies that are sent with same site Lacs they can technically still be vulnerable depending on the browser that they're using and what settings they're applying so for example if they uh were to click on that link and to allow that third party cookies and that would essentially mean that the full exploit could could essentially be done however if they had same site uh set to uh just its own domain then essentially can't be exploited is that is um yeah so the the key thing with with ls as well is that um so first the US browser does

need to does need to allow the sending of third party cookies in request um so for now some browsers behave differently than others um so that is one thing which you when you're doing your write up um or if you're on the receiving end of the report you you need to interrogate so you know if it's an internet internet application for example or something on an internal Network it might be a bit more reasonably a bit more likely that somebody that your users would be using something like Microsoft Edge um but if it's a public facing application that might be slightly less likely because who on Earth likes Microsoft Edge um the other thing with um thex attribute is

that it requires a top what's called a top level vation to the web page um for it to actually send across origin request so that will essentially fancy language for following a link to the web page rather than um uh so getting to the web page as a link from another web page actually rather than just clicking a fishing for example um so that's something you'd have to consider as well it makes it a bit it makes your attack path slightly longer and a bit less likely but in theory yes it is still vulnerable

that i' like thank let's another

[Applause] round cool okay well I mean I think that concludes uh