The Not So Same-Origin Policy

it for having me and my name is david petty and my talk is called the not so same origin policy and basically i'm going to be diving into the subtleties of like misconfigurations with the policy and how they can lead to exploits and web applications so quick a little bit about me i recently graduated northwestern university with a bachelor's in computer science i'm currently associate security analyst at independent security security evaluators it's here in baltimore and my interests are hacking of course i love video games i play a couple musical instruments and i love animals and i've always had pets including now so i had to sorry but those are my two guinea pigs um

anyway so independent security evaluators were a security consulting firm here in baltimore maryland and we basically assess our clients products for security flaws report back to them and then so that they can fix them and we're made up of hackers cryptographers reverse engineers all of the above and we like to have a white box perspective meaning of course we attest from a pen testing standpoint on the front end of a product but we like to see the full back back-end design and to find any security flaws and we have a wide variety of customers but generally they're just companies with high value assets that need to be protected and we do also get to do a lot of research uh which led to

this talk and we but we do focus on routers and ads devices and healthcare devices and speaking of devices i want to bring up the iot village which we have actually hosting here today today or tomorrow sorry um i think it's 10 a.m to 5 p.m in training room one and basically it's just uh a set of devices that we bring in you can hack them find zero days and then we know there's a set of them that are also vulnerable so it's a lot of fun you get to hack learn a lot and we hand out prizes and we do this at a number of conferences including the ones i have shown here okay so over the overview of the talk

i'm gonna summarize the same origin policy i'm gonna and talk about how it's enforced i'm gonna summarize cross-site request forgery because that's gonna be our main attack when exploiting uh the policy and then i'm gonna go into bypassing the same margin policy with custom policies and there's a number including cross-origin resource sharing and then custom policies for flash java applets and silverlight app or applications and then i'm going to talk a little bit about steps you can take to harden the policy okay so who should care definitely web app developers because this is going to help reduce uh your applications exposure to security flaws and then definitely white hot hackers because it's going to increase your

insight on evaluating same margin policies and when they're going to be more or less secure and then anyone basically is using the internet it's important because it's going to give insight on why you shouldn't click on trusted links okay same origin policy originated in 1995 and it's an incredibly important security mechanism for browsers and basically the entire internet because it restricts web pages from freely accessing data on other web pages and i'll get in more detail in a sec but the first thing is what is an origin and that is the protocol host and port number of a resource on the internet so in this example here http is going to be the protocol www

www.example.com is the host and 80 is going to be the port and so just to give a couple more examples so this table is just referencing the url i have above it and if the origins are going to match or not so the first two match the top because they have all of those three things in common and then the third one has a different protocol https the fourth has a different port 81 and the last two have different host names okay the same origin policy basically states that any resource cannot access data on another resource in the internet through javascript unless they have the same origin so in this scenario if you're the user

on the left and you visit sitea.com and sitea.com includes javascript that dynamically creates a request to site b.com by default the same origin policy restricts our response back and that this is to basically stop malicious web pages from freely accessing sensitive data on other web pages so let's get into a little more detail first thing is a symbol git and post is allowed to be sent across origin and that's because it was adopted earlier internet's history before ajax came out and uh and then also here i have just some examples of this when you can send this type of request in html tags there are a couple more too and then ajax is really important because this

allowed us to send and receive data asynchronously through the xml http request okay and like i said the simple get and post request sent cross origin by default will be the response will be restricted and this is because it's adopted after ajax and we knew the dangers by then and of course you know we don't want malicious pages accessing other data okay and then there is some you know non-simple requests and basically this is a request that uses a special method or header and you can see some examples i put on the bottom and by default the same origin policy will restrict these cross-origin even the request because they're pre-flighted meaning that they're going to send an options

request first to the server with information on the request and the server gets to evaluate if it's safe or not and most of the time it's going to say no if it's cross-origin or all the time it's going to say no if it's cross-organ okay so it's important to keep in mind this is all context dependent so uh like i said ajax responses by default are going to be restricted but external hyperlinks on the internet by the nature of it are going to be allowed because the user has the chance to click on the link or not and that's why interested links are very dangerous okay so just to summarize cross-site request forgery or sea surf

as i say the first thing is the victim needs to be logged into a vulnerable website and i'm going to talk about protections in a sec and when they log in they're going to save a session cookie then the victim needs to be tricked into visiting a malicious page and this is usually through phishing now the actual malicious page is going to create a cross-site request to modify the vulnerable web app server state this is usually in a post request it could be a get and then the server is going to accept the request because by default browsers send cookies to cro through cross site requests and that's important that's why they're in thought authenticated

