The internet age and globalization of operations have seen the adoption of computing infrastructure to better facilitate organizations and people’s business operations. To facilitate this, web applications are used as the primary means of accessing and manipulating data distributed over various data centres. 

Despite their obvious advantages, security concerns remain as their major hurdle towards their full adoption. What are some of these vulnerabilities, and can they be addressed?

WEB APPLICATION VULNERABILITIES

A vulnerability is a weakness or hole in an application’s design that may be exploited by an attacker to cause harm to the application’s stakeholders. A stakeholder is any entity that relies on the application in any form.

The Open Web Application Security Project, a non-profit organization dealing with web application security, lists ten vulnerabilities that plague web applications.

1. Injection. This is a weakness that allows the addition of untrusted data sent to the application’s interpreter sent as part of a command or query. This allows the attacker to be able to access unauthorized data or execute restricted commands on the application.
2. Broken Authentication. This is a weakness in the authentication procedures that allows an attacker to masquerade as another entity through misconfigured session keys and passwords. This allows an attacker to assume another person’s identity temporarily or permanently.
3. Sensitive Data Exposure. Web applications may not properly secure user data either in transit or at rest. This will allow an attacker to steal sensitive data to commit credit card fraud, identity theft, or other malicious activities. 
4. XML External Entities (XXE). Poorly configured or older XML processors allow for the execution of external XML entities within scripts. These external entities can determine application structure and carry out attack vectors such as the denial of service attacks and internal port scanning.
5. Broken Access Control. Attackers can exploit improper enforcement of what authenticated users can access and carry out on a web application. An attacker can use these to view sensitive data on user accounts, modify user’s data, and access sensitive files. 
6. Security Misconfiguration. This is usually the result of using default configurations, incomplete configurations, misconfigured HTTP headers, and error messages containing sensitive information. All web application dependencies such as libraries, frameworks, and operating systems must be properly configured and upgraded in a timely manner to ensure the most up to date settings are used.
7. Cross-Site Scripting XSS. XSS vulnerabilities occur when a web application uses user-supplied input as an output on a new web page without proper validation and sanitization. Cross-site scripting allows a malicious attacker to execute JavaScript code on the user’s browser, which can be used to hijack user sessions, steal sensitive data such as login credentials and redirect users to malicious websites.
8. Insecure Deserialization. Deserialization is the process of converting data from a file or stream and rebuilding it into an object. Insecure deserialization is a vulnerability where untrusted or malicious data is used to exploit an application’s logic to carry out attacks. It can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks, or carry out remote code execution or denial of service attacks.
9. Using Components with Known Vulnerabilities. Components of web applications such as libraries and frameworks run with similar privileges as the application. Attackers can exploit the use of these components with known vulnerabilities to compromise a web application. Should they be exploited, they can cause untold damage to the application’s infrastructure and data, and these may undermine all other security policies that have been implemented in the application.
10. Insufficient Logging & Monitoring. A web application needs to be constantly monitored and logged in order to prevent repeat attacks and stop attacks such as a denial of service and session hijacking. In most cases, the time taken to detect attacks is normally more than 200 days on average and is usually done by external parties to the target organization. 

CONTINUOUS TESTING VS PENTESTING.

Two schools of thought are primarily considered to counter web application vulnerabilities, continuous testing and pen-testing. Continuous testing is the continuous testing of its creators’ application to ensure all security concerns have been addressed. At the same time, pen-testing is usually carried out by an external party to circumvent the existing security policies implemented on the application. While pen-testing is considered the most ideal as an external party will most likely find something overlooked, it is far more costly. There is a risk of sensitive data exposure to untrusted parties.  

How does one optimise for continuous testing?

Continuous testing is carried out early, regularly, and everywhere. In a continuous testing process, testing is done undisrupted continuously moving the software continuously from development, testing to deployment. This allows the development team to find the risk, address it, and improve the final product quality. In order to properly secure an application, continuous testing should be carried out in every stage of the computer development pipeline. Test suites should be set up at every point the web application code changes, merges, or is released. This allows the development team to run tests at specific points rather than running all the tests at once.

In order to carry this out, teams need to add additional modern testing practices in the form of minute quality checks. These checks are carried out throughout the application pipeline allowing for small sections of code in the application to be tested throughout the application’s development pipeline. Test automation should not be the first thing tacked due to test dependencies, which have to be satisfied before execution. 

This can be solved by dividing the process into two stages: continuous integration and continuous testing. In continuous integration, rather than waiting for all developers to commit their code, the code is merged into the main branch, built, and tested in a virtualized environment. This saves time in moving from the development environment to the testing environment. Should the test fail, the issues are reported back to the developers, and the process is repeated continuously until the production build is completed.