August 15, 2020
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?
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.
Let’s look at the most popular targeted data assets and determine if such data assets are worth protecting:
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:
These questions will help in deciding where client-side security lands on your ecommerce risk management priority list:
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:
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?
Complexity in front end security leads to mistakes.
Mistakes, eventually, lead to breaches.
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.
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.
Security start with visibilty
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
Now let’s move from a higher level to the concrete building blocks in the context of web security.
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:
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:
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.
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
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.
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
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 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?
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?
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.
About authors