How Backdoors In Client-side Of Web Applications Can Lead To Breaches and GRC Compliance Issues?

The client-side browser front-end of web any application is a gateway in and out of our virtual kingdoms. The scripts executed by the client-side web browser are also great access points for malicious hackers and thieves to collect sensitive personally identifiable information (PII). By ignoring these significant client-side vulnerabilities, we can be making big mistakes that can ultimately lead to data exfiltration and adversely affect Governance, Risk and Compliance (GRC) requirements. How can we prevent that without overwhelming ourselves?

Why Did Client-side Security Become A Lucrative Attack Surface?

The web is no longer just a place to market and sell. It's where organizations operate, help customers learn, purchase, and enjoy their products and services.

The digital user experience is the core of the ecommerce customer experience. Current trends, such as enhancing the experience coupled with digital market business intelligence gathering, and best of breed technologies continue to move software logic to the client-side of web applications. This also increases inherent environment complexities. The web browser front-end, aka ‘digital user experience’, actively ingests customer/user information at data input points that can include some very sensitive information.

As the web front-end code runs on unmonitored and untrusted devices, many application security flaws are being leveraged by malware and malicious actors to capture credentials, financial transactions, payment card data, and permit legitimate third-party vendor tools to facilitate unauthorized access to sensitive data.

News alerts and announcements of client-side breaches, including e-skimming and Magecart malware infused cyber attacks demonstrate many examples where web applications and website architectures have been compromised. Many mobile applications are also being compromised via skimming malware, web-based supply chain attacks.

What Is At Stake?

Let’s look at the most popular targeted data assets and determine if such data assets are worth protecting:

• Payment card data
• Authentication and authorization credentials
• Financial records
• Customer Personally Identifiable Information (PII)
• Patient Personal Health Information (PHI)

The street language of risk assessment and mitigation is ultimately measured in currency (dollars, British Pounds sterling, Euros, etc.) Evaluating security related risk to web front-end data in terms of monetary value is an important step towards prioritizing the protection of the most critical of information assets.

According to payment card industry sources, failing to comply with the PCI Data Security Standard (DSS) and resulting data breaches could result in industry-imposed fines, penalties and unwelcomed litigation. Fines from the major card brands for PCI DSS non-compliance can range from $5,000 to $100,000 US depending on the level of verified due diligence exercised by a compromised business entity. The less due diligence demonstrated by a breached organization, the higher the fines, penalties and liabilities. Other breach related consequences can include the following:

• Settlements, legal costs, judgments and litigations
• Fines, penalties, and fraud losses
• Termination of accepting payment cards
• Diminished sales
• Going out of business
• Cost of reissuing new payment cards
• Higher future costs of compliance

These questions will help in deciding where client-side security lands on your ecommerce risk management priority list:

• What happens if your web application has been breached yesterday or even today?
• What will be the PCI compliance-related forensic investigation costs and associated fines, penalties and liabilities?
• What will be the cost of remediating breach related vulnerabilities?
• Are CCPA, GDPR and other privacy regulations applicable? What are those related potential costs
• What about lost revenue? How critical is it in terms of brand damage?
• Will business continuity be impacted?
• What about lost employee productivity?
• And more...

When Bad Things Happen

Magecart related malware attacks were confirmed to have successfully breached at least 19,000 Internet domains in 2019 alone. Macy’s, Ticketmaster, American Cancer Society, P&G's First Aid- Beauty, British Airways, Newegg, and many other organizations have reported successful digital skimming attacks. The vast majority of cyber skimming victims, however, are inflicted upon small to medium-sized organizations with 50 to 1000 employees. Costs of web skimming breaches can range from tens of thousands to hundreds of millions of dollars along with a high probability of putting some affected entities out of business.

$650 Million to $6 Billion

Lawsuits liability

$230 Million

GDPR fine notice

$10’s of millions

Legal, Forensics, and other costs

Brand safety and reputation

Leadership changes

Hundreds more web supply chain-based breaches of the front end user experience:

• Step 1 - Attackers add code with skimming functions to a script that is used by the target website. 
• Step 2 - The skimming function is executed by user browsers enabling it to steal sensitive information including account login credentials, payment card information by recording user keystrokes and input into form fields.
• Step 3 – User information is sent to attackers.

Top Four Vectors Of Client-side Web Skimming Attacks

Javascript Libraries

Web applications that use third-party JavaScript code are vulnerable because of the lack of internal security management and oversight. As a result third party code can have an unrestricted level of access to sensitive data at the browser-level.

Sideloading And Chain-loading of Code

