Threat Vectors and Software Security: Securing the Application
In part 3 of this series on software security, we touched on some key security elements of your software’s environment. It’s important that your network is secure and that proper processes are in place to keep it that way. The last part to look at is the main entry point that can be most vulnerable because customers have direct access to it – the application itself.
In this article, we’ll again start big and work our way in. We’ll look at some basic configurations. Then we’ll investigate sanitizing and scrutinizing the data that is entered. Finally, we’ll review some best practices to secure your customers’ accounts.
SSL and Security
By now SSL should be a no brainer for your web application. An SSL certificate enables you to encrypt the data between the browser and the infrastructure. As your data flows over the Internet, it can’t be read by somebody trying to monitor the traffic. Modern browsers even warn you when you are using a site that isn’t secured via SSL. Obtaining a certificate is free and easier than ever, simply by using sites like Let’s Encrypt. Or if you’re in AWS you can use their Certificate Manager to provision an SSL certificate in seconds, again, for free.
Another piece of securing data transfer that you might not think about is between back-end systems. If you have APIs that talk to each other it’s a best practice to encrypt that data as well. Even if the applications are in an internal network, if someone were to get access to the network, they must work harder at reading the data going through it. The same goes for databases – internal APIs should communicate with your database over SSL.
Prevent Cross-Site Scripting
Cross site scripting occurs when an individual manages to inject code into an application and the application runs it. When this happens, the individual has complete control over the code and can do some malicious things. When taking input from a user it should always be “sanitized”. Sanitizing is a process of taking the input and ensuring it isn’t something that could create an exploit in your application. This typically means escaping certain characters.
A prime example of this is when eBay allowed scripts to be run on their site. At the time, eBay did this intentionally to provide a unique experience to their sellers – and it came at the cost of exposing their customers. Eventually eBay did the right thing and removed the feature but only after they were called out on it.
Prevent SQL Injection
Like cross-site scripting, SQL injection occurs when bad input is used to gain access to the database. When running SQL statements in your database, you sometimes take user data – like when a search occurs. Clever attackers with knowledge of SQL could expose systems and data by inputting SQL commands into text and other input fields. These commands could return sensitive user data or, in this famous XKCD comic, drop tables. Basic rule of thumb – don’t trust users.
This should be obvious, but your sensitive data should be encrypted. What this means is that instead of your data being stored as-is on disk, it is modified so it is unreadable to humans. You need a key to transform the data back into a readable form. Thus, if someone were to get access to your data they are left with a bunch of garbage without the key. Any place you store data – whether it be in a database or files on a machine – you should encrypt said data.
Send Only What’s Needed
Here’s an often-overlooked security vulnerability: when returning data, you should always be asking, “Should we send this?” For example, if your API gets an entire user model and returns it that’s probably a bad idea. It might contain identifiable and sensitive information that can otherwise be avoided. Each API should restrict the data it sends back, allowing only the most relevant pieces to be returned. Once the data has been sent to the browser it’s as good as exposed.
2-Factor Authentication Improves Security
With some basic best practices reviewed, we’ll look at some other steps you can take to ensure the security of user data. A common practice for securing a user account is 2-Factor Authentication or Multi-Factor Authentication (MFA). This is the process of asking your users to validate who they are beyond entering a password. You’ve likely seen this if you use an online banking app. This process asks the user to setup a way to get a code after login – such as texting or, ideally, a secure app like Authy. With these tools, when the user logs in, they are asked to provide a one-time code. This way, even if their password becomes exposed the account is still inaccessible.
Related to login, it’s a good idea to have smart analytics. Did the user try 15 logins in the past 2 seconds? Are these requests coming from an IP address located far away from where it usually is? These can be indicators that someone other than the actual user is trying to get access. Prompting the user to validate the login or letting them know a login occurred are good measures in protecting their accounts.
Use Salt for Passwords
Another best practice in securing user information is to add a randomly generated string, or “salt”, to a password prior to encrypting it. Now, even if the user is using the same password on your application as every other application (bad idea by the way), your application is taking steps to ensure the uniqueness of what’s stored.
So, why does this matter? Consider a situation where your password is compromised on some site. That compromised password can’t be leveraged elsewhere if all the other places are adding a salt. In effect, your password is different when salt is applied, even though you used the same password you always use.
Be Wary of Third-Party Libraries
Nowadays, there’s hardly an application that isn’t using third-party libraries. These are generally open-source libraries available for anyone to use, where the code is freely available to review. It’s best practice to check the libraries you use for security vulnerabilities prior to adoption. If a library is old and hasn’t been maintained, chances are good that it’s less secure.
Final Thoughts on Security
Your application is part of your business – and in some cases, a mission-critical part. It’s how your customers interact with you and it’s what differentiates you. It’s also a front-line vulnerability for protecting users from attackers and from themselves. By following best practices around data encryption and giving users options to better protect their data, you allow yourself the best chance at securing your business.
At the end of the day, security is a team effort. No one person can keep your company safe and your customers secure. From the top, down, security is part of everyone’s day-to-day. And your culture needs to live and breathe that consideration.