5 Security Concerns When Using Static Site Generators

Posted: July 20, 2017 by James Pavur


Static == Secure Right?

If you’ve read my recent post extolling the virtues of static site generators for secure web development you might think that deploying a static site makes you more or less invulnerable to cyber adversaries. Although it’s true that going static dramatically reduces your vulnerability profile, it doesn’t quite eliminate it.

This post considers five possible attack vectors against websites built with static generators (e.g. Jekyl, Hugo, etc.) and how to best protect yourself against them.

1) Vulnerable Hosts

Not a server you want to host your website on.

Not a server you want to host your website on.

One of the chief benefits of static sites is that they open up a wide range of non-traditional and serverless hosting options. That said, many reasonable people might prefer to self-host their personal website on a home server or cloud platform. Hosting a static site may create a false sense of security and encourage the owner to overlook systems administration tasks.

When hosting a static site with a full-fledged web server like Nginx or Apache, the overall security state of the web server itself remains important. Server-level vulnerabilities like directory traversal exploits or exploits which rely on malformed HTTP requests can still provide hackers a way to deface or maliciously modify your website.

Don’t think your boring database-free site isn’t an attractive target either. A popular static website with links can be a powerful tool in distributing malware, engaging in blackhat SEO, or building a botnet.

How to Fix

2) .git Leakage

A sneaky leaky octocat from github.com

A sneaky leaky octocat from github.com

Where’d you put the git repository for your static site? Is that url a publicly routable directory? Many tutorials encourage the creation of a .git directory inside the folder generated by your site for easy deployment.

You may think your .git folder doesn’t have any secrets, after all - it’s just the code for a publicly available site right? But an adversary can use the repository to view orphaned pages and files that haven’t been linked yet, read drafts and unpublished stories, or even flip through your site’s history and read content you’ve elected to delete for some reason or another.

Additionally, due to the ability for .git repositories to grow quite large over time, leaking your .git repository can turn into a significant force multiplier for denial of service attacks (see #3 below).

How to Fix

3) Denial of Service

An AWS user's worst nightmare.

An AWS user's worst nightmare.

A denial of service attack against a static website is much more difficult to execute than against a dynamic website. Static requests are far easier to handle than dynamic requests that require computational operations serverside.

That said, some of the most attractive serverless hosting options for static sites, such as Amazon’s S3 cloud storage option incur per-request charges and might create some unexpected financial charges at volume.

Imagine, for example, a very humble 50 Megabit/s DOS attack against your static site. All the attack does is sends GET requests to a static page hosting a 1kb file. Every hour your S3 bucket gets hit with 22.5 million requests. Running those numbers through the AWS Cost Calculator shows that this attack would cost you around $215 per day.

This sort of attack is a drop in the bucket from Amazon’s perspective and could go unnoticed and unmitigated for several hours. Even if it was noticed, an ornery adversary who just personally dislikes you could always run a rate-limited attack at a reasonable 1000 requests per minute and still up your hosting costs to nearly $1,000 per month.

A static site gives you few self-hosted mechanisms for limiting attacks. You can’t automatically block problematic IPs or suspicious clients. You can’t even set internal server limits to cause the server to stop responding to requests after a certain traffic threshold.

The scalability and affordability of static sites looks great at first pass. After all, serving an ambitious one-million legitimate requests out of an Amazon S3 bucket would only cost you $0.34 a month! Far cheaper than any dynamic hosting option.

However, if you approach static site ownership with a feeling of invulnerability you might quickly find yourself in an expensive and unfortunate situation. DOS attacks are a fundamental characteristic of the modern web and, although all-static gives you a thicker layer of armor, it doesn’t make you invincible.

How to Fix

4) External Injections

Reddiit.com: The end state of all weblinks someday.

Reddiit.com: The end state of all weblinks someday.

As your static site evolves, you may wish to pull in content from around the web in the form of links, images, even embedded javascript or html media viewers. This sort of content helps limit the ‘wall of text’ feel a long static article can instill (ahem) and makes a static site feel richer and more modern.

Unfortunately with new features comes new responsibility. A trustworthy link today can become a parked domain or malware host tomorrow. As the maintainer of a public site on the internet, you have entered into a sort of social contract to protect your users to the best of your ability yet weblinks and included files outside your control could quickly wreak havoc.

For example, Mario Henderich in 2011 demonstrated that .svg images could be used as a tool for cross-site scripting in some vulnerable browsers. If your site included an image like:<img src='https://evilsite.org/trustme.svg'> and evilsite.org turned out to not be as trustworthy as you initially hoped (!!!), you might find yourself inadvertently serving unseemly advertisements or even malware on your static site.

How to Fix

5) Unencrypted Traffic

A site with no encryption.

A site with no encryption.

This issue might seem a little odd. After all, static sites should not handle secret information - whether through AJAX API calls, or direct hosting, or pretty much anything else. If all of the information served by your site is public, why does it matter if the traffic is encrypted?

As I mentioned above, there exists an implicit social contract between a responsible web host and their end user. As a host, you have a moral obligation to protect the user from cyber threats to the best of your ability when they are viewing your page.

TLS does more than just conceal POST parameters sent to webforms. It functions as a critical protection of user privacy on the internet, allowing them to browse the web without the fear of eavesdroppers building a deep profile on the articles they read, the pages they visit, and the content they consume. Certainly some of the routing meta-data from your site will inevitably be available to ISPs and eavesdroppers, but encrypting whatever traffic you can is a common courtesy to your users and rarely takes more than a little effort and expense on your part.

Ideally, you can get your site registered with a legitimate root certificate authority and offer your own SSL certificates to users. This adds an additional layer of protection by providing non-repudiable guarantees that it is you serving the content to your users.

How to Fix

Recap

Security is not just for dynamic applications. When building a static site, remember to think about the content you’re hosting, the implicit promises you’re making to users, and the platform on which your site lives.

Static site generators promise to simplify the process of maintaining a secure web presence but don’t let simplicity lead to complacency. Keep abreast of security issues in the technologies you use and consider these five basic examples as a starting point for a lifetime of #staticVigilance.


Previous Next