Sideloading and chain-loading techniques allow actors to load JavaScripts code with skimming capable malware on target web pages even while using legitimate scripts and tools. E-skimming breaches via sideloading can go undetected for a long time because infected code is loaded directly by web browsers well outside of the security perimeter.

Platform Or Cloud-Hosted Skimming

E-skimming code is found hosted by popular cloud platforms including Salesforce Heroku and Amazon CloudFront CDN, as well as on misconfigured Amazon S3 buckets. Such code can inject backdoors for inserting malicious code into JavaScript libraries used by thousands of organizations.

The Backdoors

Most organizations struggle with a single source of truth for their client-side code. Step one is actually knowing what exists. Let’s look into why most organizations struggle in discovering and classifying front-end assets. What more do we need to know?

What does client-side chaos look like?

The front end complexity of web applications at an organization with ~1,000 employees

Assets:

60

password
pages

2

payment
pages

110

forms
ingesting PII

147

PII elements
ingested by forms

Risks:

50

vulnerabilities
detected

2

high
severity

38

medium
severity

10

low
severity

Surface:

2

domains
analyzed

703

web pages
total

3,318

scripts
detected

35

scripts per page
(average)

The Client-side (Front End) Problem Is Twofold:

1. Front end code, aka ‘the digital user experience’, can actively ingest customer/user information at the data input points including login and financial transaction forms, or any other web forms where organizations are processing sensitive user data.

Web development continues to move software logic to the client-side of web applications. Web applications increasingly execute both dynamically loaded and externally controlled JavaScript code into user web browsers. Dynamically loaded third-party scripts dramatically increase code variability while nearly eliminating event change controls. Increased variability and reduced controls mean a growing probability of compromise. Meaning, that every script, third-party and open source library can open a backdoor.

• Are you aware of every backdoor?
• Do you know what is flowing through these backdoors?
• Can you lock and control backdoors?

The Client-Side Universe

Client-side application security is its own universe. It is its own world. In most cases it requires an awful lot of manual work to ensure application security in this space. The client-side web browser front-end is a more different attack surface than the other web application interfaces. Just like in optimized application security, client-side security requires a completely new point of view, approach, and skills. For many, these concepts are not yet well understood. Let’s explore what components of a client-side security program that will help reduce potential “backdoor” risk.

What a Thorough Root-Cause Approach Must Do

• The approach should look for the root cause by breaking down a big problem into smaller pieces and apply a risk management framework. Many GRC frameworks can help with this. By leveraging risk management frameworks, you can be confident that your approach is structured, measured, and complete. Some of the most popular frameworks to consider implementing are OWASP. CIS, NIST, MITRE ATT&CK. A framework is like a brick wall vs. a pile of bricks. The benefit of a framework is that you know if something is missing.

Security start with visibilty

1. What assets do you have?
2. Who has access to those assets?
3. What is being done to these assets?
4. What controls and protections are in place?
5. Are controls effective and non-tampered with?

Feroot creates a sustainable security program operation with a continuous scanning and real-time protection and monitoring of the client-side (front end) surface area that is proactive, autonomous, and accurate

2. A thoroughly optimized method implies looking for the root cause or reason behind the a given problem, not just the surface or the symptom of the problem. For example, if a patient is having chest pain, a non-root cause approach would be to provide some painkiller medications. Could it be a lung problem or even a heart disorder? The root cause method would be to find what is really causing the chest pain and remediate any associated critical issues.
3. The approach should be flexible, platform-agnostic and business-friendly.
4. The approach should be continuous and comprehensive to make it effective, efficient, and to help prevent future mistakes and missed vulnerabilities.

Now let’s move from a higher level to the concrete building blocks in the context of web security.

What Use-Cases Are Required?

Because the client-side code dynamically changes for each user session, client-side vulnerability inspection must include all JavaScript code loaded by the browser during user journeys. This includes code loaded by the first party web application servers as well as any code loaded from external third-party sources. Considering all elements of the client-side browser code will enable you to determine the security posture of the client-side and obtain a comprehensive list of vulnerabilities in this environment. An excellent methodology to tackle front-end security problems should consider these use-cases:

1. Vulnerability Management - Penetration tests and security vulnerability assessments help diagnose immediately addressable vulnerability issues. Unlike penetration tests, however, additional scrutiny should be applied to runtime front-end code. This will help to accurately and precisely discover such vulnerabilities and provide actionable information. 
2. Content Security Policy (CSP) – Includes the introduction of security controls to enable a business to operate flexibly without hindering business operations or introducing risk.
3. Web Application Firewall (WAF) – WAF implementation should become part of the operation and embedded into the runtime as well. Unlike a WAF, however, there is also a need to secure the front-end at the browser level and while being platform agnostic.
4. Secure Software Lifecycle Cycle (SDLC) – The secure SDLC should include tools that monitor and help manage change control over the entire software development lifecycle. Unlike traditional software management tools, however, a critical objective is to also monitor and manage in-house developed Javascript code and third-party code. True regardless if such code is loaded from servers under your control or dynamically loaded from third-party servers.
5. Third-Party & Supplier Risk Management – The goal is effective management of 3rd party related vendor risk to critical IT and data assets. Unlike the 3rd supplier management systems, potential solutions need to address third-party technologies in real-time and at the browser-level of every user session. Once again, it should do so with no adverse impact on user experience and browser performance.

