
Go Static or Go Home - fiber
http://queue.acm.org/detail.cfm?id=2721993
======
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/](http://xkcd.com/327/)

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

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

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

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

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

------
normloman
I'm not concerned if a web app or a shopping cart is dynamic. But I see
dynamic blogs all the time. Blogs with no comment system, or one that's used
infrequently. What's the point of making that dynamic?

While I'm on the subject, can anyone tell me the reasoning behind loading blog
content with javascript? I hate when I visit a blog with no script turn on,
and get greeted by a blank template. Why does it need javascript to grab the
page content?

~~~
jordanlev
The point of making a blog dynamic is so a non-technical user can easily
manage the content via a dashboard. I'm a big fan of static site generators
(which is what I presume you're inferring people should use for blogs instead
of wordpress et al), but it is silly to think that uploading markdown files to
a server is a reasonable workflow for most non-programmers.

As for loading content with javascript -- I totally agree, this bugs the shit
out of me. Also, I browse with cookies disabled by default and it is always
frustrating when a site that is only serving content doesn't load properly
without cookies. wtf?!

~~~
normloman
I'm not advocating static page generators that use markdown. Far from it. I
used to use a blog platform called Movable Type. It was just as easy to use as
WordPress but it generated static pages. You'd make changes in the back end,
click publish, and Movable Type would generate a new static page to serve up.

You can make WordPress generate static pages too. They have plugins for that.

~~~
stevewilhelm
Six Apart's MovableType is still around.

[https://movabletype.org](https://movabletype.org)

~~~
sandymcm
I used MT for years. Versions 4 and 5 had various problems, coincidental with
various changes at the parent company, SixApart. (At one time they had three
blogging products: Vox, TypePad, and MT.)

I've been searching for a suitable replacement ever since MT 4. I tried to
switch to WordPress but hated it. Maybe just preferences, but I've never
warmed to WP, in spite of trying each new version that launches.

I see that Byrne Reese, former SixApart employee and co-founder of the MT-
based OpenMelody project, is now using Ghost.io for his blog. That's the
system I'm testing now as well. (Have used Tumblr in the meantime, with some
success.)

------
bikamonki
I've been an evangelist of static sites for a while. With over 15 yrs of
experience doing sites I started in static and saw the "dynamic movement" born
and grow (at some point I even programmed my own DCMS!); in most cases the
motivation to install a DCMS was that the client wanted to update content in-
house instead of paying a webmaster (a sound business idea?) but the reality
is that even when using a dead simple DCMS clients always find it difficult to
run it and still contact the webmaster. Furthermore, the vast majority of
sites are seldom or never updated so having the 'kick me' sign in those cases
is nosense. I guess a strong selling point of DCMS that made us all buy in
even knowing that it was a bad idea where themes and plugins! So many of them,
so nice looking, cross-browser tested and so easy to install. Clients where
über happy with the end product.

So a couple of years ago I decided to do static sites for ALL my clients
(there may be dynamic components that I normally implement with a back-end
data service). I still have a few dozen sites and web apps with DCMS but the
goal is to migrate them as well.

~~~
icebraining
The best mix may be a (hosted) dynamic editor that generates and deploys the
static site. Have you considered this solution? It probably won't eliminate
the need for a webmaster, but it should help reduce the requests for small
changes while keeping the benefits of the static site.

~~~
burke
I think I tried a blog engine once that did this. Maybe it was
[https://movabletype.org/](https://movabletype.org/) ? In any case, I really
wish more people/tools employed this strategy.

~~~
bikamonki
I think more devs will adopt it when we have plugins and themes that can be
installed with a click! So far I have been able to adapt HTML themes to a
front-end MVC (Angular or Backbone) but it is a long manual process...

------
gizzlon
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
software on your web server, rather than just returning the contents of some
files that were generated earlier._

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

It seems like hes real beef is with "dynamic" (vs staic) sites, but he keeps
mentioning CMS's for some reasons (ike you can't can have "dynamic" sites
witjout a cms)

 _> 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? :)

etc etc..

There's a case for static sites, but this post just confuses things.

~~~
anth1y
> 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](http://en.wikipedia.org/wiki/Paul_Vixie)

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

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

------
netaustin
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
consumed by a Node app, for example.

2) Shift any user-facing dynamic feature off the CMS. Commenting, login,
subscription management, etc., can be handled by purpose-built apps that tie
into the CMS-driven site via Javascript, preserving the security and
cacheability of the CMS.

That's not to say that it's impossible to drive a large-scale news site with
static files. I believe CNN does exactly that with their in-house CMS. But no
open-source CMS that generates static files is powerful enough to use in a
newsroom context, or popular enough to gain traction.

~~~
jamiesonbecker
It's simply a matter of inversion. Is the page generation and publication
performed upon each change (by editors/authors/etc) or upon each access?
Obviously, the former is much more efficient, even for frequent changes, and
even across millions of data points. (Just ask Twitter).

