In the early days of the internet, most webpages were static, informational resources. As the internet matured however the power of the web to deliver richer content was leveraged, and static web pages were increasingly replaced by the adoption of dynamic web applications. Web applications deliver interactive experiences and often underpin vital commercial operations for businesses such as portals allowing customers to self-administer various account details, through to online retail sales, online banking, and more recently interactive online spreadsheets, project management, and customer relation management (CRM) tools.

These web applications leverage technologies such as AJAX (“Ansychronous JavaScript and XML”) and HTML5. With AJAX, web applications can send and retrieve data from a server asynchronously (in the background) without interfering with the display and behaviour of the existing page, behaving almost the same as a locally installed traditional (compiled) application installed as an executable on a personal computer. By decoupling the data interchange layer from the presentation layer, AJAX permits web applications to update displayed content dynamically without the need to reload the entire page, and underpins the delivery of the recent Single Page Application phenomenon.

All these usages mean that the platforms that underpin and deliver web applications necessarily store and grant access to significant volumes of customer, financial and other data. Security breaches on these kinds of web applications are a major concern because they can involve both enterprise data and private customer data.

How is a web application constructed?

In order to understand how a web application might present specific and serious security concerns, it is important to understand how they are constructed.

In their most common form, a web application is generally constructed based on a model involving three “tiers” or layers known as the presentation, application, and storage layers. Each of these layers delivers specific functionality and crucially each must communicate with and pass data between it and the other layers. Even when carefully designed, these boundaries between the various tiers often introduce security weaknesses if errors are introduced in how data is passed between each layer.

1. In a web application, the user’s web browser forms the first tier (presentation layer) and displays (presents) information to the user, as well as taking input from them and communicating via HTTP protocol to the application layer on the web server;
2. The middle tier (application logic) consists of code or libraries that act as a dynamic engine using dynamic web content technology such as ASP, PHP, or Ruby on Rails. It forms the application logic, making decisions on whether requests from the presentation layer are authorised and how they should be routed, handled, processed, and responded to; and
3. A database forms the third tier (storage). It contains and controls access to all the data that the web application may need in order to handle requests and build responses to return to the client.

Errors in how any one of these layers is implemented can lead to security weaknesses being introduced in the application. Web applications are typically exposed to the Internet by design, at least in part, and security-related problems caused by errors in the program’s logic, implementation or configuration can therefore be exploited by a potentially unlimited number of attackers situated anywhere in the world.

Web applications by their nature are dynamic, and their complexity of functionality means that they have what security researchers term a large “attack surface” – the number of all possible points, or attack vectors, where an unauthorized user can access a system and extract data. The richer and more complicated the attack surface, the more potential areas for errors to be introduced, and the harder it is for an organisation to gain assurance that the web application is secure. Because of the sheer amount of data in modern web applications, and the difficulty in ensuring that they are suitably secured, web applications continue to be a prime target in attacks for malicious hackers.

What is the impact when something goes wrong in web applications?

A single flaw or software weakness in a web application or its framework can allow an attacker to either partially or completely compromise a server and the data that it stores. If a web application is not secure, this can lead to numerous issues including data breaches, loss of website control, and even fraudulent transactions. Security weaknesses are often expressed in terms of their impact on the “CIA Triad”, a term used to describe the three key metrics or principles of security delivery, and any failure which constituted a security breach or incident. The CIA triad consists of:

• C – Confidentiality – an organization’s efforts to keep their data private or secret. In practice, it’s about controlling access to data to prevent unauthorized disclosure. Failures to ensure confidentiality are often expressed as “data breaches” and can involve the theft of private or financial data. This is perhaps the most considered form of security weakness, as well as the most widely reported type in the general media.
• I – Integrity – the ability to ensure that records are accurate and have not been tampered with and can be trusted. A prime example would be the case of customer bank balances and transaction history in an online banking system – the accuracy of the data is essential to the provision of the service to the user as well as in the organisation’s own interest.
• A – Availability -whether the web application is actually available and able to serve customers. It is important for all web applications, but a vital example might be an e-commerce or web sales platform. For many businesses this may provide their primary (or indeed only) revenue stream), so the loss of the web application platform’s availability has a direct and immediate impact on sales revenue. An example of a key threat to an application’s availability may be the delivery of a successful “DoS” (Denial of Service) attack by a hacker, in which an application is knocked offline and made unavailable to genuine users.

What causes security weaknesses in web applications?

Web applications are inherently complex in both their design, their implementation, and their operation, and trying to establish the root cause of software weaknesses in a meaningful manner is incredibly difficult. Organisations such as MITRE try and provide a hierarchical taxonomy of software weaknesses in a community-developed catalog known as the CWE. Examples of types of weaknesses include not validating or sanitizing form inputs, misconfiguring web servers, and application design flaws. Although the CWE provides different “views” that aim to group weaknesses in different ways depending on the goal (e.g. for analysis or to facilitate understanding or research) none of the views directly addresses the root cause of each in a meaningful way.

Perhaps the best way of understanding how security weaknesses are introduced in a web application is understanding how they are created. Web applications are like any other application in that they are developed under a Software Development Lifecycle (SDLC), consisting of seven theoretical phases of development – planning, analysis, design, development, testing, implementation, and maintenance – a failure during any one of which can lead to a security weakness being introduced. In practice, the SDLC is a model only and not every web application will step through each phase of development explicitly during its development – although failure to conduct or consider a given phase is likely to introduce security weaknesses by its very absence.