GRC IT security frameworks are implemented to facilitate the management of the business and other organizational IT governance practices, enterprise risk assessment, issue mitigation, and compliance with applicable regulations and industry standards. GRC ‘regulatory standards’ are implemented as required by government mandates. Compliance with ‘industry standards’ requirements are not imposed by law, but are de facto requirements imposed by various industry-specific organizations to help maintain minimum acceptable levels of professionalism and excellence in performance. One overall directive they both have in common is the concept of “…the protection and preservation of critical information assets and intellectual capital.”

There are numerous IT GRC standards being implemented today and discussing them all now would not be practical. Some of the most influential and widely embraced are as follows:

1. Payment Card Industry Data Security Standard (PCI DSS)
2. California Consumer Privacy Act (CCPA)
3. General Data Protection Regulation (GDPR)
4. Open Web Application Security Project (OWASP)
5. Center for Internet Security (CIS)
6. National Institute of Standards and Technology (NIST)
7. Mitre ATT&CK

Let’s take a high-level look at each one and discuss the implications of meeting the requirements for each as it relates to the impacts of the injection of 3rd party, side-loaded code and scripts into client-side browser interactions with web application architectures.

Payment Card Industry Data Security Standard (PCI DSS)

The PCI DSS is a set of de facto industry standard requirements that businesses and other organizations must be compliant with if they store, process or transmit cardholder data in order to process payment transactions. Compliance with the PCI DSS is mandatory for entities who are processing payment card data from the five (5) major payment card brands; AMEX, VISA, MasterCard, Discover and Japanese Central Bank (JCB)

The intent of the PCI DSS is to protect critical data elements associated with payment card transactions as follows:

Type I cardholder data (CHD) elements – Primary account number (PAN), cardholder name, and various service codes. The most critical data element of this type is the PAN; the PAN determines the actual scope of PCI DSS requirements compliance. Type I CHD has to be stored or transmitted using strong, industry-standard encryption or mathematical hashing, truncation or masking of the PAN.

Type II cardholder data elements – Card validation values (CVVs) and magnetic track or chip equivalent data that are unique to each card (also sometimes referred to as ‘sensitive authentication data SAD). Sensitive authentication data must never be stored following transaction authorization except for some extremely rare and special circumstances. If it is going to be stored prior to authorization, it must be protected via strong encryption and securely deleted when no longer needed.

Entities processing payment transactions often do so via web-based eCommerce architectures. Per PCI DSS section 6.x, only securely developed and administered applications are considered PCI DSS compliant in order to process such transactions. In addition, the PCI DSS requires that such applications be developed and maintained in accordance with OWASP Top 10 requirements (more on OWASP in a bit.) https://www.pcisecuritystandards.org

Data Protection And Privacy Regulations

California Consumer Privacy Act (CCPA)

California was one of the first states to enact personal data protection regulations. Now many other states in the US have followed suit in passing and enforcing their own Personally Identifiable Information (PII) and Personal Health Information (PHI) privacy regulations? Per CCPA, any business or entity conducting e-commerce transactions, or storing-transmitting PII-PHI via web-based architectures must do so only if the proper protections are in place.

General Data Protection Regulation (GDPR)

GDPR is a regulation imposed by European Union law that focuses on data protection and privacy with respect to specified PII.

* Note: Some eCommerce applications often process data elements deemed GRC sensitive or even restricted via some payment or payment re-direction web pages. As such, those web pages should only present and support those services necessary to securely facilitate the payment transaction and nothing more. Additional code, scripts, *.html tags, etc., that are used for gathering business intelligence, browser user interaction telemetry, info sharing with web marketing entities, etc., should not be present on payment or payment re-direction pages. Feroot technologies are unique in the industry in providing visibility and mitigation support for enforcing these requirements.

Data Protection And Privacy Regulations

Cybersecurity Frameworks

Open Web Application Security Project (OWASP)

OWASP is an online affiliation of web application developers that produce methodologies, documentation, tools, and techniques to support industry-wide secure web application development and administrative best practices.

