Securing User Data and Remediation Strategies for Application Users
Keywords-data leak; dns defenses; cache poisoning; malware analysis; privacy-based security defense; phishing; same-origin policy; COMBS;
Abstract — Data leaks such as the COMBS data breach are a sophisticated security attack that exposes both personal user and network information. The attack deploys a cross-section of methods to evade site defense mechanisms and leak personal information. DNS attacks such as cache poising use cross-browser scripting to hijack a user’s personal information by intercepting a web session. The most common DNS defense mechanisms such as a content security policy aim to prevent a user’s web session from an intercepted third party yet even such measures are not guaranteed to stop or defend an attack such as COMBS. We look at DNS defense practices for the platform sites and show that all can be circumvented in a matter of time. Some circumventions are browser and platform-specific while others require users to recover from personal information after a loss. We conclude with recommendations for securing user data for authenticated platforms in a multi-step user privacy-based defense.
On Tuesday, February 2, the COMB data breach, or the Compilation of Many Breaches, stole more than 3.2 billion unique email address and password pair combinations and archived them in an encrypted container. According to CyberNews, the COMB data leak included approximately 200 million Gmail addresses pharmed from major platforms like Linkedin as well as other platform providers. 
The sophisticated attacks used a series of orchestrated attack methods to steal user’s web session information and perform DNS attacks on large content platforms. Due to the nature of the attacks, traditional security defense and the content security policy failed to prevent a similar security breach in 2017.
USER’S WEB SESSION EXPOSED IN BROWSER ATTACKS
Such data breaches occur when an attacker solicits authenticated credentials from the user by hosting a fake site located on different domains other than the real site and perhaps driving traffic to the fake site by sending a LinkedIn email. Users find it difficult to distinguish the real site from the fake site.
Code from https://company.com should only have access to https://company.com’s data
Code from https://evil.company.com should not be allowed access to https://company.com’s data
Table I Malicious attack on third party site
The same-origin policy tries to ensure that company.com content data originates from company.com, however, there are a number of attacks that spoof the domain, and the user’s often aren’t able to tell. The malicious code attack such as cross-site scripting (XSS), stored XSS, or cache poisoning attack, execute on a user’s system and compromise a browser's session regardless of the security or steps of the platform a user might take to secure their information.
The vulnerability of having the user information such as a user and password combination from a web session accessible means it’s likely that some info will be leaked and used in subsequent attacks across multiple platforms.
PLATFORM SIGN-ON SERVICES
The prevalence of platform sign-on services such as using a Linkedin sign-on or Facebook sign-in to authenticate third party sites has exasperated the problem of a data breach not because these services aren’t secure but because the same methods can be employed to hack these credentials and users are still likely to use the same pairs of credentials across multiple platforms. This suggests that the threat posed by phishing, XSS, and cache poisoning is still a vulnerability for users, even when using platform sign-on services to logon to third-party sites.
OVERVIEW OF THE PROBLEM
Since the majority of people reuse their passwords and usernames across multiple accounts, credential stuffing attacks have become a major vulnerability to platforms. If someone uses the same passwords for their LinkedIn or Netflix as they do their Gmail accounts, attackers can scrape the data and access more important accounts.
The Cross-Site Scripting attacks (XSS) will inject malicious code into otherwise trusted websites and get executed when a user logs on to the site. The damage of malicious third-parties is able to inject their code into large platforms like Linkedin. If there’s malicious code executing in your browser, the authenticated username and password combination can get phished from the web session. Stored XSS is an attack where a website does not store data in a safe manner. An attacker could then store malicious code within the website’s database. Said code could be executed whenever a user visits that website.
To test the current vulnerability of the COMBS, we create Gmail accounts with authentication pairs and used them regularly across multiple sites such as Linkedin. Over the course of three weeks, the email addressed were phished and the key pair information was compromised.
Likewise, if an email address has been around for many years, it's likely the authentication key pairs have compromised at some point in time created the same attack scenario.
There are two paths forward to thwart a data leak such as COMBS and recover personal information loss. The first is to recognize and identify compromised data and two is to identify the code derived from the requested data uses privacy-based defense to mitigate damage and loss of information from the attack. Both paths require intervention from a user and the use of remediation tools against the digital tools from the platform providers and third-party sites.
Identifying whether your data has been compromised requires checking an email address against a security field database such as CyberNews. 
If the address has been verified as compromised, users should change their passwords using a strong password manager such as Lastpass, a downloadable application for generating strong passwords. These steps should be repeated across all platforms and third-party sites where the address was used.
Users are recommended to change their passwords on a regular basis by using a strong password for every account. Creating unique passwords can be quite challenging, and we recommend using strong password managers to help them generate them.
Additionally, users should add multi-factor authentication on more sensitive accounts when available. That way, even if an attacker has their username and password, they won’t be able to get into their accounts.
Final remediation is for users to report an attack or malicious activity of the personal information or third-party sites to the platform providers themselves so that updates can be made as needed to content security policy.
We tested the user privacy defense practices of the top platforms, using both known and novel attack techniques to determine that all of the data protection defenses we encountered could be circumvented in one way or another. Many of the attacks used combined approaches and can be used against a wide variety of defense mechanisms. We found that even platforms with advanced security defenses, such as Gmail and Linkedin, were vulnerable using targeted attacks. After reviewing the available security defenses, we propose a privacy-based defense for the user’s to ensure any personal information is compromised, remediated, and reported to mitigate large data breach attacks.
Previous automated technology proposals still require user installation and won’t guarantee defense against multi-threat attacks such as COMBS. By contrast, privacy defense controls allow the user to handle their authentication credentials as they need with every new session.
 Marco Balduzzi, Manuel Egele, Engin Kirda, Davide Balzarotti, and Christopher Kruegel. A solution for the automated detection of clickjacking attacks. In ASIACCS’10, 2010. 9
 Bernard Meyer. CyberNews. COMB: largest breach of all time leaked online with 3.2 billion records. In Cyber News, 12 February 2021
 CyberNews. Personal Data Leak Check.
 Mike West, Joseph Medley. Content Security Policy. In Google’s Web Fundamentals.
 CheatSheets Series Team (2021). Clickjacking Defense Cheat Sheet. In OWASP’s Cheat Sheet Defense Series.