I seriously don't get this at all. Are you saying you want to write web apps in C and compile it webasm to obscure everything?
-
-
the code on *their* domain (http://evil.com ) with the user's credentials (say, for http://bank.com ). The most obvious 3/
-
issue is Function.prototype.toString, which allows you to see the contents of any function. So the exploit is: be aware that 4/
-
http://bank.com/account.js contains authenticated, secret account data, <script src="http://bank.com/account.js "> on http://evil.com 5/
-
Now you might be thinking, this seems like an awfully obscure exploit. But if http://bank.com uses a module registry, that 6/
-
<script> will populate a global `__registry__` (or something like it) on *http://evil.com * but with the user's 7/
-
*http://bank.com * cookies. So basically, it's a bad idea to use cookies as auth to put secret content in a JS file. 8/
-
Even if you think you're safe, someone else can decide to switch to webpack and pwn you. So don't do it (put the secret in HTML instead) 9/
-
Given that, when designing <script type="module">, we should certainly *default* away from sending cookies across origins, and maybe 10/
-
we should just say that we provide no sugar for cross-origin credentials for *modules* (and that you'll need to use low-level primitives 11/
-
like Service Worker if you really want to shoot yourself in the foot). F.p.toString is one possible vector of the above vuln 12/
-
but basically anything that lets you hook into JS comings-and-goings is potentially subject to this kind of vuln. 13/13
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
