The Rails core team takes security very seriously which means that we have a great foundation to build our apps on. Thanks to them, we didn’t need to focus on security vulnerabilities in our early stage of development. But the more code we write on top of core, the more we risk introducing a vulnerability into our web application.
The following practices were implemented over the last few months to increase the security of our app.
OWASP ZAP Security scans
Example of the alerts we got from ZAP
We ran security scans using OWASP ZAP. ZAP is effective at detecting vulnerabilities when used as a proxy. It can also be integrated into your CI tests to keep your security in check.
But be aware that ZAP will raise false positives sometimes. Take our SQL injection and path traversal flags as an example. These errors were raised but, by examining the parameters that triggered those alerts, we determined they were completely irrelevant to us and didn’t represent any threat.
Content Security Policy compliance
This was difficult to implement because we used to inject script tags to make our beacon work — CSP discourages you from doing this (see unsafe-inline). We were able to overcome that limitation and other restrictions (unsafe-eval) and make our beacon is CSP compliant.
The flexibility of RequireJS allowed us to bundle and provision all the required code without breaking any CSP rules. We also implemented functions that we sourced from third party libraries.
A good example is our analytics module within our beacon, take a look:
We used to inject the analytics scripts into the customer’s markup, that violated the unsafe-inline rule from CSP. A good way around this was to wrap those scripts into an AMD module so they can all be bundled together into the beacon. By doing that you comply with CSP and also get more control about when to call your third party scripts.
A good side effect of this is that our test environments are now more restrictive about loading and executing scripts.
Enforce stricter HTTP headers
Some HTTP headers were designed with the security of our apps in mind, under that premise it made sense for us to add them to our application. ZAP also encourages you to do this. It doesn’t take too much to do and you’ll get an extra layer of protection against XSS.
If you are running a Rails app I highly recommend installing the Secure Headers gem created by Twitter. Thanks to it we were able to include valid CSP headers, HTTP Strict Transport Security, X-Frame-Options, X-XSS-Protection, X-Content-Type-Options, X-Download-Options and Clear-Site-Data all in one gem.
Since secure_headers implements a railtie you don’t need to add any code, the new headers will be inserted as middleware.
Code patches and security scans weren’t the only thing we did — we also encouraged our teammates to take security more seriously.
Use a password manager
It’s ok to not know the “magic word”
Trust a password manager and stick to it.
It will increase the safety of your accounts and will periodically run security audits to check for duplicate passwords and leaked accounts.
2Factor auth on everything
2Factor auth provides an extra security layer to confirm the identity of a user. In the software realm it is composed of your usual security credentials and a confirmation code that is delivered to you via SMS or an authenticator app. This makes identity theft harder and puts you and your company in a better position to defend against this threat.
Keep your account recovery codes organized
You can kiss the codes but please, don’t mail them.
So, you have 2Factor enabled; but what if you lose your phone? It can take days to restore all your credentials through support and you may get permanently locked out from some of them. Print out your security codes and keep them in a safe place.
Turn on your VPN if you are on a public network
We know you love to work at Starbucks as do millions of other people. Unfortunately, public networks are often targeted by attackers who aim to steal data from you. Using a VPN will encrypt your data at a packet level and make sniffers completely ineffective against your traffic.
After reading through these recommendations you should have a good starting point for your own security audit. Personally, I think it’s a good idea if a new teammate runs the audit, in that way he/she can see which services the team uses and get in the good habit of caring about security.
I hope this walkthrough gave you some motivation to deal with security related issues within your stack or team. It’s an arduous task and requires the formation of new habits but it certainly pays off on a personal and organizational level.
Marín Alcaraz Córdova.
Follow me: @marinftw
Start getting Net Promoter Score feedback today. Signup for Wootric.