Context

Scanning using AppCheck is designed to be non-disruptive and is used by users to test their production systems every day. 

However, there are risks of scanning production environment which can never be entirely mitigated.  These risks can include data loss or modification, as well as undesired interactions with parts of your application. Appetite for such risks is a decision for each individual business to make.

AppCheck's recommendation is to perform limited, unauthenticated scanning in production, and perform full, in-depth scanning in a pre-production environment.

To facilitate this, AppCheck provides two main profiles for scanning web applications: Sensitive Production Environment, and Standard or Single-Page Application.

Standard or Single-Page Application

The Standard or Single-Page Application profile is AppCheck's main Dynamic Application Security Testing (DAST) profile, and we recommend running this against a pre-production environment.

This includes active scanning intended to discover zero-day vulnerabilities by active exploitation.

Sensitive Production Environment

As the name suggests, the Sensitive Production Environment profile is intended for scanning production environments.

This profile focuses on the following:

System Interoperability Vulnerabilities

One of the most common areas for vulnerabilities to be introduced lies in the interoperability of systems in production environments. These flaws are often overlooked because each system is tested in isolation. 

For example, the common Cross-Site Scripting (XSS) vulnerability occurs when data submitted via a web browser is embedded in the application's response without proper filtering. The attacker could exploit this by tricking the user into following a malicious link that embeds JavaScript in the page designed to hijack their session with the application. This is one of the most common findings in application scanning but only applies to parts of the request that the attacker can control through a malicious link or an evil web page (i.e URL components, Form data and the referer header). If this behaviour is observed in an arbitrary HTTP header, it is often either reported as Informational or ignored completely. This is because there is no way for the attacker to control arbitrary headers in an XSS attack (with the exception of the referer header) and therefore at face value poses no risk. 

Whilst this finding is likely to be overlooked as a non-issue (which it often is), consider how this may change if a web cache is introduced when the app is deployed in production.  

Web caching servers store web server responses to speed up access to commonly requested components. The cache identifies requests by building a “cache key” that is then used to store are retrieve items from the cache. Typically, cache keys are based on the URL (hostname, path and query string) but don’t take into account other headers. Therefore, in our example, the attacker may be able to poison the cache with a malicious response by embedding JavaScript code within the affected header. Users who access the same URL will now retrieve the malicious version of the page, turning this previously considered non-issue into a devastating critical impact attack. 

You can read more about XSS and Cache Poisoning here: https://appcheck-ng.com/cross-site-scripting/ and https://appcheck-ng.com/web-cache-poisoning-explained/ 

Another popular and powerful attack is HTTP Request Smuggling, a vulnerability that occurs due to two or more systems in a chain calculating the length of a malformed HTTP request differently. In this attack, its possible for the attacker to remotely manipulate requests submitted by other users. Crucially, this attack occurs due to the Interoperability of two or more systems and may only affect your production environment. Additionally, an update to this attack technique, focusing on HTTP/2 was presented at Blackhat 2021 and had breathed new life into this powerful attack. 

Hosting Environment Vulnerabilities

Hosting components such as Application Frameworks, Web Servers, Application Servers, Content Management Systems and intermediary devices are a crucial part of your attack surface. Threat actors have redoubled their efforts on these systems recently due in part to the global pandemic, where remote access systems have become more widespread and business-critical. In 2021 the UK’s National Cyber Security Centre (NCSC) and the NSA released a joint advisory stating that Nation State-backed threat actors were actively targeting security flaws in; Cisco, Citrix, F5 BigIP, Fortigate, Pulse Secure, and VMware, systems commonly found at, or close to the internet gateway. 

In the same year, critical impact vulnerabilities have also been discovered and subsequently widely exploited in the Apache WebServer and countless popular Content Management Systems (CMS) and plugins. 

This area of your exposed Attack Surface is perhaps one of the most volatile. New security flaws are disclosed daily, a system that was believed to be secure yesterday may now be known to contain a critical security flaw. It is not uncommon for server build vulnerabilities to be dismissed as an acceptable risk or overlooked in development and staging environments, especially when they are restricted to trusted IP addresses/users.  

It is essential that vulnerabilities within the production environment are identified on an ongoing basis and quickly addressed. Attackers are quick to jump on the latest and greatest attacks so it’s essential we detect these vulnerabilities quickly without waiting for the next full scan. 

Configuration Differences 

It’s often not possible to have the exact same configuration across production and pre-production; practical differences such as location and resourcing among many other factors can play a part and affect security. 

For example, differences in proxy and firewall configuration or configuration to support the use of an additional system such as a CDN service, load balancer, remote management system or web application firewall can impact security.

Even in cases where the additional system is designed to improve security, there are cases where these systems introduce interoperability flaws or can even introduce vulnerabilities themselves.  

Gaining Complete Scan Coverage

By combining the results of these two scans optimal coverage is achieved without risking unwanted side effects associated with DAST scanning of sensitive systems. 

See also: Minimising Risk of Web Application Scanning.