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

91–100 of 106 posts

Re: Go Static or Go Home

#91

Post by gizzlon »

smhenderson wrote: post #53
gizzlon wrote: post #30

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. > Even if [..] and there's nothing like bash installed on the same computer as the web server Bash installed? Huh? Why Bash exactly? I feel mentioning jails or containers here would be more on point.. > This is because every DCMS page view involves running a few tiny bits of s…

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

Re: Go Static or Go Home

#92

Post by dezgeg »

tptacek wrote: post #90
dezgeg wrote: post #88

Earlier quoted context omitted.

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

We can repeat this subthread with examples of UAF bugs, which are equally common, if anyone really wants to get the full flavor of how wrong it is to suggest that C is comparably as safe as Haskell.

My post wasn't meant as disagreement on the issue of whether some languages are safer than others. I apologize if this is is how the message was received. I was trying to point out that w.r.t. C strings, using strncpy is almost always the wrong thing to do.

Re: Go Static or Go Home

#93

Post by betenoire »

bnegreve wrote: post #77
betenoire wrote: post #58

Earlier quoted context omitted.

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

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…

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.

Re: Go Static or Go Home

#94

Post by gizzlon »

klibertp wrote: post #72
Xorlev wrote: post #39

Earlier quoted context omitted.

I think he means that you can cache the majority of the page (including the HTML template) and then substitute in just the data (usually coming from JSON). I don't buy that it's more efficient personally. I'd rather resend a lightweight page on every time then force the browser to download it all, load the JS, then build a page and have the browser draw that. It seems to me that single-page apps are great when you ar…

There's one technology, available everywhere including most toasters, which allows you to do this (cache HTML template and just substitute the data) and it can work on both back- and frontend with no problems, is crazy fast and even leaves you with something readable when it breaks. It's called XML with XSLT. Somehow it isn't very popular. But hey, we got this idea of "rendering pages on the backend or the frontend (…

> It's called XML with XSLT.

But that can only generate XML/XHTML, right?

Also, fast compared to what? Many options are fast if all you do is replacing some values. Static pages can just be written out from memory or disk, a whole nother level of fast :)

Re: Go Static or Go Home

#95

Post by gizzlon »

bnegreve wrote: post #77
betenoire wrote: post #58

Earlier quoted context omitted.

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

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

Re: Go Static or Go Home

#96

Post by gizzlon »

anth1y wrote: post #31
gizzlon wrote: post #30

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. > Even if [..] and there's nothing like bash installed on the same computer as the web server Bash installed? Huh? Why Bash exactly? I feel mentioning jails or containers here would be more on point.. > This is because every DCMS page view involves running a few tiny bits of s…

> 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

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

Re: Go Static or Go Home

#97

Post by tptacek »

dezgeg wrote: post #92
tptacek wrote: post #90

Earlier quoted context omitted.

We can repeat this subthread with examples of UAF bugs, which are equally common, if anyone really wants to get the full flavor of how wrong it is to suggest that C is comparably as safe as Haskell.

My post wasn't meant as disagreement on the issue of whether some languages are safer than others. I apologize if this is is how the message was received. I was trying to point out that w.r.t. C strings, using strncpy is almost always the wrong thing to do.

Oh, sorry, I didn't mean to sound like I was snarking at you!

Re: Go Static or Go Home

#98

Post by jacquesm »

netaustin wrote: post #13

High traffic and high volume sites driven by CMSes, like newspapers, tv stations, etc., largely cannot rely on static files to deliver their content. Rather, they use caching layers for speed and security. There are two better ways to improve security for sites like these, which are highly targeted and poor candidates for static sites: 1) Use a headless CMS. WordPress on the backend that provides and API which is con…

News is about as static as it gets.

Re: Go Static or Go Home

#99

Post by klibertp »

gizzlon wrote: post #94
klibertp wrote: post #72

Earlier quoted context omitted.

There's one technology, available everywhere including most toasters, which allows you to do this (cache HTML template and just substitute the data) and it can work on both back- and frontend with no problems, is crazy fast and even leaves you with something readable when it breaks. It's called XML with XSLT. Somehow it isn't very popular. But hey, we got this idea of "rendering pages on the backend or the frontend (…

> It's called XML with XSLT. But that can only generate XML/XHTML, right? Also, fast compared to what? Many options are fast if all you do is replacing some values. Static pages can just be written out from memory or disk, a whole nother level of fast :)

No, XSLT is perfectly capable of generating plain text, which means it can also generate JSON, YAML or what have you. It's true that generating malformed XHTML would be rather hard, though.

As for fast: compared to any other templating engine for server side languages. It was very long ago when I tested this, but for rendering a simple blog page XSLT with lxml (so completely on the C side) was much faster than Jinja2. I suspect only things like Mustache would have a chance here, but then again: XSLT is Turing-complete (probably accidentally, but still).

And that's before taking into account that you don't have to do rendering server-side at all - you can just serve static files and rely on the browser to render them. I don't know if it would be faster than serving static files and rendering with JS, but it has one advantage: it works even for people who have JS disabled.

There are many problems with XSLT, though. XSLT 1.0 is almost unworkable and XSLT 2.0, while specified, is nonexistent: nobody bothered to implement it. Once you start using implementation specific ways of extending it, you lose the benefit of being able to render on a client. Turing completeness can be a trap, too: you can code infinite loop in XSLT, and good luck debugging it (or even recognizing where do you loop in the first place...).

Still, XML and XSLT are a very nice technology, which should be used much more often. The problem, I suspect, is that XML is "yuck" nowadays, which means no one wants to use it, learn it or improve it.

Re: Go Static or Go Home

#100

Post by bnegreve »

betenoire wrote: post #93
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…

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.
Post reply on HN