Just because we don't really have common, enterprise-grade authoring tools for
non-technical people that publish static sites anymore doesn't mean that it's
not the better way.

~~~
Retric
Sure we do, it's called caching.

There is a minimal difference between a webserver serving static pages and a
caching server serving static content. When you get down to it caching is
simply a more flexable approach to the classic (autoring tool) -> static
webpage approach. In many ways the only difference is the authoring tool is a
website not a stand alone program.

~~~
icebraining
Caching is usually done on demand, though, not ahead of time. That means the
dynamic portion is still launched by the request, which increases the
probability of security flaws being exploited.

~~~
jamiesonbecker
Exactly.

In other words, some fraction of the requests are responded to dynamically and
then the result is cached. That dynamic nature can be exploited. Site search
engines, etc, are also often (but not always) dynamic, server-generated
results that have a greater likelihood of exploits via XSS, CSRF, SQL
Injection, etc. Login forms almost always require server interaction and are
great targets.

(I say "almost" because REST interactions might be stateless and thus login
forms really just serve to generate an access token and verify that it's
working; this is how Userify works, for instance. It's still theoretically
more exploitable than pure static files, but it raises the bar quite a bit.)

------
andrewstuart2
A castle with no gate is also more secure. And kind of useless for its
inhabitants. Like being under siege all the time.

My point being, sure you can get a more secure `something` by making it more
and more static, but you'll probably cripple it somehow.

It's simply a balance you have to find for your use case.

~~~
jkot
There are castles with no gates.

I think problem is that current dynamic websites are sort of crippled already.
Right now even simple shopping app requires UI based on HTML + web. Not a
chance to use command line, some automated devices etc... In future we might
see radically simplified protocols/webservices for more universal access.

~~~
Diederich
I hear what you're saying, but it doesn't have to be so.

All of the web apps I make at work are all javascript in a page apps. But
before I start doing any of that, I make a REST API. 100% of the interaction
between javascript and the web server is REST.

There are many reasons for this, but a key one is that it allows _easy_
command-line or programatic interaction. Much easier than with traditional,
server generated web apps.

~~~
sbilstein
Same here. Increasingly products I work on do almost no server side
templating; frontend templates call REST services that I can test with curl,
postman, or other tools.

~~~
tsax
Are there any downsides to this design?

~~~
sbilstein
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 guess people who disable javascript don't get to use your site...but I don't
really care about that segment of the population.

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

------
buro9
I'd love to see how different people solve the highly dynamic plus static
problem.

This usually boils down to the shopping cart and checkout example... you can
always attack the checkout process as it is a unique, dynamic part of the
process that no web store wishes to ever be unavailable.

How does one "go static" with web applications that by necessity involve
interactions with datastores?

~~~
Arcanum-XIII
The idea is not that everything need to be static - some contents are by
nature updated too fast, or too often, to be static. Still, there's lot of
page that could be pre generated since the content of the datastore itself is
not evolving a lot. Most blog could use a static blog generator for example,
with the comment being the only dynamic part - and a lot of cms page too ! Pre
baking stuff is so much easier, faster, and cleaner.

~~~
chriswarbo
True. My personal site is static (generated with Hakyll), and uses Disqus for
comments (only because I haven't yet seen a simple, self-hosted alternative
which has been battle-tested).

~~~
oneeyedpigeon
I work on a statically generated site in which the comment form simply feeds
back into the generation workflow. It's certainly not 'battle tested', but it
has the advantage that a) we get to own the comments rather than giving them
to someone else b) everyone can partake in the discussion c) much less demand
on the client when rendering

------
icanblogshitz
There was a submission briefly on the front page here where someone was
proclaiming security by not using c/c++ for projects, yet, they left their
blog comments and site wide open for some idiots who have already tried to
post silly comments with JS popups.

I guess maybe we need people to use static sites, like trainer wheels on
bikes, until they become more security concious.

~~~
chriswarbo
Security is additive: the more precautions you take, the more secure you'll
be. Avoiding C/C++ when safer, higher-level languages could be used is one
example. Escaping Web site comments is another. Doing both is best, but either
on its own is still better than neither.

Becoming "security concious"[sic] doesn't mean outgrowing best practices. If
Bruce Schneier used "password" as his password, he wouldn't avoid getting
attacked just because he _knew_ it was a bad practice. Likewise, understanding
the tradeoffs between static and dynamic Web sites doesn't make someone's
dynamic site secure.

As the article points out, even a locked-down, well-tuned dynamic site with
CAPTCHA-protected registration forms is orders of magnitude easier to bring
down with DDoS attacks, since dynamic sites must perform more work per
request, eg. to render "Hello CaptchaFarmUser99999" at the top of the page. If
they _don 't_ need to perform more work per request, since all pages are
always fully cached, then you've just re-invented static sites :)

