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.
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.
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.
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.
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:
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
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.
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.
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.
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.
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.
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.
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: email@example.com
No software to download or install.
Contact us or call us 0113 887 8380