Possible causes of security weaknesses at each stage of a web application’s development include

1. Planning – failure to consider risks that may need to be addressed during the application’s development
2. Analysis – choosing an insecure framework or technology;
3. Design – introducing an architectural weakness;
4. Development – failing to follow secure coding standards, or using unsafe functions, introducing logical errors;
5. Testing – Failure to conduct testing of the application behaviour, especially under edge conditions, prior to release;
6. Implementation – Misconfiguration of the supporting platform or an error in deploying and configuring the application; and
7. Maintenance – Failing to patch and update the platform.

How can web application security testing help?

Security weaknesses are addressed using various measures that are collectively known as controls – they can be preventative (stop a weakness being introduced), detective (detect when a weakness has been introduced), or corrective (fix a weakness once it has been found).

Web application security testing is a key detective measure that helps to ensure that any issues that have been introduced during the application’s planning, design, development, and implementation are speedily detected and flagged for attention so that they can be addressed and remediated before an attacker can exploit them.

In modern deployment practices such as CI/CD (continuous deployment) pipelines, web application security testing can be performed against pre-production instances of the web application too, so that they can double as a preventative measure – spotting weaknesses in code even before it is deployed. This allows developers to fix issues before they are even introduced to production, leaving attackers with no attack window during which the web application is vulnerable to exploit.

What types of web application security testing are there?

The two primary forms of web application security testing are: static analysis (SAST) in which the code itself is examined (offline), analogous to the script for a play being read and examined for issues; and dynamic testing (DAST) tools such as AppCheck in which the running application itself is probed for weaknesses while it is running, analogous to a live performance of the play being observed, rather than simply the script being looked at.

How does dynamic web application vulnerability scanning work exactly?

Dynamic web application scanning works by sending requests across the network in the same way that a user’s web browser does, continually attempting to break into and compromise a web application in order to pinpoint any potential gaps in the application’s security. DAST works in the same way a hacker would therefore, attempting to gain access or take advantage of flaws and insecurities within web applications for real.

There are two primary approaches to vulnerability scanning – passive, and active. A passive scan performs non-intrusive checks, simply looking at items to determine if they are vulnerable. You can visualize this method by imagining encountering a door, but not touching it to see if it’s open or locked. If the door is closed, that marks the end of that branch of your investigation.

An active scan on the other hand, is a simulated attack on your site in order to access vulnerabilities as they would appear to an outsider and is where the real power of dynamic web application security testing lies. Sophisticated dynamic web application scanners perform this active testing via an “outside in” or “black box” approach, with no prior information of the application or code – if you visualize this as a door, the fact that it may be closed would not present a dead-end. Instead, your investigation would push you to test the door, perhaps pick the lock, or even force entry. To support this, dynamic web vulnerability scanners work by automating several processes: these include application spidering and crawling, discovery of default and common content, and probing for common vulnerabilities, It is during this last step, which is perhaps the most powerful, that the scanner searches for vulnerabilities via a process known as “fuzzing” – submitting numerous variants of each possible web request to the web application, carefully tweaking numerous parameters of the request one at a time to try and elicit an unexpected response from the application under certain conditions.

What kinds of issues can web application scanning detect?

Some of the more basic web application vulnerability scanners may solely identify vulnerabilities in commercial products – such as Apache web server – in which the vulnerability in question is already known/publicly disclosed and has a published CVE ID – that is, common cybersecurity vulnerabilities that have been catalogued and are assumed as being present based on recognised patterns and software versions recorded as being susceptible to that particularly vulnerability. However, AppCheck’s web application scanner is designed by experienced penetration testers, making it more thorough and accurate at identifying complex issues from first principles, meaning that it actively uncovers previously-unknown vulnerabilities, even in custom and in-house code.

The AppCheck crawling engine uses a combination of application modelling techniques and subtle heuristic cues to automatically discover the complete attack surface of any given application in the shortest time possible. The algorithms are designed to model how a penetration tester or attacker would explore the application, to detect subtle vulnerabilities that other tools often miss and opening up attack vectors that are inaccessible to less sophisticated crawlers. It can therefore detect a range of vulnerabilities in in-house and custom code that is unique to an organisation and developed in-house by its own engineers.

Web application scanning is capable of detecting all common security problems, including “OWASP Top 10” issues such as broken access control, cross-site scripting (XSS), SQL injection, and other injection failures, security misconfigurations,  and server-side request forgery (SSRF) vulnerabilities.

What else can be done to help?

It is important to appreciate that security is best assured via a “defense in depth” approach, meaning that no single measure – such as web application security scanning – should be considered to be a panacea, no matter how effective. Rather, a strong web application security scanner should be considered as part of an effective arsenal of tools leveraged against preventing, detecting and correcting any potential security issues.

The exact list of measures most appropriate for a given organisation will vary, but in general it is worth considering what measures can best be performed at each stage of the software development lifecycle, mapping a chosen control (or controls) to each phase of the web application’s development.

How can AppCheck Help?

AppCheck help you with providing assurance in your entire organisation’s security footprint. AppCheck performs comprehensive checks for a massive range of web application vulnerabilities – including authentication failures, misconfigurations and violations  – from first principle to detect vulnerabilities in in-house application code.

The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail and proof of concept evidence through safe exploitation.

Additional Information

As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please get in contact with us: info@appcheck-ng.com