Realms Security [𝕏]
19 Nov 2022Originally posted on X
Now that we understand:
1. What realms in #javascript are;
2. Why they can so easily be maliciously utilized against #browser #javascript supply chain protections,
🧵 We can finally talk about the security field that doesn't get the attention it deserves - realms #security:
But first, if you missed (1) what realms in javascript are, I recommend reading What is a realm in JS?
And if you don't understand (2) why realms are such a security concern to in-browser supply chain security, I recommend going back to my previous tweet on that.
All set? Let's begin👇🏻
Back in the days, when building web apps was not massively relying on a never ending list of dependencies, in-browser web apps builders were mostly concerned about XSS attacks for client side security.
Since those are syntax based type of vulnerabilities that are exploitable via user input, defending against those required developers to become aware of them, and make sure the code they’re deploying isn’t vulnerable to such attacks by properly sanitizing user input.
But since then things have changed dramatically, and user input is no longer the only exploitable surface for executing unwanted code in web apps.
Nowadays, the number one way of achieving that is by breaching dependencies that such web apps rely on - and it is far more complicated to defend against than user input sanitation.
It’s so complicated, that there is more than just one approach on how to do so, and a very popular one which is taken by various companies is by defending javascript in real time in the browser.
You get what I’m saying? Unlike XSS attacks, it is now so hard to prevent unwanted code execution due to supply chain attacks, that a popular solution is to just wait for it to happen and defend against it live!
In my previous thread I give a very straightforward explanation on how such solutions look like, but generally the idea is to redefine the behavior of javascript and by that protect it against potentially malicious usage (doesn't click? go back to this 👉🏻 )
But what I also talk about there, is how such defense when only applied to the main realm (top window) is basically useless, because any protection that is applied to only one realm does not apply automatically to another - and that's a part most solutions fail to protect against
To put simply, if for example my biggest fear is that an attacker successfully accesses “document.cookie” API so I delete access to it completely, I’m still screwed - the attacker can always regain that access by creating a new iframe and grabbing its unique “document.cookie” API
That is how good old realms in javascript can be maliciously abused due to how browser javascript attacks evolved.
And that’s how the need for “realm security” was born - it’s the effort around securing realms so that attackers won’t be able to leverage them maliciously.
This is an abstract definition, because currently this is a very abstract concept - we only now start to understand the role of realms in the changing in-browser security ecosystem and that realms even require security due to how browser javascript security shapes up.
That is a security field I wish to define and further explore to eventually be able to improve the security of the web apps we use daily.
Realms security is a field I have been researching for months now, and Snow JS ❄️ is the first significant fruit of my long term research.
Super excited to introduce Snow in the next thread 😊
To follow my realms security research journey, best place would be https://github.com/weizman/awesome-javascript-realms-security where I cover everything there is to know about realms and {offensive/defensive} security of realms including best tools and practices
1. What realms in #javascript are;
2. Why they can so easily be maliciously utilized against #browser #javascript supply chain protections,
🧵 We can finally talk about the security field that doesn't get the attention it deserves - realms #security:
But first, if you missed (1) what realms in javascript are, I recommend reading What is a realm in JS?
And if you don't understand (2) why realms are such a security concern to in-browser supply chain security, I recommend going back to my previous tweet on that.
All set? Let's begin👇🏻
Back in the days, when building web apps was not massively relying on a never ending list of dependencies, in-browser web apps builders were mostly concerned about XSS attacks for client side security.
Since those are syntax based type of vulnerabilities that are exploitable via user input, defending against those required developers to become aware of them, and make sure the code they’re deploying isn’t vulnerable to such attacks by properly sanitizing user input.
But since then things have changed dramatically, and user input is no longer the only exploitable surface for executing unwanted code in web apps.
Nowadays, the number one way of achieving that is by breaching dependencies that such web apps rely on - and it is far more complicated to defend against than user input sanitation.
It’s so complicated, that there is more than just one approach on how to do so, and a very popular one which is taken by various companies is by defending javascript in real time in the browser.
You get what I’m saying? Unlike XSS attacks, it is now so hard to prevent unwanted code execution due to supply chain attacks, that a popular solution is to just wait for it to happen and defend against it live!
In my previous thread I give a very straightforward explanation on how such solutions look like, but generally the idea is to redefine the behavior of javascript and by that protect it against potentially malicious usage (doesn't click? go back to this 👉🏻 )
But what I also talk about there, is how such defense when only applied to the main realm (top window) is basically useless, because any protection that is applied to only one realm does not apply automatically to another - and that's a part most solutions fail to protect against
To put simply, if for example my biggest fear is that an attacker successfully accesses “document.cookie” API so I delete access to it completely, I’m still screwed - the attacker can always regain that access by creating a new iframe and grabbing its unique “document.cookie” API
That is how good old realms in javascript can be maliciously abused due to how browser javascript attacks evolved.
And that’s how the need for “realm security” was born - it’s the effort around securing realms so that attackers won’t be able to leverage them maliciously.
This is an abstract definition, because currently this is a very abstract concept - we only now start to understand the role of realms in the changing in-browser security ecosystem and that realms even require security due to how browser javascript security shapes up.
That is a security field I wish to define and further explore to eventually be able to improve the security of the web apps we use daily.
Realms security is a field I have been researching for months now, and Snow JS ❄️ is the first significant fruit of my long term research.
Super excited to introduce Snow in the next thread 😊
To follow my realms security research journey, best place would be https://github.com/weizman/awesome-javascript-realms-security where I cover everything there is to know about realms and {offensive/defensive} security of realms including best tools and practices