------
qeorge
Startup idea, free for the taking: create a service that "ossifies" dynamic
websites into static HTML.

(By ossify, I mean to take something dynamic and make it static).

For example, that WordPress site you commissioned for a movie 3 years ago? Its
a huge liability, but you don't have to take it offline - just ossify it. No
one is updating that blog anymore!

Under the hood, it would basically be a crawler, and the deliverable would be
a zip file containing a 1-to-1, static copy of their website with all URLs
still working. I suspect most folks here could whip up a shitty proof of
concept in 48 hours.

If someone does this, email me! I have a couple of potential clients for you
(I'm a former consultant, with lots of WordPress sites in my history).

~~~
juliangregorian
This is already a product that exists many times over. Besides the
aforementioned wget, I've recommended less technical users to SiteSucker, a
Mac/iOS app.

I'd be happy to bill your clients to do it for them though!

~~~
qeorge
Here's the thing: they don't want to run SiteSucker. That's only slightly more
helpful than telling them to just run wget!

They want to write a check and get back to business, not become a web
developer!

(I think that tool is awesome though, and I appreciate the tip!)

------
erikb
And there we have it. Security needs stability, stability decreases on a daily
basis. We can't have that traditional kind of security. We need to move on to
a more proactive way of thinking.

------
ivanhoe
Static site is more secure only if the server is also up-to-date and setup
properly to trim down all unnecessary options. Putting static site on a
general purpose apache installation that will happily serve PHP and CGIs from
user home dirs is not such a big security improvement.

------
k__
Also, in times of SPAs, LocalStorage, WebRTC, Parse and FireBase you can
sprinkle your static web-sites with some dynamic functionality, when needed...

------
faraazin
Noob qn:how does custom search work on static sites? May not be the best
approach, but a simple SQL query would do the trick for dynamic sites.

~~~
kstrauser
I used Google Site Search
([https://www.google.com/work/search/products/gss.html](https://www.google.com/work/search/products/gss.html)),
which starts at $100 per year. Outsource all that infrastructure to a company
who's good at it, park your static HTML on a CDN, and enjoy fast worldwide
access with searchable content.

That's not the only option, but it's a boss-friendly company to name drop.
Most organizations wouldn't blink at the price, especially if it means you can
move off dynamic hosting to far cheaper static hosting.

------
programminggeek
I'm going to say that the bigger problem in dynamic languages isn't that they
are dynamic. It's that they have weak, nonexistant, or very undeveloped
mechanisms for creating strong communication protocols that you can depend on
as safe or reliable.

Take the classic case of SQL injection. You have string input into your system
that turns into string input into a SQL query that turns into string input to
a database. That is dangerous because if you don't check on what the input
string contains, it might contain nothing, or a semicolon, or it might not be
a string at all!

We understand that putting a string direct into a SQL statement is dangerous
at this point, but we have yet to fix its root cause - nonexistant protocols
or boundaries in most code we write.

What a static language changes in that regard is compiler checked type
signatures on your code. That generally stops you from say passing an Integer
into something that needs a String. That solves a certain class of problems
for sure, and the complier does it for you every time you change your code, so
there is a convenience there.

What static typing doesn't give you is actual data correctness. Things like
buffer overflows or SQL injection can still happen with static typing. You
could use a language like Scala or Haskell to have stronger/more complex types
that would have more distinct notion of value correctness and at that point
the complier would be doing most of the work to ensure your program is
correct.

Leaning on a type system in that regard is basically turning your types into
the protocols that determine correctness in your system.

It is also possible to lean on stronger protocols that check messages in a
dynamic languages to achieve largely the same thing.

In the end, to write safe, high quality software, you need to define the
communication protocols between methods/functions/routines/services and
enforce them much as you would with an externally facing REST api.

The difference between a dynamic system with dynamic protocol checking vs a
static system with compiler type checking is the mechanism you are using to
enforce the protocol and how easy it is to interact with it.

Dynamic systems might be easier to interface with externally because you don't
have to understand a complex type, just pass a Hash/Dictionary sort of like a
JSON API, vs a static system where you need to use the right types and so on,
similar to a SOAP/WSDL API.

Performance is also a consideration, but really when you compare static vs
dynamic, it is important to understand that at the end of the day you can
write Ruby/Python/PHP that is functionally equivalent to C/C++/Java. They are
all ultimately going to be able to do the same kinds of things.

The tradeoff is in how they solve the problem and how well that fits with the
team writing the software.

------
__Joker
Interesting. Also if you are interested read
[http://programmers.stackexchange.com/questions/206558/why-
do...](http://programmers.stackexchange.com/questions/206558/why-does-the-us-
government-disallow-dynamic-languages-for-secure-projects)

~~~
danieldk
Did you read the article? It's about static vs. dynamic site generation. It
mentions eval() in a passing, but it's not about dynamic vs. static typing.

