Web application security threats and countermeasures

Security is a game of constant catch-up. We are always trying to secure against threats while remaining agile enough to accommodate the unanticipated curve ball. Properly mitigating threats requires strong security considerations during development, deployment, and maintenance of a Web application. In this post, we’ll examine how maintaining focus on key threats to a Web application can help you stay ahead of problems, anticipating them before they occur.

Who is using your application?

Whether the application is internal or external to your organization, it’s important to consider who uses it. Not every user is technically savvy. Not every user comes to your application with honest intentions. Scrutinize every location where a user can interact with and submit information to the application. At best, a user’s mistyped input can cause an error and interrupt their experience. At worst, a malicious user can craft input to manipulate data within the application or give them unauthorized access.

There are several ways to counter problems caused by user interaction. Inspect all user input to the application via form fields, URL query strings, and any other means of interaction. This can reduce the risk of a user’s input causing serious errors in the application.

Where is your application hosted?

The application is only as secure as the server hosting it. A vulnerability within the server could be a gateway into application data or an entry point into your organization.

There are a number of factors to consider when examining the security of the server behind your application. Look out for news about zero-day attacks related to the server and any software versions that are running on it. Maintain a regular patching schedule to reduce the risk that these threats pose.

Another way to prevent an attacker from gaining access is to understand the configuration of your server and services. Then, make changes where necessary to bolster the security of your system. This includes ensuring that unique, secure passwords or keys are in use for all services running on the server. The default Raspberry Pi Debian image, for example, has the same SSH keys across all downloads. As such, it's important to regenerate these keys before use. Additionally, ensure that your server is configured so that the application is using SSL/TLS with secure ciphers.

What data are you exposing?

Data leakage can give an attacker critical information about your application and Web server setup. Armed with this information, they can create more targeted attacks against your application and increase their chances of finding a viable exploit.

For example, if the application server configuration sends the server version information via the server header within its response packets, and you are running a server version with known vulnerabilities, the attacker knows to spend more of their time focusing on exploits targeting known vulnerabilities. Without that information, the time it takes an attacker to find a successful exploit directly tied to the running server version increases.

Data can also be exposed within error messages that are too verbose. Configuring the server to display only information that the user needs to see prevents them from gleaning any additional information about the application setup. Usually a simple error message to users is sufficient. However, in some cases it may be unavoidable to expose some data about your application to users. Put thought into the potential risk this information could pose. Also consider what an attacker might be able to do if they are able to obtain that information.