Web App Security Part 2: Digging Deeper

Dan Ivovich -

This is the second in a 3-post series on web application security. Be sure to check out Web App Security Part 1: An Introduction.

What is Your Risk?

When considering the security of your application and surrounding systems, it is important to understand the real risks for your application and environment. Here are some items to consider:

What Type of Data Do You Hold?

What is the value of the data in your system? What would an attacker gain by getting accessing it? It may be clear why you would be targeted. Ensure your security approach matches your risk. Ideally, don't keep things for which you don't want to be responsible (credit cards, social security numbers, etc.).

What Access Do Your Employees Have?

If an employee's computer gets attacked, or your employee is phished, what would the attacker be able to access? A server that is part of an internal network to which your employees connect opens up a much larger attack surface. A compromised employee computer that is always connected to an important server is a prime attack vector. As much as is possible, segment your network and resources so that servers are only accessible by the right people and only when necessary. Also, make sure your employees use strong passwords and are aware of common signs of phishing attacks (which is beyond the scope of this post).

Physical Security

With the prominence of cloud hosting, this one isn't thought of very often, but if you have servers in your office, consider what physical access to them might allow an attacker to do. Modern data centers have many layers of security — nothing you are likely to have in your own office.

Integration

Make sure that any service you partner with takes security seriously. Their security should we well documented, and they should clearly follow the best practices we’ve been discussing here. Claiming "great security" without specifying any details is always a red flag. True great security can be openly discussed; there is nothing secret about how to implement it. Deciding to work with a weakly-secured partner who has access to your data or system could be a huge weak spot in your infrastructure.

Authentication

Most applications make some effort to identify the users at the keyboard, and any system that doesn't authenticate their users probably has very little to protect. For the rest of this post, I'm going to focus on how to authenticate valid users of your system. The authentication mechanism of a web application is often the initial point of exploitation by those looking to do harm, while it is also an area that is often weakened by developers in the name of "usability." Let's review some important points regarding authentication:

Best Practices

  • Rate Limiting - Limit how quickly repeated attempts at entering a password can be made. You want to slow down a brute force attack enough to make it impractical.
  • Failed Attempt Lockout - After a certain number of failed login attempts, you can lock the account until a successful email validation loop is completed, preventing any further attempt by a malicious actor to force themselves into the account.
  • Password Reset or Lockout Email Expiration - When the password reset emails and account unlocking emails are sent, the links in those emails should expire, both after a certain amount of time and immediately if they are successfully used. You do not want a compromised email to instantly grant access via old password reset links.
  • OTP or OATH - One Time Password (NOT via SMS, more on that later) is a cornerstone of the Initiative For Open Authentication (OATH) and is a must for any high value accounts you are protecting. These use cryptography to ensure a unique token is generated that must have come from a device or application set up by the authenticating user. Now just knowing the password isn't enough, and that is a good thing.
  • Password Managers - This may seem strange because there really isn't much you can do to ensure that users make good use of password managers, but I mention it for a specific reason. Make sure you aren't doing anything that would STOP a someone from using a password manager. This is now explicitly mentioned in the latest guidelines from NIST.

A False Sense of Security

  • Password Complexity Requirements - These have been proven to do little to improve security, while they frustrate users or make them write things down or use the same password in multiple places. The latest guidelines from NIST focus on just making sure a password is long enough (greater than 8 characters) and is not a commonly used password (dictionary word, or password1, etc).
  • Time Based Password Changes - This just frustrates users and doesn't help. It is no longer recommended by NIST.
  • SMS Based Second Factors - The SMS ability of your phone was never designed to be truly secure. The latest NIST guidelines have removed the recommendation to use SMS for an out-of-band second factor for authentication.

The Heavy Hitters

  • Virtual Private Network (VPN) - This is a great way to control network access to your servers. It may not be practical for every user of your application to connect via VPN, but even requiring it for server administration can help. If your application needs to be very secure, and only accessed by a select group of people, then consider placing the entire interface to be only accessible via a VPN connection.
  • Certificates - Sometimes a username and password might not cut it when you need tight control over who can access your system. Not only that, you might want a 3rd party or complex vetting process to ensure the identity of each user. In those cases, you can authenticate users of your application through client certificates. This isn't very common, but it is an option.

Weak High Security

There is one really important thing to keep in mind: good security always comes down to the weakest point in your system.

Any weak point can give an attacker a foothold, leading to further compromise. Your system will only become more complex over time. A strong foundation of good security practices is crucial. Thankfully, a lot of these items are clearly explained in the well written NIST publication on Digital Identity. I highly recommend reading through this document, as it includes a lot of great information and clear detail on the right way to do things. Unfortunately, you'll immediately notice that so many applications either don't follow these guidelines or they take many other steps in the name of ease of use or in order to reduce support tickets so that they ultimately reduce the security of all those involved.

Similar to what we reviewed last week, the items discussed above aren't hugely complex, but it’s important developers understand them when designing and implementing a system that ensures web application security. During development and beyond, web applications require constant attention.

Next week, in our final installment on web application security, we'll review some of the ways that SmartLogic keeps security in mind when building applications for our clients.