and the reason this works within the constraints of the same origin policy is because the state state changing request doesn't require response so let's give some examples first thing common target sites banks social media project management but really anything that has high value accounts or assets and then some commonly forged requests the classic is making a payment so the attacker tricking the victim into paying them or emptying their bank account changing credentials so they can hijack the account uh escalating privileges could be creating a new account that has high privileges and sabotage of course which would be like delete deleting a bunch of data and uh cross-site scripting payload and the reason why cross-site scripting and

uh c-surf work really well together is because often an xss attack requires authenticated requests and if it also the web app also has a c-serve vulnerability it's going to allow the attack to work okay so there is protection it's generally through a c surf token and this is just some parameter that's sent with any state-changing request that the attacker would have to guess so it should be randomly generated cryptographically secure it should be generated per user session so it's session based and it should be independent of other info like cookies or server time so and whatever makes the attacker not be able to guess it so this is like a fake example that i just created

but this would be some uh request to update your password and if you have the c surf take token here as a body parameter the attacker is not going to be able to guess it essentially okay so let's actually go into the same margin policy and custom configurations so there are three custom policies i'm talking about uh cross-origin resource sharing course crosston main.xml and clientaccesspolicy.xml and so these three policies have associated attack pages that could be used if they're if they're configured and securely so for cores you can use basically any standard html webpage for crossdomain.xml it's compatible with flash java applets and silverlight and client access policy is exclusive to silverlight and we're going to see tac

examples soon okay first though i want to introduce my demo web apps so they're found at demo.securityevaluators.com and on that page it has you know brief summary of this talk and instructions on where the links are and how to use the attack and it's important to know that demo.securityevaluators.com is hosting the web applications while demo2.secure evaluators.com is hosting attack pages because it needs to demonstrate a cross-origin attack and we do have i do have the cser protection implemented in the uh the web applications because we're going to show how we can bypass it and obviously the app looks awesome you can buy apples or uh update your credit card and it's completely arbitrary it's just for

demonstration okay so let's talk about cores so it's developed by a world wide web consortium to basically standardize same origin policy configurations across the internet so it's basically just a set of http response headers that define what uh requests can be sent across origin that the server will accept and send responses to so the allow origin header in the top uh is whitelistingexample.com that domain allow credentials header is saying if that crosstown request can send cookies or not so if it can be authenticated and then they allow methods and allow headers to specify what methods and headers can also be sent okay um now the wildcard policy is really important because this is dangerous and this just white lists any

third party domain and it's always shown by an asterisk in these examples so in for cores it's going to look like this it's going to have this header set with the asterisk and the reason why there's a limitation for cores however because you cannot have the allow origin set to a wildcard policy and also have allow credentials set to true so and from the attacker standpoint it's going to be it's going to be harder if this configuration is set because you need to have your malicious requests authenticated um however it's you know it's a limitation for developers too because if you need to have authenticated requests from third-party domains that for the sake of functionality then you

can't use this policy so for the sake for the sake of demonstration i'm using this policy in my tests uh that i have below which is basically just the server setting the allow origin header to whatever origin is sent with the request so it's mimicking the same functionality it's just doing it in a more dynamic way so we're going to look at the wild card policy and this is my attack webpage for cores and uh it's probably really hard to see so i'm going to kind of zoom in on parts so we're going to look at this first part but i do want to say the context of this is that the victim is logged in

to the vulnerable web app and then has been tricked into visiting the link to this malicious web page so the first thing it's going to do is going to send a get request to maintain mainpage.php and main page is just where it showed where you can buy apples and with the same margin policy using a weak configuration the attack page is going to be able to see the response so you see in the bottom here i've highlighted var data is storing the response of the request and that's going to look something like this so you can see those are the course headers being set and it's an authenticated response so a request so the response is going to be

the you know in the session of the the victim so and you can see in this response i've highlighted there's a c surf token with a value so the attacker now has the victim c surf token in the response so next thing that's going to happen this is down here is we're going to take that response and parse it for the token um and this is sort of an elementary way of doing it but it works and then the the attack page is going to now create all on the same page create a new request that's a post to buy.php which is on the on the web app and you can see that i've highlighted

it's setting a quantity of a thousand and then putting the c surf token parameter as the stolen token from the victim so this is basically forcing the victim to buy a thousand apples now this is super arbitrary and in real in a real life attack it would be something actually much more malicious okay so let's look across the main.xml so this is another way to make a custom policy and this one was made earlier than coolers and so it was more an ad hoc solution because they needed the functionality of allowing third-party domains so this is compatible flash java applets and silverlight and i do want to stress that these three are going to be used as the

