Hacker News Reader

On the other hand, I don't really get your point.

> Sure, but guess how those pages are returned? By running code on the server..

Yes, but by running static code.

> > The web server executes no code on behalf of a viewer until that viewer has logged in.. > 1) Of course it does, 2) How do the site check your info without executing code? :)

Again, static code.

So his point is not that we shouldn't run code at all, but that we shouldn't run code that heavily processes user inputs, or worse, evaluate generated code as DCMSs sometimes do.

Of course you can argue the no code is truly static, because it depends on the user input, but I don't think this is what you're arguing here.

> of course you can argue [that] no code is truly static

what the hell is static code? Static has very specific meanings in different technical contexts (static pages, static allocation, static scoping, etc), but I've never heard someone refer to static code.

Can you give me an example of code that is and isn't static by your definition?

My understanding was that it referred to static vs dynamic linking. Since self-updating code is an attack vector.

Dynamicity usually refers to the fact that you can execute code that wasn't fully specified at runtime.

Lisp code is the stereotypical example of a dynamic programming language because it can update its own code while being executed.

On the other hand, compiled C code is static because the code is loaded into memory and cannot be changed during the execution (as a matter of fact, the memory pages holding the code don't have even have write permissions). Btw, you can make it more dynamic by enabling dynamic libraries or modules which make the whole thing less secure.

In a static program, you can only execute code that was originally provided (at least in theory), that makes it harder to accidentally execute a piece of code provided by the user as input.

Back to our problem: A dynamic website will typically take user input (e.g. the user name) and build a personalized view of the webpage for the user. To achieve this, the page will probably contain a SQL query with a 'name' field. If the inputs are not properly sanitized, the field can contain anything including SQL code. If the user is malicious, you have a SQL injection (i.e. the user can execute an arbitrary query). What happened is that you've executed code provided by the user.

So by "static code", you seem to mean "compiled executable code".

You can compile Lisp "code" to machine code, and there will be nothing dynamic about it.

Yes, indeed.

> Dynamicity usually refers to the fact that you can execute code that wasn't fully specified at runtime.

As in eval()'ing code based on user input? That's pretty crazy, and I don't think (hope) a lot of real world security problems are caused by that!

> Back to our problem: A dynamic website will typically take user input (e.g. the user name) and build a personalized view of the webpage for the user

But this has little to do with the language, right? Now we're are talking about handling user input, which can be dangerous. The OP seems to get this confused as well, which is one of the reasons I claim he's not exactly an expert.

A TLDR of the original article: "Handling user input can be dangerous, it's safer if you don't." But we already knew that...

As far as eval()ing user input, well, just grep your code for eval(), no need to change language.

> As in eval()'ing code based on user input? That's pretty crazy, and I don't think (hope) a lot of real world security problems are caused by that!

His claim is that the mere fact that the language contains an "eval()" function (which is a feature of dynamic languages) inevitably increases the risk.

Quoting: Most of the computer languages used to write web applications such as DCMS systems contain a feature called eval, where programming instructions can be deliberately promoted from data to code at runtime. [...] but when it is left accessible to unskilled or malicious users, eval is a recipe for disaster.

> A TLDR of the original article: "Handling user input can be dangerous, it's safer if you don't." But we already knew that...

I would say:

1. DCMS are bad for public facing webserver because they process user inputs with a language that supports function as powerful as "eval".

2. DCMS are bad for public facing webserver because they run slow interpreted which is "1000 times" slower and enable DDOS

> Ok, I understand that there's reasons for using static pages, but I don't get the feeling this guy really understands what he's talking about.

I think he might know a little bit: http://en.wikipedia.org/wiki/Paul_Vixie

None of the things on that wikipedia page makes me think he actually knows anything about web servers. Sure, he obviously should know about some of the things that make the internet work (BIND, cron, etc) but nothing on there has anything to do with making web sites. All of it is about the infrastructure.

Either this article is filled with intentional hyperbole, or this guy doesn't know what he's talking about when it comes to serving web pages.

Ordinarily I'd be bristling at a comment like this, but you are articulating some stuff --- a little rudely, but still --- that I believe about Vixie as well. I won't pretend not to have noticed and let you take all the heat. Paul Vixie's reputation among software security people is a little bit fraught.

Which is what makes the article so peculiar. He's either being exceptionally sloppy or...I don't know what the other options are.

Founder of ISC? Impressive! (But it doesn't make the article any better :)

Bash installed? Huh? Why Bash exactly? I feel mentioning jails or containers here would be more on point.

Maybe because of this? https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29

Maybe, but doesn't that require that the attacker can set ENV variables for the executed bash command? I'm sure it happens, but it seems unlikely to be a major concern for most dynamic sites?

(I'm not arguing against the notion that static sites can be more secure, just that the article is bad ;)

I don't know a lot about it but I do remember reading that if you are using bash to process CGI or bash is spawned by a process that is handling CGI then the env is augmented with variables containing the contents of the http headers sent back by the client - thus giving an attacker a way to add to the environemnt.

Again, I'm a bit sketchy on the details. We mitigated this on one server we have where it might have been an issue by simply disabling bash and sym linking sh to pdksh.

And, yeah, the article does seem a bit schizophrenic...