Presenter: Gal Weizman
Gal Weizman: So first of all, a little bit of background. The fact that we embrace composability driven development is great. We have web applications that are running on top of code of other people. And that is a great thing.
Gal Weizman: But naturally that also introduces security concerns. And when I think about it, these 2 security concerns can be splitted into 2 main aspects. The first aspect would be the build-time concern. So the build-time, you might know it as a supply chain and packages and dependencies, and the fact that an application is being built and bundled to be executed later in the browser. So a lot of maliciousness can be introduced at that point. And we are definitely concerned about that. But there is a whole different aspect, which is the runtime aspect.
Gal Weizman: We also know it as ads services and third party scripts in general. These are other ways to compose software which is not through the build time. And this basically happens on the fly in the browser, and is also a way to compose web applications. And that's also another way to introduce problematic security concerns and malicious code.
Gal Weizman: The motivation to that naturally is to try to come up with security tools to protect the runtime. So we're gonna focus on runtime, we're not gonna focus on the build time aspect, because obviously, the build time is definitely a problem, and there are a lot of attempts to secure that aspect.
Gal Weizman: By protect, that could mean a lot of things. We could try to observe and perhaps block behavior and access to sensitive operations at runtime. Whether it's network, DOM, storage access, these are things that we might want to to protect. We might want to limit in general the global environment in which the application is going to be executing in to make it maybe less useful for attackers. And in general, just like alter functionality and the environment, so that APIs are hardened and more secure. And I think this is a really important security layer, because there's just so many parts of applications. Traditional applications are being composed at runtime. So we have to find a way to protect these at runtime.
Gal Weizman: In reality, what this means is trying to apply some protection at runtime to the application. This would be an oversimplified example but it should give you the gist of it. Local storage is an example for a sensitive API where we might store sensitive information. One thing that these security tools are trying to achieve is to have some security layer on top of the getItem function for example, and make sure that the application still has access to items, if it has access to a predefined key, for example.
Gal Weizman: But then, if any malicious code has the ability to execute within the application, if it doesn't have the secret, they're not gonna be able to access storage. So this is just an example of like things that that security runtime tools can attempt to accomplish, to perform better security.
Gal Weizman: But there's a problem with that, and this relates to the same origin concern. Zb talked about same origin policies before, and this is a good place to talk about them also, because the browser is really good at protecting app realms from each other if they are cross origin to each other, which is great. Because we compose software that way. We fetch information and functionality from cross origins. And we wanna make sure that they don't have the ability to affect the main realm of the application. But the problem is that this naturally means the opposite. It means that if 2 realms are from the same origin they are completely trustworthy. and the way composability works today isn't really compatible with that, because nowadays, the way we compose software using supply chain and fetching scripts that run in the same realm as the application. They all run in the same realm. And we're talking about code that we don't necessarily know and trust.
Gal Weizman: And they all execute in one same realm. And therefore it doesn't have any protection against same origin realms. This problem undermines such runtime security tools almost completely. And I would like to demonstrate exactly how just for it to make sense.
Gal Weizman: So if we take the former example, you can see here 2 techniques to access the local storage on top of the mechanism introduced before. So the first one is the get local storage naively. Where we try to simply getItem and because of the security mechanism from before, and because of the fact that we don't provide the necessary secrets, we're getting a null value.
Gal Weizman: But the problem is that the bypass function can bypass that security mechanism very simply by just creating a new same origin realm and then reaching into that same origin realm instance of localStorage which is not being protected by the security mechanism by default. In this context, the way we create the same origin realm is by using an iframe.
Gal Weizman: This bypasses the mechanism almost completely. And this example easily extends on. I mean, it doesn't have to stop at localStorage. It could extend onto any security mechanism we're trying to apply. We're talking about DOM, we're talking about network access. We're talking about shaping the global object in the environment so that it's more secure. But if you can leverage yourself into another same region realm which is not protected by default, the security tools are going to have a really hard time protecting you.
Gal Weizman: Which is why I think the same origin concern matters. Which is why I want to talk about it today.
Gal Weizman: And I think, most importantly, even if this solution was perfectly secure, it would mean introducing a performance overhead, because the virtualization of the APIs that are protecting this problem just introduce a performance headache.
Gal Weizman: So based on the conclusions from the solution we've been working on, we have a few ideas. I think the main point is that we're not sure how the solution should look but the idea is that we want to be able to provide security against same origin realms for the application.
Gal Weizman: Just to wrap up. This is the proposal part. We have a general idea of what we imagine. I think we can leverage existing APIs in the browser to achieve this solution. And I think CSP is a really good candidate for that.
Gal Weizman: For 2 main reasons. The first reason is that CSP is already really good at enforcing rules onto realms recursively. It already does that perfectly. And that is exactly what we're trying to achieve with Snow. And what we want to be able to to to address this problem. And in general, CSP is just like an adequate mechanism for enforcing security policies in general. And this is a proposal for a security policy.
Gal Weizman: That is basically the idea. I think the bottom line is that I want the problem to be clear, and I want it to be clear that the solution is just an idea. We're not sure what it should be. This is just like a way for me to demonstrate what we had in mind. And we would love to discuss it.