attack page so as long as there's across the main.xml on the web app these three could possibly be used as attack pages okay so first example of a policy is example.com so you can see in the domain variable is just setting what domains are allowed so that's whitelistingexample.com and then again there's the wildcard policy however for crossdomain.xml it's dangerous because there are no restrictions like cores so that's just something to keep keep in mind so we're again we're looking at these policies now i'm gonna use the flash example for my second but uh here actually yeah okay so i'm zooming in on the part that actually matters here and this is gonna be doing a different type of attack but

utilizing the same uh you know the same method so basically what this request is and again the victim is logged in and is tricked into visiting this malicious web page the first thing it's going to do is just create a get request to edit card.php and you're going to see what that webpage has in a second but first i want to show the policies actually in action so you can see in just in your developer tools if you have a policy or across the main xml policy of example.com visiting this malicious page on demo2 that security evaluators is going to get blocked but then if you have a wildcard policy you can see that edit card was sent and

received a response and there is the response from edit card which has the victim's credit card number so that's just another example of the attacker just using a get request to access sensitive data okay and then client access policy is very similar to across the main except it's just exclusively for silverlight but it behaves in the same way so there's not too much to talk about it and i just wanted to give an example in this picture which shows the wild card policy with the asterisk okay and there are other bypasses like jsonp or json with padding basically this is just another way a modified way for two servers to exchange json data um but it's not subject to the

same origin policy because the browser looks at the the script tag here or the exchange from the context of the webpage that the scripts are on so it evaluates the request from that origin instead of the actual target site so if anothersite.com is malicious it could possibly use it could inject code through this response because as i show here it uses a callback function and it evaluates this as javascript okay so some other things for internet explorer there is a in under internet properties and security zones there is a custom level option that just disables any cores protections and the domains have to be in the same zone for that to work but that is very

dangerous uh setting to have and then the other thing is that uh ie doesn't regard port in terms of origins so these two urls here have the same protocol in host different port but they're considered the same or same origin and you may think that that's really that's not a problem but there are some instances where it could be for example if port 80 is hosting a normal web application with sessions and sensitive data but then port 8080 uh is just some arbitrary like publicly accessible web app but it has a cross-site scripting vulnerability a malicious an attacker could use that vulnerability to trick a user into sending a request from the 8080 to the normal 81 and it would be

authenticated and receive a response because ie considers these the same origin okay um so to summarize some limitations like i said cores you can't have a wildcard policy while also sending cookies so that's a limitation for developers and attackers java applets and silverlight it requires the victim to run the plugin so you actually have to click like run and some people will do that and some people won't it is a limitation and then there is limited to plug-in support for browsers so as of march this year the firefox esr or extended support release 32-bit is the only one that supports these plug-ins and then there hasn't been chrome support since september 2015 but for ie there are no limitations the

activex plug-in still supports them and then only the only thing for flash is it has to be enabled in the victims browser for the attack page to run okay so uh there are a couple things you can do the harder in the same market policy but i want to stress that these are not fixes they're just ways to harden so the first thing is content security policy is a response header that a server can use and it's just another way of whitelisting domains that can send cross-origin requests so this could be used in lieu of a policy or in conjunction with it and then x-frame options has much more limited control and basically just prevents cross-origin

requests from the frame and iframe tags and then the same site cookie attribute so if this is another thing a server can do is set this attribute and then the set cookie header and if it's set then that the web pages cannot or will not be able to or not receive requests with cookies it will disregard the cookies so that's another thing that attacker would foil the attack because it needs to be authenticated request okay so takeaways first thing is same origin policy has a lot more nuances than you think so there are multiple ways you can configure it to cut with a custom policy they all behave a little bit differently and you may not know what an attacker

can actually do if you're using an insecure policy and then a weakened same margin policy is definitely dangerous like i've shown with these attacks it's allowing you know an attacker to either bypass sea surf protections or access other sensitive data on a web page and then i guess the main point or goal is to optimally balance usability security so especially today a lot of web applications need to include third-party domains for the sake of functionality so they need to open up their same margin policy to allow them in but the more you open up your policy the riskier it's becoming because you can't control those third-party sites so i guess the most important thing is

we actually take the time to look at the same origin policy and secure it as much as we possibly can instead of simply using a last configuration like a wild card for the sake of convenience and here is contact information where slides will be up soon probably this weekend and feel free to ask me a couple questions right now if i have time and or just talk to me after thank you very much