Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Static or Go Home

queue.acm.org

Post reply on HN
Print view View original

101–106 of 106 posts

Re: Go Static or Go Home

#101

Post by bnegreve »

gizzlon wrote: post #95
bnegreve wrote: post #77

Earlier quoted context omitted.

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…

> 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 lit…

> 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

Re: Go Static or Go Home

#102

Post by bnegreve »

StefanKarpinski wrote: post #33

"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 a…

> 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).

Re: Go Static or Go Home

#103

Post by smhenderson »

gizzlon wrote: post #91
smhenderson wrote: post #53

Earlier quoted context omitted.

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...

Re: Go Static or Go Home

#104

Post by Diederich »

sbilstein wrote: post #87
tsax wrote: post #81

Earlier quoted context omitted.

Are there any downsides to this design?

Not really, you can achieve this using a Rails (or rails-like thing like Play) very easily and use in their built CSRF, SSL, etc. but this type of design also makes it easy to build from scratch (which may lead you down the path of reinventing things). SPA + restful endpoints makes it easy to pick a library centric approach vs. a framework approach but it certainly does not preclude you from using a framework. I gues…

I've also found it easier to secure my apps. The attack surface seems to be much smaller.

Re: Go Static or Go Home

#105

Post by yk »

tptacek wrote: post #56
yk wrote: post #48

Earlier quoted context omitted.

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.

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.

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.

Re: Go Static or Go Home

#106

Post by wglb »

bch wrote: post #66
wglb wrote: post #61

Earlier quoted context omitted.

It is possible to write secure applications in C Yes, but is it probable? History says no.

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 throwin…

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.

Post reply on HN