Hacker News Reader

Comment by jameshart | Hacker News Reader

The biggest difference between a static site versus a dynamic one is security surface area.

A static site web server can only ever, worst case, be induced to serve the wrong files. And you can mitigate that by making sure the only files you put on the server in the first place are ones you want to serve.

A dynamic site can be induced to run code. It can be induced to return the wrong data from the database it has access to (passwords for example). It can be induced to modify data.

Wordpress breaches happen all the time. Nginx breaches don’t.

View on HN

I just want to straighten the perspective on things a bit.

Technically there's no web site that doesn't "run code". There's always code involved. It's code all the way down, from the web server to the file system drivers, the operating system and so on.

While it's true that static files reduce attack surface, we need to think deeply why is that, and design intelligent dynamic systems that have the security of static ones.

And ultimately it's about input, and how input is treated. It doesn't matter how complex code you run, if you accept no input, you can't attack that system. Of course with no input you can't even figure out which page to show. So there's always input, even for static sites. But I'm trying to point our attention to what's the major distinction here.

I think they were merely implying that the website codebase doesn't have anything executable. I can't imagine anyone reading HN thinks that serving websites, generally, doesn't require a giant pile of code at many levels. Sure it doesn't eliminate the server-side security concerns of the entire deployment, but probably would from the entire website codebase; many people run static websites in read-only caches. At that point, the security concerns are more in the system/ops/network realm than the site itself.

Sure. Heartbleed for example was a data exposure vulnerability that leaked data from the HTTPS stack, which exposed private keys and plaintext from other inflight requests. Any real world system that handles HTTP requests, at minimum, has to do some reading of config data, some reading of data to serve up, and some writing to log files.

The point is that a static web server does that and only that. A dynamic web server is one that does that and more.

Just to build on this, there are RCEs that involve overflowing headers; Go just had one not that long ago. There's plenty of inputs on a GET request. You still need to do proper security on a static site.

Or.. a commodity static hosting provider can do proper security for you.

I don’t tend to worry about the RCE risk of hosting files in an S3 bucket behind a cloudfront distribution. That’s someone else’s problem.

Commodity hosting with proper security is also available for dynamic website technologies.

> we need to think deeply why is that

That's because the nginx inputs have a much more homogeneous type than your random django-based system.

I'm not sure there's anything you can learn from that. Some use-cases just lead to more secure software than others, and this is a completely non-actionable piece of information.

As they said, it's attack surface. The static site does one thing; the Django site does more things. This is the use-case difference you're talking about: the more your code does, the more likely it is to have vulnerabilities. And it's actionable: make your code do as few things as possible.

Perhaps we could describe a dynamic website as being a static website + extra (i.e. the dynamic stuff).

As mentioned in the article, every dynamic website will also need some static assets (the .js files, images, etc.)

So, it seems like a dynamic website will always have greater attack surface area than a static one, by definition. It will have all of the static site surface area, plus some more.

----

I wonder if there is room for a language that is not as general as JS, but can still be used to add dynamism to a website. So, you don't have to be stuck in the "it's Turing complete, so we can't be sure it's well-behaved before running it" situation.

Perhaps CSS is kinda turning into that, these days.

Though maybe CSS will become Turing complete too, at this rate (:

> if you accept no input, you can't attack that system

But this is a side channel attack, right?

HTTP requests are input. Code Red for instance sent broken input.

A static web server can theoretically be induced to execute code because it still has parsers.

While I do agree a static site has a smaller attack surface, I think it’s more that nginx has way more eyes on it and a much slower development rate than your average custom configuration of WordPress plugins.

Because if you were to build your own static web server, your first version would probably more susceptible to attack than a stock WordPress installation.

This was my thinking as well. A website running application code will also require maintenance vis a vis updates to mitigate security holes. And that never stops.

You could theoretically never need to “update” a static site. There’s not even really a concept for it. Unless the target changes HTML versions, I guess.

> Nginx breaches don’t

Except when someone forgets to append a trailing slash on a location block with an alias directive.

Reply on news.ycombinator.com