[StefanKarpinski]

"Little Johnny Tables". Um, yes, that was "Little Bobby Tables" [1]. Obviously not a big deal, but it seems emblematic of how sloppy this piece is. The article confuses – seemingly willfully, since Paul Vixie should know better – the concepts of dynamic language, dynamic page generation, lack of proper input hygiene, and various other orthogonal issues. The argument that dynamic languages are less secure depends an awful lot on the language – I don't think anyone is going to buy that C is more secure than Python. Haskell vs Python? Now that's a debate to be had. Certainly, websites that do no dynamic content generation are probably more secure – but then you're stuck with the Internet circa 1993. And of course, nobody is in favor not sanitizing inputs properly.

[1] http://xkcd.com/327/

[bnegreve]

> The article confuses [...] the concepts of dynamic language, dynamic page generation, lack of proper input hygiene, and various other orthogonal issues.

One of the implicit point of the article (that maybe shouldn't be implicit) is that these issues are not, in fact, orthogonal.

For example this:

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.

In other words, proper input hygiene is a problem because you're dealing with a language that allows execution of data (i.e. a dynamic language).

[codygman]

> Haskell vs Python (more secure)

If you mean comparing type systems there isn't much of a debate!

[StefanKarpinski]

I was talking about which is more secure. The real point is that this isn't a static vs. dynamic language issue: C and C++ are static and full of terrifying security traps; Haskell is static and it isn't. Since C and C++ are the most commonly used static languages, and they are much less secure than the most commonly used dynamic languages, it's questionable to claim – without additional elaboration – that static is more secure than dynamic.

[thegeomaster]

C++, especially when using features provided by the newest standards (C++11 and C++14), cannot be likened to C in terms of security problems. In theory, yes, it's backward compatible with C so any security issues present in C can be reconstructed in C++, but using managed pointers, standard containers, RTTI and other features can considerably reduce the attack surface... but I'd argue that not a great amount of applications could benefit from being written in C++ vs. some safer language.

[MaulingMonkey]

> using [...modern C++ features...] can considerably reduce the attack surface...

I'd argue the remaining attack surface is still wide enough to drive a shuttle crawler-transporter through. Even if your core code is perfectly tricked out with best practices, you're going to inter-operate with 3rd party APIs with C style interfaces at some point - and that means raw pointers, rolling your own containers / RAII wrappers, etc.

[feld]

Go outside and get some fresh air.

[tptacek]

I generally like your comments and this one is out place for you. What were you actually trying to say?

[feld]

He's trying to pick on Paul Vixie for such a irrelevant detail. The fact that he had to mention it to boost his ego makes the rest of his post not worth reading.

edit: I also enjoy the reaction of HN readers. It's fun. People take this site too seriously.

[tptacek]

Did you think Vixie's post was insightful or useful?

[feld]

Absolutely; he's right. You should not mix data and code. That's the reason why my own site(s) are all static, and my website does not look like it's from 1993. (just kidding, it does intentionally, but my blog is Pelican)

You can still write a static site that talks to a database and can accept form input for users to login and do things. It's not impossible. There's no reason to require every page view to be dynamically generated. We invented countless types of caching software to make dynamic sites as static as possible! Why is it illogical to rip out the dynamic piece altogether and use a static site generator for (nearly) everything? Why does every page view have to hit a language interpreter or virtual machine? It doesn't!

It shouldn't!

Do people believe that websites can't use databases without being dynamic? That's the only explanation I have here.

edit: I have seen the other end of the spectrum -- a 10 million line PL/SQL CMS that dynamically generates the entire website -- HTML, JS, CSS -- from an Oracle database. Even the static content was in the database as blobs! Everything served through the Oracle Application Server (Apache with mod_plsql or mod_owa, which rarely got updates) and had no chance of scaling well. But people paid out the ass to license it!

[tptacek]

My site is static too. I had... uh... a bad experience with Wordpress about 7 years ago.

I think most competent professionals know that you should use static sites when you can get away with them. Look how many static site generators there are:

https://staticsitegenerators.net/

(You can also go look and find all the tools that will render a static site from a hidden Wordpress install).

To me, Vixie's take here is not very interesting, nor is it very useful. If you're the type of person to learn something from an ACM post, and you have a dynamic site, chances are it's dynamic because it needs to be.

But then I'm a little biased towards reading this article as a "get off my lawn" piece, and that's not very fair either.

[yk]

Calling any Turing complete language "more secure" is probably nonsense. It is possible to write secure applications in C, and it is possible to directly pipe attacker controlled input to a shell in Haskell.

[tptacek]

I know a total of zero working security researchers who think C is just as safe as Scala.

The obvious flaw in your example: you can exec a program unsafely in both C and in Scala, but only in C can you do it accidentally simply by idiomatically copying a string from one place to another.

[yk]

My claim is not that C is just as safe as Scala, my claim is that the comparison is only valid if you do not think too hard about it. If you implicitly assume some web app, not too experienced programmers and a typical budget, then Scala is less likely to contain remote code execution bugs. But if you worry about timing attacks, then it looks a lot better for C.

[thegeomaster]

FWIW, idiomatically copying a string in C is done using strncpy, and that doesn't introduce any RCE bugs. I would not in my right mind defend the premise that C is just as safe as Scala, but the truth is that sloppy programming can do harm in every language imaginable. It just becomes about damage control.

[wglb]

Sorry, if you get the third argument of strncpy wrong, you are right back in the area of trouble.

[pbsd]

Even when you don't get it wrong (i.e., no out-of-bounds writes), you can still get out-of-bounds reads because strncpy does not always null-terminate strings. C strings suck.

[dezgeg]

To be fair, the real issue here is 'strncpy', whose destination argument does _not_ operate on C strings, despite that it's name starts with 'str'.

[StefanKarpinski]

Sure, you can do dangerous stuff in any language, but it's much harder to write a secure C program than a secure Python or Haskell program.

[wglb]

It is possible to write secure applications in C

Yes, but is it probable? History says no.

[bch]

History says that security is a process, not a product (or artifact). I get it that C can be difficult. Pointers allow NULL dereferencing and use-after-free, strings are open to poor handling, etc. That said: we have OpenBSD w/ their re-written string/memory management and static and dynamic analysis tools with decades of development behind them.

I'm more hesitant to crucify C than I feel others are... are we throwing out the baby with the bathwater ?

To your comment -- that a C program is probably not secure -- most code written (regardless of language) is probably junk, with different classes of errors. Its tough.

[wglb]

I was thinking of history as what actually happens as opposed to what should happen.

Assessing C#, code for example, you have at least two fewer entire classes of vulnerabilities to look for.

[jerf]

"Calling any Turing complete language "more secure" is probably nonsense."

I just wrote an article on a sensible metric by which you can do exactly that: http://www.jerf.org/iri/post/2942

A lot of people already knew that stuff on one level or another anyhow, but it's helpful to spell it out sometimes and bring subconscious feelings up to the conscious level.