OWASP principles and practices are supported by many GRC frameworks, and compliance with OWASP attributes is mandated by others. For example, compliance with OWASP Top 10 web application vulnerability mitigation requirements is mandatory for in-scope PCI DSS environments. The OWASP Top 10 is a standards based awareness document for web application developers and administrators. It represents a broad consensus with respect to the most critical risks to applications, based upon a 3-year rolling tally of the most critical web breaches found in the real-world web architecture implementations. https://owasp.org

National Institute of Standards and Technology (NIST)

NIST is a physical sciences laboratory and a non-regulatory agency of the US Department of Commerce. NIST supplies industry, academia, government entities and other organizations 1,300+ standard reference materials. In some instances, US organizations require compliance with NIST recommendations. For other entities, alignment with NIST recommendations is considered to be a best practice.

NIST has published a multitude of guideline documents including the 800 series of special publications. This series presents information that is of specific interest to the computer security community. NIST has also published SP 800-95: Guide to Secure Web Services. https://csrc.nist.gov/publications/sp800

Center for Internet Security (CIS)

CIS is a non-profit entity that helps to establish minimum acceptable secure baseline configurations for computer operating systems and other IT system attributes. Minimum secure baseline system configurations is mandated for compliance by some industry standards such as the PCI DSS. https://www.cisecurity.org

Mitre ATT&CK

MITRE ATT&CK and Client-Side Security of Web Applications

MITRE ATT&CK™ and framework - SaaS Matrix

Detection and/or protection of the client-side against a number of tactics including:

Mitre ATT&CK framework is a comprehensive matrix of tactics and techniques used by threat hunters, penetration testing teams, and social engineers to better classify attacks and help assess risk. https://attack.mitre.org

Inventory Management

The discovery and ‘baselining’ of IT systems and processes is a critical attribute of any cybersecurity program. The web browser client-side is unique, but still worthy of such consideration. Most organizations struggle with finding a single source of truth for client-side code security recommendations. A NIST, CSF or CIS focused hardware-software inventory is the first priority. Discover it, manage it, secure it. It all starts, however with ‘discovering it’.

Discovery

What makes client-side security unique is how to go about creating an inventory of web front-end architecture elements. What do you need to know about your front-end?

• What data is going through the web front-end assets?
• What sensitive data do they collect?
• What sensitive data could get unnecessarily exposed in the process?
• What application elements are touching your data (i.e. - scripts and libraries)?
• What 3rd party elements have access to the data that is going through the front-end?

A critical part of client-side inventory discovery and management is to determine what scripts have access to sensitive data that are not being used, often referred to as ‘zombie scripts’. When a script becomes a ‘zombie’, it should be immediately quarantined since it will be the easiest backdoor for a potential attacker to exploit. Why are static code analysis, dynamic code scanning, and the manual review of front-end code affecting critical data assets so challenging?

• No two scripts are the same.
• It is difficult to find all zombie scripts.
• Total visibility into scripts being used and scripts that are not is difficult to achieve.
• Visibility into security control and configuration variants is often difficult to establish.
• It is difficult to block all access to sensitive data on the client side.

Change tracking

Web application browser front end scripts are continuously changing. Security teams often lose the client-side battle because of code variability and dynamics. Since the front-end code changes for every user session, how can someone review all of those changes and try to determine what’s exposed? Is it due to business logic, application vulnerabilities, or a cyber incident? We see the same problems over and over in every customer related environment that we review. Humans can't analyze millions of script changes at machine speed. Machines can track and spot anomalous behaviors in a way no humans can. Machine-to-human ‘teaming’ is necessary.

A Place For Automation, Orchestration, and Communication

It is possible for machines (cyber technologies) to analyze the web browser front-end to first detect anomalous behavior, and then provide crystallized insights and contextual details to the security analyst. It can also help one to take defensive action in mitigating the relentless cyber-attacks on web applications and browsers. In this approach the machine's role is to build the picture for the security staff providing the much-needed visibility as to what's happening, and to help recommend suitable corrective actions.

In summary, client-side security is a unique potential cyber-attack surface that is often overlooked or missed by traditional application vulnerability and penetration testing methods. If you succeed in optimally protecting the client-side of your web, you will not just have created a more robust end user experience. You will also have enhanced your organization's overall business competitiveness, agility, and ability to continue differentiate with innovation. Finally, and possibly most importantly, you will also better succeed in protecting your organization’s most critical and valuable assets; sensitive customer data.

We hope this technical resource regarding client-side web risk surface area has convinced you that it is important to find, monitor, and lock all backdoors within the application web browser front- end, ensure that your customer’s critical data assets don’t become any attacker's newly harvested low-hanging fruit.