Tuesday, November 26, 2013

Securing Rails, Part I - Web Application Security

Every organization must secure their web application irrespective of the technology platform and whether it serves HTML, JSON or XML. All web applications suffer from the same kinds of broken security. We see these security problems over and over again, so much so that those of us in the security industry have strong confidence in our career choice. Mind you, we would like to be put out of business, it just doesn't seem likely. Just look at the 150MM user account and password leak from Adobe this past summer. Why were the passwords encrypted and not hashed? Please don't mix the two concepts or misuse the two words - encrypt means you can decrypt. You cannot de-hash in Order(1) time.

I highly recommend reviewing OWASP's website and their tri-yearly top ten security issues list. If you go back over the top-ten lists since 2004, you'll find that problems trade places, but rarely drop off - code injection (backend server (SQL, OS, etc.) or web server (XSS - HTML, JS)), broken authentication/sessions (login protocol, session handling, Cross Site Forgery (CSRF), Redirects), broken authorization (direct object references, no function ACLs, private data exposed), misconfigured security.

Every web developer should familiarize herself with these common security vulnerabilities.

Rails has a specific security page that discusses common security pitfalls and how to fix them in the Rails platform. This covers session protection, code injection and security configuration.

Additionally, under the Ruby Toolbox, Security section, you may find a number of gems useful for protecting your application. I have not reviewed these in detail, so cannot make recommendations based upon experience. That said, there are a few gems that look promising.

Under Security Tools, developers have contributed some interesting gems. I'm a big fan of analyzers, they're cheap to run and, if they provide useful information, are great at catching problems. Their downside is they tend to generate a lot of chaff and very little wheat, so a vigorous analysis is often required. Brakeman and Tarantula look promising. Check the others out, too.

In addition, there are Captcha, Spam Detection and Encryption gems. I like the first two, Captcha tech is great for protecting user accounts from brute force attacks. Spam Detection, well, if you've got email, no need to explain that one. I would encourage you to take care with Encryption, mostly because it's easy to do it wrong and make yourself believe your more secure than you really are. Encryption is not a magic security dust to be sprinkled atop data and everything gets +24 Securons. Please consider this as a last resort and, preferably under an knowledgable engineer's direction.

Developers must hone their security expertise. Most security holes come from ignorance and a lack of creativity on the software author's part. Read some great security blogs. Educate yourself.

2 comments:

  1. I am very happy to discover your post as it will become on top in my collection of favorite blogs to visit. application security

    ReplyDelete
  2. I am thankful to you for this article because you are providing such good information about the web application as I see, thanks for this. Code U231748506

    ReplyDelete