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 a 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.
Some hardware architecture questions to ask:
- Do you have any on-premise servers?
- What external services do you use for hosting?
- What resources are available and consumed for each?
Some code architecture questions to ask:
- 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?
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.
Some database-related questions to ask:
- 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?
- Are there any NULL values or other database design issues that could cause bugs for certain queries?
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.
Some dependency related questions to ask:
- Are there any dependencies that have been deprecated or are no longer actively maintained?
- 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?
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.
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.
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 commands. For example, an SQL injection may involve a user inputting their own SQL query to give themselves administrative privileges.
2. Broken authentication
Improper implementation of authentication enables attackers to compromise passwords, keys, or session tokens. Automated brute force attacks can be used to try thousands of common passwords in just minutes.
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.
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.
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 unauthorised users.
6. Security misconfiguration
Security misconfiguration can happen at any level of the application stack. A server may still have default user accounts enabled, unprotected files and directories, or other unpatched flaws.
7. Cross-site scripting
Cross-site scripting occurs when attacks inject client-side scripts into web applications viewed by other users to bypass access controls.
8. Insecure deserialisation
Insecure deserialisation takes place when a web application deserialises hostile objects supplied by an attacker. This can provide the attacker with remote code execution capabilities.
9. Components with known vulnerabilities
Web applications have many different components, including libraries, frameworks and operating systems. When these components aren't kept up-to-date, they may be exposed to a wide range of security vulnerabilities. An outdated version of PHP could expose an application to known security risks.
10. Insufficient logging and monitoring
Logging and monitoring are critical to prevent potential attacks. Many breach studies suggest that the time to detect a breach exceeds 200 days.
Step 3: Check compatibility
The next step is running a compatibility check to see what might break if you update everything. Suppose you have a PHP web application running on version 5.6: the version is very old and no longer maintained and there are many known security vulnerabilities, which means you must upgrade, but you're not sure if the application will still work.
Language compatibility
Language compatibility represents how an upgrade in the web application's programming language or framework will impact its functionality. Many popular programming languages include migration guides between major versions.
The good news is that there are many tools that can help you uncover any compatibility issues. A good example is the PHP Compatibility Checker for PHP_CodeSniffer, which analyses your code base for compatibility with higher and lower versions.
Dependency compatibility
Dependency compatibility refers to the compatibility of various third-party dependencies with a different version of the underlying programming language or framework.
If the web application isn't using a dependency manager, it might be worth installing one as a first step to assist with compatibility issues.
Step 4: Run code metrics
The last step of an audit before coming up with an action plan is running some basic code metrics. These should provide insights into performance, complexity, error rates and other issues that can guide the upgrading process.
Three of the most important metrics:
- Cohesion of Methods (LCOM): measures the number of responsibilities of a class. In an ideal world, this metric should be equal to one in order to adhere to SOLID principles.
- Maintainability Index: measures the maintainability of any project by looking at lines of code, complexity and the number of commented lines.
- Halstead's Difficulty: looks at how difficult the code is to understand by assessing the software's vocabulary and length with operators and operands.
Application monitoring
Application monitoring is also a great way to assess an application's performance, identify any relevant bugs and prioritise what needs to be fixed. Many popular application monitoring platforms provide real-time alerts for errors driven by actual usage.
Step 5: Compile recommendations
The final step is making recommendations based on the four areas involved in the audit. These recommendations will ultimately serve as the guide that you can use to upgrade the web application and bring it up-to-date.
- Architecture review: a manifest of hardware and software architecture that can be used as a map for future work.
- Security review: a list of security issues sorted in order of severity. Urgent issues should be fixed immediately, medium-risk issues scheduled in the near-term, low-risk issues fixed as time permits.
- Compatibility review: highlights the extent of language, framework, and dependency compatibility issues and a plan for resolving them.
- Code metrics review: lays out the performance, maintainability, and error rates as a baseline that can be improved upon over time.
Should you outsource the audit?
The auditing process is complex and time-consuming, which makes it a natural candidate for outsourcing. In addition, hiring an expert can ensure that you don't miss any crucial components of the audit, such as a hidden security vulnerability or minor language change that could come back and cause issues further down the road.
For PHP web applications, Siftware provides an extensive and affordable security and performance audit solution designed to help you understand everything that needs to be done and come up with a clear plan of action. The deliverable is a single PDF report that clearly outlines all of these key areas and includes actionable recommendations that you can start implementing immediately.