Achieving the web isolation nirvana, how far along are we?

foreign one two let's go can they hear me can you hear me okay awesome all right hello everyone Welcome to our talk on web isolation um man it was such an inspiring keynote it was amazing like it will be very hard to follow you know we basically should sit down there yeah we should run away right all right so um I'm co-founder and CTO of J scrambler um I also helped started the new Oasis boa chapter basically you had our first meet up uh this week I hope the the other chapter leaders are somewhere in there uh but basically I've been working in security for as far as I can remember there is uh stands for virtualization I think uh no no response at all huh all right um I've probably been working in security almost as long as uh Pedro can remember okay so time for a little story better it's 10 a.m I'm barely a coffee in are we gonna do this yep we need to push through like people are waiting so um it's a story about a ship um some of you may recognize this ship it's the Titanic and it was built in Belfast in their famous Shipyard which I was lucky enough to visit during the absec absec EU 2017 I guess but we want to talk about how it was built many people do not know this but when he was built it was bleeding edge in many ways so the bottom of the ship was splitting to 16 water type compartments so it was made such uh it could withstand some damage without compromising the whole ship it could I think up to two adjacent compartments could be completely flooded which back then it was like the worst situation they could imagine and that's mainly the reason why they deemed the the Titanic to be Unsinkable so they made a great fuss about it but depending on the exact location of the damage it could actually withstand up to four adjacent water type compartments completely flooded without sinking the ship so we all know how this story ended when the Titanic hit an iceberg the six forwards compartments were completed flooded and the Titanic sunk so even though the story didn't end well compartmentation was a great idea and it is still used in shape design to this day so the main idea is that if a section is damaged it doesn't compromise other parts of the system the problem with the Titanic is that its implementation was flawed but we'll tell you more about that later it's a this is a cliffhanger at this point yeah I guess so all right so um let's talk about web isolation then a little bit of History before we start okay so the first real attempt at web isolation was introduced by the same origin policy to restrict how two different Origins interact with each other but restrict how if actually we can embed a third party like a cross-origin script from the third party origin directly to a web page and this script will actually have the same level of privilege as any other script like same origin scripts so where is the same origin restricting anything here so it turns out that embedding is permitted what is restricted is writing to or reading raw data from cross-origin domains so the reality is that the same origin policy is complex and has lots of exceptions and to this day many developers don't fully understand how it works which is frequently a source of security issues two years later we they have given us like iframes okay with which we can isolate two documents or scripts running on the same web page but the problem is that people uh soon enough started to look for ways to have these two different Origins communicating with itself like coming coming with hacks and creative hacks basically and and we only threw the towel 13 years later and made it official by introducing the web messaging API with which two different Origins can communicate using a post message basically but not every problem went away so for instance iframe still had a lot of power an iframe document can navigate to the top window among other things so we had to solve that problem too and 13 years later we got high frame sandboxing with which we could restrict very heavily what an iframe is allowed to do the problem is that at the same time they have given us this configuration attributes that allow us to relax the iframed sandbox I frame so it's it's like they given like the power and then they take it away and people obviously they're going to use these things to relax the sandbox about the same time we got content security policy version one uh with which you can do domain-based allow listing um which was later found to be completely broken and you can read all about it in the paper that you can see on the right plus it's very hard to maintain so later on versions two and three they fixed these problems but they are not straightforward to set up so I would say that like the main critique that we have on CSP is that it is kind of binary like either you fully allow a script to run or you fully block it there's no middle ground so basically um if it was more more granular it could be more useful for sure and this basically concludes that the problem with this isolation mechanisms is that they are they lack granularity um they the the the boxes that of isolation that they provide are not are not configurable so you basically so there was never one isolation feature with which you could do like full isolation of a web app so it has been more about stitching together all of these isolation features and hopefully to cover as much ground as you want so this is both complex and error prone so inevitably you will leave holes or all blind spots for instance Jason p and cores are good examples so if they were configurable and granular maybe people wouldn't like had the need to try to find ways to relax these features or to poke holes on them and here you can see the timeline where these features were introduced you'll notice a huge gap between 97 and 2009 which you really have to wonder what the browser people were doing back then we needed our pacemakers configured at a higher Pace I think all right so what Pedro has been talking about is a large variety of different features that browsers give us the thing that we are trying to get to is isolation what we are trying to build is the ability to isolate different scripts and their actions uh but what we have is a variety of security features that the browsers have implemented almost reactively as different attacks arose the question is can we use those features to put together a more solid a more systematic uh way of building isolation and I think that the answer is yes and you shouldn't just believe me the community you and I we all have been building um essentially a a mechanism for doing web isolation on top of the browser features that we have um I'm going to describe two different primary mechanisms that we use in order to um in order to implement uh web isolation and the two techniques that mostly we use are um are uh virtualization and transformation now there's three projects that I've randomly chosen to put on this graph but most mechanisms for web isolation end up falling somewhere on this graph on this graph you have virtualization where what you do is you virtualize you replace the versions that are provided by the browser with our own attenuated version if you see something that is dangerous you replace it with something that is less dangerous or easier to control and then you have transformation where you're simply changing the source code so that you remove the bad things from your application so we have a way off on the on the top right we have a project called Google kaha which was an open source sandboxing project with which I was intimately involved which uses both a combination of virtualization and transformation to achieve this sandboxing there was a another open source project called jsrag which uses mostly transformation in order to achieve the same kind of effect and then we have A J Scrambler with which Pedro is intimately familiar which uses more virtualization but essentially what we have in our we have two tricks in our toolbox to use to build um to build isolation which is what we are trying to get to now I'm going to talk first about virtualization what is virtualization well I call it virtualization but we all already know this as polyfills right uh what is a polyfill you have features that are provided by the browser or sometimes you don't have a feature that is provided by the browser you implement it using other mechanisms that are available when you use virtualization for Security even in cases where the browser provides some particular capability you end up replacing it so for example if you have date this is the real date object provided by the browser you might provide a virtualized version well date unless you care about timing attacks you can just provide the original date object directly to to third-party code another case we saw in the in the keynote uh a browser I'm going to name the browser am I going to name the browser ie6 which uses ActiveX ActiveX was overly powerful if if a third party had access to ActiveX there was a huge number of things that they were able to do and maybe you don't want to provide access uh to to um to ActiveX so you you never provide this uh to third-party code but you can also an innovation where the ie6 also did not provide a compatible xhr object but ActiveX was able to implement um was able to implement uh xhr and so what you can do is Implement a version of xhr on top of ActiveX and then via the power of virtualization you hand only a version of xhr to uh to third-party code and you can even provide a version of xhr that only connects to particular proxies or connects to only particular third-party sites and therefore you're sort of controlling exactly how much power this third-party code gets similarly you can virtualize the Dom you can virtualize access to location you can virtualize access to Inner HTML Etc and you build up this way of controlling not whether a script executes or not but how much power the script has when it is executing so that's virtualization for control there is another version where we use transformation now this is easily my most favorite slide Pedro gets a little uh nervous when I get very excited about this but essentially the only this is the mechanism by which almost every language based sandboxing control works on the on the left hand side left hand side my right hand side what you have is the variety of functions that you're going to call so you have alert which is like a like a system call for for the browser right these are functions that are provided externally you have strings which are types you have function types and array types you have a variety of primitive types which are provided by the browser what you can do is transform this and rewrite it so that each one of those functions types and primitive objects are instead accessed only as a result of an argument to a function so this is very simple kind of transformation but if you think about this this means that the caller of this function controls everything that is happening inside this function every call goes by a uh is controlled by the column and this basic primitive allows you to essentially sandbox large pieces of JavaScript now I know those of you that are familiar with JavaScript I like just as look there's all this eval that allows you to break out of the sandbox and there's ways of Walking Up The Constructor chain there's ways of walking up the Prototype train and you're absolutely right but the basic idea is this one and this is really I mean it's a basic mechanism of sandboxing and it fits on a on a single slide and I think that that's one of the reasons why it's power and simplicity together mean it is the basic building block of what we're going to end up building you see how he gets excited about this too if you you can come talk to me after this I can talk about this for ours um can we do this for HTML and the answer is obviously yes it's actually even simpler for HTML because HTML is a much simpler language and so you know you can do a a a series of rewrites for HTML uh on the um on on this side you have styles and for CSS it's even easier if you prefix every CSS rule with let's say in this case uh dot gadget123 that means that the scope of what is affected is now limited to only uh the children of uh of an element that has um that has that particular class overall what is happening here we're turning we're not allowing or blocking HTML we're not blocking or allowing CSS we're not blocking or allowing JavaScript what we're doing is controlling how much access any particular part of the code has access to um and this is a very powerful General technique right you can you don't just need it for uh visibility you can also use it I mean you don't just use it for control you can also use it for visibility you can transform each one of these functions such that all of the access goes via one function that you control and it can do a variety of things in yesterday's talk I think JB talked about uh um how valuable observability is when you're doing pen testing observability or visibility as we end up calling it is very critical because sooner or later functions fail now you know this room is filled with clever hackers and sooner or later the foolish people who are standing on stage who are building sandboxes our code and our sandboxes end up failing what is critical is not to build sandboxes that remain absolutely robust but build sandboxes such that when the sandboxes fail you get visibility you can to find out that the attackers are in and so that you can end up responding and virtualization ends up giving you the same kind of control um in general what is happening is there's some general design principles that we are using in order to build these actually in yesterday's keynote there was a a a slide that Alyssa presented which as you as I go through the the three principles mirror the the the principles that she was talking about as well Prince so there's going to be three principles it's visibility ease of use and control um compartment size let's say we are building a ship one of the problems in the Titanic was how small uh the the unit of isolation is if you think about all of the controls that we have generally built um the controls are either you know the size of the host or the size of a domain or the size of a particular path in the domain or the size of a particular file or the size of a particular function or in this in the case of J Scrambler specific actions right and and you had the other example of CSP like you either allowed the whole script or you don't you block it at all like you you cannot have a smaller box for that exactly so the the smaller the size of the compartment the more control you have over exactly how much functionality you are allowing now there is a counter to this which is the smaller the size of each one of these compartments the larger the number of um the larger the complexity of the configuration is going to be but we can counter that by building additional tools that make it easier to configure these fine-grained compartments the second thing if we go back to the story of the Titanic that we need to keep in our mind is the strength of the isolation material now I'm stretching the analogy a little bit but essentially um when we build mechanisms for isolation like iframes like csb um if they are cut in the wrong direction we end up having to drill holes through them and like any structure if you start out with a solid structure but you continuously drill holes you start out with a ship but you build little rooms into them so that they are able to do what the functionality you require is then you end up weakening the structure in order to build the in order to maintain the strength of the isolation material in order to maintain the strength of the isolation mechanisms that we have we have to align with how developers end up using the software most of the mechanisms that browsers provide were built for web 1.0 which is a very different way in which applications were being built then the way in which we build applications today and sooner or later developers come up with ways of working around the the isolation mechanisms that we provide and the third one is of course visibility and user friendliness this is very very this is is a point that I was making earlier what you don't know may end up really hurting you you need to understand the nature of the attacks in order to understand exactly how attackers and your users are responding to to to to the mechanisms that you're building I end up sometimes saying to people developers are people too which is sometimes not obvious to us uh the user friendliness of the tools that we build is a very critical part of uh enticing developers to use our tools and to use the tools in a way that enhances the security of the application rather than being something that they need to work against and we are back to our Cliffhanger so basically we told you that the Titanic implementation was flawed and this is kind of a summary of some of the things we already said like for the Titanic the compartments were too big okay so they would need to have smaller compartments in order to be able to withstand more compartments being completely flooded because when you flood the compartment you flood the whole compartment if the hit is more precise maybe the the size of the thing that you're flooding is smaller and that makes you more resilient the the materials so the obviously it wasn't uh strong enough because like you hit an iceberg so it would if like if it was uh um made of like stronger materials maybe could withstand the hit uh the damage model had the wrong assumptions uh or in other words basically the threat model was wrong was was flawed and last but not least the lack of visibility because of obvious reasons if someone had spotted the iceberg in time they would not collide with the iceberg so uh visibility and analytics which are an interpretation of what you're seeing are very critical for avoiding these set of problems so now time for some demos and before and to understand the challenges we first need to understand what we have been doing wrong so as as for like browser security isolation native security isolation features things have moved slow and erratically um like I said we didn't have a feature one feature that could provide the type of isolation and user friendliness and like uh flexible enough um it has been mostly about stitching together all of these features that we talked about as for other Solutions beyond the browser native Solutions there are very few Solutions out there like Google kaha is a good example of a analystic web isolation solution but sadly it was discontinued which Jazz if you don't know he was the lead of that project back then at Google um apart from kaha there's web page Integrity the the one the the project that we are doing ah so what does the next 20 years look like given where we have come from what what we need is a single holistic client-side web solution that covers all of these different angles uh that we've talked about what we need is a sort of a broad coherent plan um and I think that those that plan will come together Guided by these three principles we've been talking about limiting the size and granularity of the compartments that we're building providing making sure that each one of these granular boundaries that we build are solid and reliable and then providing visibility and user friendliness so on the one side making sure the developers find these apis easy to use but also have these apis provide feedback so that as they are being used not only do we know whether developers are using them well but we also know when attackers are bypassing them when as we were making this presentation Pedro and I joked about uh how do you make a a ship that is actually Unsinkable uh and uh I think Pedro said you give it wings and you