Live data from Hacker News

Hardening Drupal with WebAssembly

wasmlabs.dev

11–20 of 52 posts

Re: Hardening Drupal with WebAssembly

#11

The article claims NASA use Drupal, which was quick to verify as true, but NASA also uses Django, or at least the Django project still claims they do. Why on earth are they using both?

Do you think NASA is some monolithic entity? If your company had a budget of 20+ billion dollars you might use two webframeworks.

Re: Hardening Drupal with WebAssembly

#12
post #4

No outgoing http requests, no ability to connect to an external database such as mysql- only SQLite is used. No explanation for what vulnerabilities standard Drupal is actually being hardened against.

> No explanation for what vulnerabilities standard Drupal is actually being hardened against. But... Are you not afraid of these unknown, not-yet-public vulnerabilities that this solution clearly protects us against?!

(Wasm Labs dev :)) For me, this is the key point. The end goal is to limit the attack surface for future vulnerabilities. This is not something specific to Drupal or PHP, but an example about technologies / apps that can take advantage of Wasm.

Re: Hardening Drupal with WebAssembly

#13

That article doesn't explain what the WASM code does in Drupal.

I think you missed this paragraph:

The Apache HTTP server and the Drupal packages remain unchanged. However, instead of loading the libphp.so extension module, it incorporates mod_wasm.so. In addition, instead of relying on the traditional PHP interpreter, it utilizes a PHP build in the WebAssembly binary format.

Re: Hardening Drupal with WebAssembly

#14
post #2

This article explores how Drupal can benefit from the capabilities-based security model offered by WebAssembly, a portable binary format that allows execution of code in a safe and efficient manner. By deploying Drupal within a WebAssembly-based stack, it gains an additional security layer, protecting against a wide range of vulnerabilities, including those that may not be public yet but can be preemptively mitigated…

> capabilities-based security model offered by WebAssembly What? Since when does WebAssembly natively ship with a "capabilities-based security model"? > protecting against a wide range of vulnerabilities, including those that may not be public yet but can be preemptively mitigated through these mechanisms Not yet public vulnerabilities? Who was this article/summary written by? Reeks of GPT or at least someone who doe…

Capabilities based means that by default Wasm cannot do anything with the outside world. You have to explicitly declare the specific access you are giving, for example if the runtime implements WASI filesystem access you need to specify which parts of the underlying filesystem will be accessible to the module

Not yet public means exactly that. You may have a buffer overflow issue in your code that you are unaware of. There are technologies that help mitigate those when/if discovered. Wasm is one of them but not the only one (ie most modern compilers have specific settings to harden the binaries against some issues)

Re: Hardening Drupal with WebAssembly

#15
post #2

This article explores how Drupal can benefit from the capabilities-based security model offered by WebAssembly, a portable binary format that allows execution of code in a safe and efficient manner. By deploying Drupal within a WebAssembly-based stack, it gains an additional security layer, protecting against a wide range of vulnerabilities, including those that may not be public yet but can be preemptively mitigated…

I'm 99% sure this was written by some flavour of GPT.

Re: Hardening Drupal with WebAssembly

#16
post #2

This article explores how Drupal can benefit from the capabilities-based security model offered by WebAssembly, a portable binary format that allows execution of code in a safe and efficient manner. By deploying Drupal within a WebAssembly-based stack, it gains an additional security layer, protecting against a wide range of vulnerabilities, including those that may not be public yet but can be preemptively mitigated…

I'm 99% sure this was written by some flavour of GPT.

Yes, sure. WasmGPT this time :-)

Re: Hardening Drupal with WebAssembly

#17

The article claims NASA use Drupal, which was quick to verify as true, but NASA also uses Django, or at least the Django project still claims they do. Why on earth are they using both?

   > Why on earth are they using both?
You lost the chance for a great pun here.

Re: Hardening Drupal with WebAssembly

#18
I took a quick look at the examples that come with mod_wasm module: from what I could see, the HTTP/WASM interface is based on CGI.

I kind of like it because CGI is architecturally elegant, but what about performance implications? By default, the CGI is not the fastest thing on Earth. Every time a HTTP request arrives, a CGI process should be initialized over and over again wasting CPU time on BSS section / runtime library initialization. Does it work any differently when it comes to WASM?

Re: Hardening Drupal with WebAssembly

#19

I took a quick look at the examples that come with mod_wasm module: from what I could see, the HTTP/WASM interface is based on CGI. I kind of like it because CGI is architecturally elegant, but what about performance implications? By default, the CGI is not the fastest thing on Earth. Every time a HTTP request arrives, a CGI process should be initialized over and over again wasting CPU time on BSS section / runtime l…

Or better PHP-FPM?

Re: Hardening Drupal with WebAssembly

#20
I used to work with Drupal, it was a security nightmare, like almost all community-based extension system (see also npm). Modules made Drupal popular, they also made it close to impossible to have any sense of security, as only very popular modules would be audited, and you basically needed a panoply of smaller ones depending on your use case.

I wonder if that's changed over time, for instance I could see GPT3.5 doing a good job of summarily inspecting modules systematically.

Post reply on HN