Audit your web application with this definitive 4-step guide

22 minute read · By Darren Beale

You know that web app you inherited? The one that sits there in the corner keeping you up at night. It hasn’t been properly maintained for years and you suspect (more than suspect, probably) that there are big issues with security vulnerabilities lurking inside. Worse still, you wouldn’t know what to do if it went down. And if that wasn’t bad enough, the original people who built and maintained it have disappeared into the digital sunset.

Step 1: Review the web application

The first step is reviewing the web application from a high level. By understanding the components, you can come up with a plan to address all of the potential security vulnerabilities, performance bottlenecks and other issues that can arise from an application that’s been ignored for while.

Architecture

Web application architecture ranges from monolith applications hosted on internal rack servers to micro services hosted on small cloud instances—and everywhere in between. It’s important to understand these details before making any changes and record the structure on a flow chart or diagram to use as a constant reference.

Many legacy applications are monoliths hosted on either internal rack servers or managed private servers. In these cases, it’s important to ensure that the operating system and any other software is kept secure and up-to-date. You may also want to look at server usage to see if CPU, RAM or storage capacity needs to be increased to handle growth.

Cloud web applications present different challenges. You may not know where different parts are hosted. For example, a single web application could use Amazon EC2 to host the application, Amazon S3 to host user uploads and Google Firebase for real-time messaging within the application. You may not even know the usage or costs for each of these services.

Some hardware architecture questions to ask include:

Do you have any on-premise servers?
What external services do you use for hosting?
What resources are available and consumed for each?

In addition to the hardware architecture, you should assess and understand the software architecture. The way code is structured can have a big impact on the maintainability of a web application, as well as any plans to update or upgrade it. Some web applications aren’t organized at all, whereas others may have a clean structure in place.

Some code architecture questions to ask include:

Does the code use a model-view-controller (MVC) paradigm or another standard?
How are web requests handled by the application?
How is the application loaded on the server?

The specific questions to ask will depend a lot on the type of web application as well as the languages or frameworks. For example, PHP web applications may range from CakePHP or CodeIgniter frameworks with a cohesive structure, to a single folder of files with each file representing a URL path.

Database

Web application databases come in many shapes and sizes, ranging from PostgreSQL to MongoDB to Redis, while many applications use multiple databases.

Start by cataloguing each database and the type of data that it contains. Next, determine if there are any performance improvements that can be made. For example, you may see that a database is very large, but doesn’t use indexes or relationships, which can degrade performance. Note these performance recommendations for future follow-up.

In addition to the database, you should check if the application uses an object-relational mapping tool (ORM). These solutions make it easier to securely execute queries against a database without worrying about low-level concerns. Many ORMs are also database agnostic, which means there may be an opportunity to easily switch database solutions.

Some database-related questions to ask include:

What are all of the different databases? How and where do they interface with the code base?
What is the size of the database? How many tables or rows in an SQL database or records in a NoSQL database?
Are proper indexes and other performance strategies employed to enable faster queries for SQL databases?
Are there any NULL values or other database design issues that could cause bugs for certain queries?

The answers to these questions could help identify potential areas where you could make performance improvements or eliminate common database-related application errors.

Third-party libraries

Web applications regularly use third party libraries that can introduce security and performance issues. While third-party libraries are unavoidable in many situations, it’s important to ensure they are secure and updated at all times.

The most important thing to look for is a dependency manager for third-party libraries, which serves as a single source of truth for third-party code that can be updated over time. For example, most Ruby applications use Bundler and Gems to manage dependencies. A single Gemfile in the application directory contains a list of each dependency and version.

Some dependency related questions to ask include:

Are there any dependencies that have been deprecated or are no longer actively maintained by the development team?
Are there any dependencies that are outdated by a major version where updating could break the application?
Are there any dependencies with known security vulnerabilities that could pose an immediate threat?

The answers to these questions could help you identify immediate issues that need to be addressed, as well as longer term issues that need to be fixed.

Testing

Software testing is a somewhat new phenomenon. By writing automated tests and running them before each new code contribution, developers can avoid introducing bugs that cause failure. Test-driven development (TDD) is widely considered a best practice for modern web applications.

Start by assessing whether the web application has test coverage, and if so, how much of the code base is covered by tests. Next, run the test suite to see whether the tests are still passing or if the tests have been ignored for too long and are failing. Even if they fail, these tests can be a helpful starting point for getting things back up to speed.

Some testing-related questions to ask include:

What kinds of tests are used? (e.g., unit tests vs. integration tests)
Is there a continuous integration server that runs these tests before a deploy?
What parts of the application are covered by tests?
What language and framework are the tests written in?

By assessing this test coverage early on, you can determine how much effort would be required to improve test coverage, as well as determine how confident you can be when deploying any new code.

Step 2: Assess security

Web applications face a wide range of security risks, so it helps to have a clear checklist of potential issues. The Open Web Application Security Project, (OWASP) provides these standards, which can be very helpful when auditing a web application for security issues.

Let’s take a look at each of the OWASP’s top ten risk factorsto see what kinds of security issues you should be watching for in your code base.

1. Injection

Injection occurs when untrusted data is sent to an interpreter as part of a command or query to trick it into executing unintended comments. For example, an SQL injection may involve a user inputting their own SQL query to give themselves administrative privileges in a web application and ultimately stealing data.

Some issues to look for include:

Validation for user supplied data.
Use of an ORM.
Dynamic queries without context-aware escaping.

2. Broken authentication

Improper implementation of authentication enables attackers to compromise passwords, keys, or session tokens. For example, automated brute force attacks can be used to try thousands of common passwords in just minutes to identify ones that work. These credentials can then be used to gain privileged access to the web application.

Some issues to look for include:

Lack of password rules and enforcement.
Storing passwords as plain-text.
Exposure of session IDs in the URL string.

3. Sensitive data exposure

Sensitive data can be compromised without extra protection, such as encryption at rest or in transit, including financial, health, or other data. For example, the transmission of sensitive data in clear text through HTML forms (e.g., using HTTP vs. HTTPS) could be intercepted through a man-in-the-middle attack on a wireless network.

Some issues to look for include:

Old or weak cryptographic algorithms.
Default crypto keys or insufficient key management.
Lack of secure data transmission (e.g., HTTP and FTP).

4. XML external entities

Old or poorly configured XML processes may disclose internal files on a server using the file URI handler, internal file shares or other attack vectors. For example, legacy applications with SOAP prior to version 1.2 may be susceptible to XXE attacks if XML entities are passed to the framework. These are more complex attacks that can be very devastating.

Some issues to look for include:

The acceptance of XML or XML uploads from untrusted sources.
Outdated SOAP frameworks (e.g., less than version 1.2).
SAML for identity processing for single sign on purposes.

5. Broken access control

Access control policies ensure that users cannot act outside of their intended permissions. Broken access control systems can lead to the disclosure, modification, or destruction of data by unauthorized users. For example, a CORS misconfiguration can lead to unauthorized API access to a web application, and ultimately, data theft or loss.