Web Security

Web Security

Recently I was asked what are good practices for developing web applications and web sites. The reality is that this is something, which very often gets overlooked and unfortunately a lot of companies don’t pay enough attention to the security aspect until it is too late. In fact, that the moment you publish you app online to the world, you automatically open a pandora box where everything that is possible to happen, and will likely happen one way or another and it is only matter of time.

Depending on how serious you are about security you might end up doing a lot of work, but end of the day it is a lot about balance of cost and benefit. The two extremes are “rapid development with no security” or “maximum security, but much slower development”. And the reality is that there is no correct answer for everyone. Every organization has different priorities and different goals. For example if you are a bank, anything you develop better be absolutely secure and bullet proof and hopefully everything is done by the book, but lets if you are a start up and if you have to deliver something within a week or else you you are out of business, rapid development is priority number one. The reality is that both extremes have pros and cons.

I believe in the balance and that you still could have pretty secure applications without significant additional development time. But it is important to mention that no matter what if you want to have secure software you should write your software with security in mind every step on the way instead wrapping some security on the very end of the development cycle.

With all that said, one of the most important concepts that everyone should be aware is multi layered security. And the idea is really simple. You have to make each layer as secure as possible and with the idea that even if all other layers get compromised, this layer will not be compromised no matter what, and if you use this simple principle in your development you are mostly guaranteed to have very high security on your system.

Here is a compiled list of tips everyone should follow when designing a secure system:

  • Always do input validation for any kind of input
  • Always protect your api asserting that the user has permissions and privileges to do a particular action
  • Assume that just because something is not in the UI, it doesn’t mean that the user couldn’t still try to access a particular API, or just simply guess its existence!
  • Never store passwords directly in unencrypted form.
  • Always stored one way hashed passwords.
  • Never store sensitive information, like passwords in cookies.
  • Don’t display system error messages, stack traces etc, in case of exception to the user (use the logging mechanism for that!)
  • Any personal information even when stored in the db should be encrypted
  • Keep access log for all data, not just when something is updated or created, also but when it was RED and by WHOM.
  • Have records for the ownership for all data
  • don’t rely solo on SSL for transportation security, you should consider having additional mechanism of securing the transport (eg. the “heartbleed” attack will probably not be the last issue in SSL)
  • Before using third party  open source libraries, always check for security issues inside the library , if the lib doesn’t have huge community and if it is not actively worked on.
  • Use firewall, open only specific ports for communication
  • Use SSH keys for communication and even login and whitelisting for only certain IP-s
  • Find and protect the weak points in the system from DoS attack
  • Consider the use of challenge/response, temporary generated keys and 2step authentication
  • Always generate new encryption keys and admin passwords whenever you are moving an application to production.
  • Expect that someone who has access to the system could be vulnerable  and as a result he could make your system also vulnerable and try to detect and protect it.
  • Use test driven development
  • For sensitive operations use third party company to audit your security.
  • use owasp secure coding guidelines

Leave a Comment

Your email address will not be published. Required fields are marked *