I'm excited about the prospects of web-assembly for the future, but I'm curious if this will have the same security ramifications of Java Applets.

What are some of the reasons why web assembly is expected to be more secure than Java Applets? (Isn't a sandboxed JVM in the browser similar to how web assembly might work?)

  • This link provides some of the answers you are looking for: github.com/stevespringett/disable-webassembly – pcalkins Jan 5 at 22:38
  • Interestingly, browser WASM support enables some code execution primitives for use with conventional browser exploits (e.g. against the Javascript engine), even when WASM code isn't used. – multithr3at3d Jan 6 at 0:03
  • I don't think anyone thinks it will be more secure than Java Applets or Flash... it's actually a bigger target because it's already built in to the browsers. On some of them you can't even turn it off. On a side note there are already countless sites who use it to mine digital currencies using your GPU power... – pcalkins Jan 6 at 0:40
  • Wasm is more like a way to speed up JavaScript than a way to offer more capabilities (if anything, Wasm code has less features). This is quite different from applets and Flash which were used to do stuff that you couldn't do with JS. Also, Wasm designers had the advantage of not being first – they could learn from the mistakes of precursor technologies like applets. – amon Jan 6 at 10:16
  • 1
    From an admittedly casual look at WebAssembly, the security situation looks much the same as jsasm rather than Java. Breaching its Object Capability Model, the 1.0 and 1.1 Java security models were essentially doing handwritten runtime deny list checks as if restricting linking to a few methods - a convenience method forwarding a call would break it all. I don't think anyone understands the implications of the Java 2 stack inspection security model. (It provided me with employment for nearly a decade.) – Tom Hawtin - tackline Jan 9 at 2:21

Java applets attempted to lock down a privileged standard library from within the process.

APIs like serialization and URLConnection were intended to work in both a full access mode (Java out of the sandbox) and untrusted mode (applets, web start). Privileges were determined by checking the caller’s class loader. This created an attack vector for gadgets: stringing together a sequence of API calls to trick a privileged Java class (say JEditorPane) into performing a privileged action on behalf of an unprivileged class.

It didn't work because the boundaries and responsibilities were unclear. Why was JEditorPane responsible for enforcing URLConnections security rules, only because it used the URLConnection APIs?!

My understanding is that WASM has no complex standard library that needs to work in both privileged and unprivileged mode. Avoiding that design mistake doesn't guarantee WASM security, but it makes it much easier to implement correctly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.