Oct 2, 2020
OK, it is time to learn a little about security for this website. The Mozilla Observatory is a website security auditor and a great place to get started. And I started... with an initial grade of D+. Ouch! The tool told me I needed to implement the following:
One thing at a time, I'm starting with the CSP. But first, the type of attack these things are trying to prevent.
The term "cross-site scripting" is a bit outdated in that it originally referred to attackers serving an evil website when a user visits a trusted site. They think they are interacting with the trusted site but no. Today the term has a much broader meaning where malicious code is executed by the browser because it seems like it is coming from the trusted domain. A typical XSS attack happens when you have an input field, such as a search box for your website, that does not properly check the input before using it. Instead of putting in something normal and expected, the attacker puts some malicious code into the field that gets executed. Often the result is that the attacker is able to expose sensitive information and steal the identity of the user.
Angular does a lot to prevent XSS, including sanitizing any input to check for malicious code. As long as you don't try to bypass the built-in security you are already pretty good. But a Content Security Policy can make XSS even more difficult.
To learn about CSP, I recommend this Google CSP tutorial and an article on Locking Down Your Website by Troy Hunt. The promise of a CSP is that it will allow you to identify the code that you trust and disallow any other code from running. In practice, the identification process is a bit tricky and not usually implemented in a way that prevents XSS attacks. Of course nothing is guaranteed to prevent, just like there is no security system that can guarantee to prevent a household break-in. Security takes careful consideration of your particular situation and needs, adoption of best practices, and periodic review. The good news is that if you don't have a site that requires logging in or sharing sensitive information, XSS attacks are not as big a threat. Still, it is good to implement on early on and be thinking about security as you add to your site (eventually I want to have a searching function, and I currently have an i-frame).
An article by Roger Grimes gives this definition of a hash:
A good cryptographic hash function is a mathematical algorithm, which when run against any content (e.g. document, sound, video, picture, etc.) will always return a unique output result (often called a hash or hash result) for unique input content. No two differing inputs should ever return the same hash output and identical inputs should always result in the same output. Using these cryptographic properties, a hash output can be used on two differently submitted inputs to see if they are identical or not. Cryptographic hashes are the backbone of almost every digital authentication and integrity process.
The SHA-2 hash of that quote is 38cf858b3c048fe44e825fc42ed61be0b4547207c4cf6d90490add90db7f2ec9, to give an idea of what they look like. The thing about a hash is that you can know the hash (the output), but you are not able to use it to figure out the input. So you could write a script for your website, calculate its hash, and put the hash in your CSP (which is public) with the rule that any script with that exact hash is allowed to run. The Google CSP tutorial says that hashes are the preferred way of allowing scripts in the CSP for static sites like mine.
An alternative to a hash that could be used for web apps or sites with dynamic scripts (whose hashes would be always changing) is a nonce, which is short for Number used Once. You get your server to generate a random string that looks like a hash every time the page loads. Assign that number to a variable, and put that variable as an attribute in the script tag you want to allow. Note that unlike with a hash, any script with the correct nonce will run so it is less secure than a hash.
With that background, now I will go off and actually implement a CSP in Netlify, which is hosting this site. The next post will report how it went.