The Cost of a Cheap Cloud
1 blog = about $1 a month
So actually getting this blog in top notch state hasn't been a real priority of mine, but I have been continually working on it to provide better security and keep cleaning out the all the garbage UI in the original open source theme. Now being that this is a static site generated by Pelican and hosted in S3, there isn't a whole lot to secure on the server side, it's already about as secure as we can make it. But there are concerns about how the client side might be exploited.
Client side exploitation of a website usually involves cross site scripting or cookie manipulation through the browser, although those are not the only vectors they are the most common. To that end I've already decided not to use any cookies. For the XSS risks I've decided not to accept any explicit user inputs, such as comments, where a stored XSS could live. Instead I'm offloading that responsibility to a 3rd party that I'll automate into the blog at some point in time. I've also decided to implement a pretty standard set of security headers to get users browsers to help out with any reflected XSS attempts.
Note
For those of you that don't know what reflected XSS is, it's where the script is embedded in the URL request. So that someone could link to my site somewhere where they can store the script, with say <a href="https://blog.gatewaynode.com/<script>alert('Howdy')</script>/some-uri">Click This Link</a>. The end user just sees the "Click This Link" and not the script that might be executed. Careful what you click folks.
Which brings me to why the blog looked pretty broken for quite a while. One of those headers is the Content Security Policy which while really useful for whitelisting the functionality of a site it can seriously break things. The header is kind of like this ode to the flaws of the modern web. The CSP is a dangerous header to implement if you don't start with one in the beginning of any web project, it can severely break your website, as I did. Being that this is a static site hosted in AWS my options to implement the headers were basically only using an Edge Lambda to modify the origin request from CloudFront. Which is great, but not something I can really emulate locally. And not knowing enough about the Pelican local web server I went ahead and just implemented it in prod. I knew it was going to break the blog, but it's my blog not my employer's or client's. This turned out to be pretty useful at finding a lot more UI junk, nothing malicious like what I originally cleaned up from the open source theme, but still things to be fixed.
Anyway, tuning a CSP can be an intensive task with layers of brokenness that is either fixed in code or fixed in the CSP directives. Doing this in Amazon edge lambda's with cloudfront is painful, each revision taking 40 minutes or so to propagate out. So it took a lot longer for me tune the CSP than I originally intended.
In retrospect I should have been using BURP suite to intercept the local web server and just tuned the CSP header there before committing to the lambda. That would have allowed local development and been vastly faster than working in prod with a CDN that takes a long time to update. It also would have been faster than learning the local web server, which I still intend to do. But it wasn't intuitive to use BURP, which is an attack proxy, to perform a development task. But I just figured that out by blogging about it.
And people say blogging, especially in my rambling style, is a waste of time.
