What can I do to increase security of a small open source application

Question

I've been developing a small CRUDish Ruby on Rails application on my free time for a non-profit organization. The app is already running in a small scale in Heroku.

Lately I've been thinking about open sourcing the application. There are many pros for this, eg. I already know a couple of possible contributors, and even my employer has shown interest in supporting the project in a couple of ways if it would be open source.

Normally I wouldn't hesitate with this kind of possibility at all, but the problem here is that the application stores at least somewhat sensitive information about people using it. I have a fear that as the project is small, and after all will always have just a limited amount of developer time and resources, open sourcing it would attract more malicious hackers than actual contributors. I don't want to harm anyone, and especially not the targeted users of the app, so even the slight increase in propability of a data leak worries me.

When thinking sensibly, I understand that

• As the app is very small, there is a very limited possibility that someone would actually try to attack it
• RoR gives me quite good and real-life-tested environment to build on top of
• Security through obscurity is mostly regarded as non-sense
• IMHO pros of open sourcing overweight the cons

I don't want this to became another discussion about Open Source vs Closed Source Systems. However to relief my mind, I'd like to know what can I realisticly do to minimize the possibility of an attack. So far at least these things have wondered through my mind:

• Use the latest Rails version, and apply all security fixes as fast as possible
• Purchase an SSL certificate and enforce HTTPS connections so that all data that users enter will be transferred encrypted
• Encrypt data at the database with a key stored in Heroku config vars. However I'm not so sure about this one, because after all, I have to trust Heroku, and as far as I understand, this would help only in cases where the actual database would be compromised. Or am I mistaken here?
• Beg some security company to make an audit to the application for free (as there is no $$ involved)

What else could/should I do?

Answer 1

Look up the OWASP Top 10 (which is the most relevant resource for your question) proposed by edvinas.me and the list of Web-oriented attacks covered by fel1x.

I don't have good advice for Web server security because I haven't done it in ages, but make sure you keep your servers up to date and that they run with only the privileges they need (separate OS account, no write access outside of their own temporary folders, and all other services on your machine should have a private account, /tmp directory and so on). Use encrypted connections for all logged-in users everywhere on your site, and store passwords properly!

You can improve the quality of your code by making sure that:

1. Input Validation: you verify the domain of all possible user input. You must verify length, type and structure e.g. for strings that you intend to parse later on. Be particularly wary of SQL injections and XSS attacks! See this page for some advice. Make sure to use parameterized queries for your database.

2. Access Control: you verify that whenever some form of user input is used to access data, access control hooks are in place to verify that this data is within the scope of the user's privileges. Much of this is done implicitly (i.e. your user has an ID associated with their current session and that ID is used to retrieve entries in a database) so it's not always obvious to see what would go wrong. Think in terms of how users could craft their input to access different data/code branches, and how you can ensure that this does not happen.

3. Bug Hunting: you actively try to crash your server, by using fuzz testing. You should look for generic HTTP fuzzers and do both naive fuzzing (the fuzzer will randomly inject errors in its requests) and more structured fuzzing (the fuzzer knows what packets should look like in your app and will instantiate parameters e.g. the advertised size of a packet, some POST parameters, etc.)

4. Code reviews: you should really have a third-party pentesting but I understand that you don't have the budget for it. You could ask potential contributors and users to review specific sections of the code and keep a track of which code hasn't been reviewed yet in your project. The people managing GNOME Shell extensions might have some good experience of this to share with you. Note that reviews will not address incorrect installations and server issues and probably not design flaws, usually only obvious bugs...

5. Documentation: since you're providing an app as FOSS, describe how to set it up securely in some documentation and distribute it along with your sources. Be open to criticism and help from other sysadmins and developers who think you're doing something wrong or not giving the best advice.

Answer 2

• Encrypt the database with a key and only store the key in memory
• Add common security headers. You can look at what other sites use (for example kraken.com) and use the same HTTP headers after reading up on them (short list: HSTS, nosniff, XSS protection, XFO, CSP)
• Test for XSS
• Make sure the RoR XSRF protection works
• Try to find a pentest company to do a pro-bono security review. Plenty companies do, for example cure53.de

Answer 3

Mostly you can follow OWASP testing guideline. There plenty of companies help open source security testing. One of the example SecureLayer7, try free open source pentest program.