Referral Beware, Your Rewards Are Mine

Referral Beware, Your Rewards Are Mine

Speakers: Whit @un1tycyb3r Taylor (Application Pentester, Rhino Security Labs)

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=tQRE9U1q2mk

Overview

In his compelling DEF CON talk, "Referral Beware, Your Rewards Are Mine," Whit Taylor from Rhino Security Labs delves into the often-overlooked security vulnerabilities within incentive referral programs. Taylor highlights that while these programs are ubiquitous across industries, from e-commerce giants to financial services, their underlying technical implementations are frequently neglected from a security perspective. His research, born from a "2 AM hacking thought," sought to uncover the "most boring part of a web application" to demonstrate that even seemingly innocuous features can harbor significant security flaws.

Taylor's presentation dissects various technical implementations of referral systems, exposing how seemingly minor oversights can lead to substantial financial fraud, account manipulation, and data exposure. He systematically categorizes vulnerabilities ranging from client-side gadgets and intricate business logic errors to race conditions and sophisticated referral hijacking techniques. The talk serves as a crucial wake-up call for companies, emphasizing the direct and indirect financial impacts these vulnerabilities can have on their revenue, user trust, and overall security posture.

The significance of Taylor's work lies in its focus on an area rarely subjected to dedicated security research. By demonstrating how a determined attacker can exploit common referral program designs, he provides invaluable insights for both security professionals and developers. His findings underscore the critical need for comprehensive security testing across all web application functionalities, regardless of their perceived complexity or importance, ultimately aiming to prevent widespread fraud and protect both companies and their users from sophisticated attacks.

Background

▶ Watch: Introduction: Referral Beware, Your Rewards Are Mine (0:00)

Referral rewards programs are a cornerstone of modern customer acquisition and retention strategies, ubiquitous across the digital landscape. From tech giants like Google and financial platforms like Robinhood to e-commerce sites such as Etsy and meal kit services like HelloFresh, companies leverage these programs to incentivize existing users to bring in new customers. The premise is simple: share a unique link or code with a friend, the friend signs up or completes a required action (e.g., makes a purchase), and both parties receive a reward, which can range from monetary credits or discounts to in-app assets.

Despite their widespread adoption, the security implications of these programs are frequently underestimated. Whit Taylor's research was driven by the observation that referral functionality, often considered "boring" or simple, had received little attention from the security community. He hypothesized that this neglect would lead to complex logic flaws and implementation weaknesses, a hypothesis that proved correct.

Taylor outlined four primary technical implementations commonly observed in referral programs:

1. URL to Cookie Value: In this model, a user receives a referral link. When they navigate to it, client-side code extracts the referral code from the URL and stores it as a cookie. Upon signup and completion of a required action, this cookie is sent to the server, and rewards are applied to both the referrer and referee.
2. URL to Client-Side Requests: Similar to the cookie-based approach, the referral link is navigated, and its code is extracted. However, instead of a cookie, the client-side code initiates several requests. Typically, a validation request checks the code's legitimacy, and if valid, a secondary request applies it to a pending user account. After signup and a required action, rewards are processed.
3. Promo Code Implementation: This is common in e-commerce. A referral code functions as a promo code. The referrer shares their code, the referee enters it during checkout, a discount is applied, and upon successful transaction, rewards are granted to both parties.
4. Mobile App Intents: Prevalent in mobile applications, this method leverages Android's Intents system for data sharing. When a user shares a referral link from a mobile app, an Intent is created, allowing them to choose another app (e.g., email, messaging) to send the data. The referral data is embedded within this Intent and passed to the target application.

Taylor stressed that companies should prioritize the security of these programs due to their direct or indirect financial impact. Vulnerabilities in referral systems can become significant sources of fraud, leading to revenue loss for the company and potential financial detriment for users. His research aimed to expose these overlooked attack vectors and provide actionable insights for improving security in this underserved area.

Key Findings

▶ Watch: Technical implementations of referral reward programs (2:40)

Whit Taylor's research systematically uncovered a wide array of vulnerabilities within referral rewards programs, categorizing them into several distinct classes. These findings demonstrate that despite their seemingly benign nature, referral systems present a rich attack surface for malicious actors.

His key findings include:

• Client-Side Gadgets: Identification of seemingly minor bugs (gadgets) like cookie injection and client-side path reversals (CSPT) that, while not immediately critical, can be chained with other vulnerabilities to achieve significant impact, such as account takeover or cross-site request forgery (CSRF) bypasses.
• Business Logic Flaws: Discovery of critical weaknesses stemming from incorrect assumptions made by developers regarding user behavior and program rules. Notable examples include the infinite credit flaw, where attackers can generate unlimited store credit, and order bypasses, allowing users to unlock referral benefits without fulfilling required purchase conditions. Another significant flaw was self-referral/self-discount, enabling users to perpetually benefit from their own referral codes.
• Race Conditions: Exploitation of timing windows in transaction processing, particularly in financial applications, allowing attackers to trigger multiple rewards from a single legitimate referral action.
• Referral Stealing Mechanisms: Development of techniques to hijack legitimate referrals, diverting rewards from the intended referrer to an attacker. This includes cookie fixation attacks, which exploit cookie handling logic, and mobile design hijacking, leveraging common mobile app sharing patterns.

These findings collectively highlight that the security of referral programs is not a trivial concern. The diverse nature of the vulnerabilities underscores the need for a holistic security approach that scrutinizes not just the code, but also the underlying business rules and inter-application communication, especially in mobile contexts.

Technical Deep Dive

▶ Watch: Implementation 1: Referral code in URL to cookie (3:15)

Taylor's technical deep dive revealed specific attack patterns and exploitation techniques across the identified vulnerability classes.

Client-Side Gadgets

These vulnerabilities, while not immediately impactful, serve as crucial building blocks for more sophisticated attacks:

• Cookie Injection: This occurs when an application extracts a referral code from the URL and adds it to a cookie without proper sanitization. If an attacker can inject characters that break out of the cookie value context, they can manipulate the cookie. This can lead to:
• Cookie Tossing: Injecting arbitrary Set-Cookie headers, allowing an attacker to set any cookie on the user's domain, potentially leading to account takeover or session manipulation.
• Cookie Bombing (Client-Side DoS): Overwhelming a user's browser with an excessive number of large cookies, causing requests to fail or the browser to crash, rendering the site unusable for the victim.
• Cookie Fixation: If only arbitrary cookie attributes (like path or domain) can be set, it can still be used for more targeted attacks, as described later in the referral stealing section.
• Client-Side Path Reversals (CSPT): This vulnerability arises when a value from the URL is concatenated into a client-side fetch or XHR request to construct an API call. An attacker can insert a path traversal sequence (e.g., ../../) into a URL parameter. Instead of an API call to /api/users/1, a crafted URL could make the client request ../../admin, potentially bypassing client-side access controls, leading to Cross-Site Scripting (XSS) or Cross-Site Request Forgery (CSRF) bypasses. Taylor recommended the DYSEC blog as an excellent resource for learning more about CSPTs.

Business Logic Flaws

These vulnerabilities exploit flaws in the application's core business rules:

• Infinite Credit Flaw: This highly impactful flaw relies on three conditions:

1. The application allows sign-up with alias emails (e.g., user+1@gmail.com, user+2@gmail.com).
2. There's no requirement for new users to refer others before receiving rewards.
3. The reward for a referral is greater than the required spending threshold for the referral to trigger.

The attack involves creating two initial accounts (Attacker and User1). The Attacker refers User1, who makes a minimal purchase to trigger the reward. Then, the Attacker refers User2, who also makes a purchase. Now, both Attacker and User1 have credit. Critically, subsequent referrals (User3, User4, etc.) are made to User1, with User1 using the accumulated credit to fund the required purchases. This allows User1 to continuously accumulate store credit without any further out-of-pocket spending, generating "thousands of dollars" in credit.

• Order Bypass: This flaw exploits applications that require an order before unlocking a referral code, but where orders are not automatically processed and cancellation is allowed. The attacker (User1) places an order with a scheduled delivery, which unlocks their referral code. User2 then uses User1's referral code to get a discount on their own order. Immediately after, User1 cancels their initial scheduled order. This bypasses the logic, granting User2 a discount and User1 the referral credit, without User1 ever completing the initial qualifying purchase.
• Self-Referral/Self-Discount: This vulnerability occurs when an application uses a referral code as a promo code and fails to validate that the referrer and referee are distinct users. An attacker signs up, and if immediately shunted into a subscription flow, they can force browse back to the home page. Navigating to account settings often triggers an API request that reveals their unique referral code. The attacker then restarts the subscription flow, applies their own referral code as a promo code, and discounts their own subscription. In one case, this could be chained with billing cancellation to achieve a perpetual 50% discount on every billing cycle.

Race Conditions

Taylor successfully identified a race condition in a financial application's referral flow:

1. User visits referral link.
2. A PUT request signs up the account.
3. A "validation" request is sent, which merely checks if the account exists or if the code has already been used.
4. A final request applies the referral code and triggers the reward.

The vulnerability lay in the final request. By using James Kettle's single packet attack (sending multiple identical requests in parallel), Taylor could exploit the small window between the "validation" and "application" requests. This allowed him to trigger multiple rewards from a single referral, effectively multiplying the referral bonus. The speaker noted the difficulty in demonstrating this fully due to the program's strict user verification (requiring an SSN), preventing him from creating a second verified account.

Referral Stealing

These attacks focus on diverting referral rewards to an attacker:

• Cookie Fixation: Building on cookie injection, this attack involves sending a crafted link that breaks out of the cookie value context and sets the path attribute of the injected cookie to a specific, more granular path (e.g., /signup or /applyReferral). According to the cookie RFC, a cookie with a more specific path is prioritized over one with a broader path.

1. Attacker sends a malicious link to a victim.
2. Victim visits the link, and the attacker's crafted cookie (containing their referral code) is stored with a specific path.
3. Later, the victim receives a legitimate referral link from a friend.
4. When the victim completes the sign-up process, the attacker's cookie, due to its more specific path, is prioritized and sent with the request, leading to the attacker receiving the reward instead of the friend.

• Mobile Design Hijacking: This niche attack exploits mobile applications that rely on the user to select the target app when sharing data, even when there's no technical reason for such a choice. For example, if a "Send by email" button sets the MIME type to message/RFC822, it triggers a system-level app selector.

1. An attacker distributes a malicious app on a user's device.
2. This app is disguised as a legitimate application (e.g., Gmail) by mimicking its package name (e.g., a.a.gmail) and icon.
3. When the victim attempts to share a legitimate referral link via email, they might accidentally select the attacker's disguised app from the sharing menu.
4. The malicious app intercepts the intent data, replaces the legitimate referral code with the attacker's code, and then forwards the modified intent to the actual target application (e.g., Gmail). The user remains unaware that their referral has been hijacked.

Demo / Proof of Concept

▶ Watch: Why companies should care about referral program security (5:45)

While Whit Taylor's talk did not feature a live, interactive demonstration of his findings, he meticulously detailed the proof-of-concept steps and attack flows for each vulnerability class he discovered. Through redacted diagrams and clear explanations, he walked the audience through the specific sequences of actions and conditions required to exploit the infinite credit flaw, the order bypass, self-referral, race conditions, cookie fixation, and mobile design hijacking.

For instance, the "infinite credit flaw" was illustrated with a multi-step process involving two initial accounts and subsequent self-funding referrals. Similarly, the "order bypass" described a precise timing of order placement and cancellation. Although he could not disclose actual technical details or target names due to disclosure agreements, the methodical presentation of these attack scenarios served as a robust conceptual proof of concept for each identified vulnerability. The diagrams effectively conveyed the technical mechanisms without revealing sensitive information, allowing the audience to grasp the exploitability of these "boring" referral program features.

Defensive Implications

▶ Watch: First bug class: Cookie Injection via URL manipulation (6:30)

Whit Taylor's research provides critical insights for organizations aiming to secure their referral rewards programs and, by extension, their financial integrity and user trust. The implications for defenders are substantial, highlighting an often-neglected attack surface.

Here are key defensive measures derived from the talk:

1. Robust Input Validation and Sanitization: Implement stringent server-side validation and sanitization for all referral codes and URL parameters. This is crucial to prevent cookie injection by ensuring that referral codes cannot break out of their intended context or inject arbitrary characters. Similarly, it mitigates client-side path reversals (CSPT) by disallowing path traversal sequences in parameters used to construct API calls.
2. Comprehensive Business Logic Validation: Developers must challenge assumptions about user behavior and meticulously validate all business rules.

• Prevent Alias Email Abuse: Implement checks beyond simple email addresses to identify duplicate users. This could involve device fingerprinting, IP address checks, or requiring additional verification steps (e.g., phone number verification) to prevent the infinite credit flaw.
• Balance Rewards and Requirements: Carefully design reward structures so that the value of the referral reward does not significantly outweigh the required spending or action. Regularly audit these values to ensure they do not create an arbitrage opportunity for attackers.
• Enforce Action Completion: Ensure that all prerequisite actions (e.g., order completion, account verification) are truly finalized and irreversible before unlocking referral codes or applying rewards. The order bypass vulnerability highlights the need to account for cancellations or pending states.
• Prohibit Self-Referral: Implement explicit server-side checks to ensure that the referrer's account is distinct from the referee's account. This prevents users from self-referring or self-discounting repeatedly.

1. Mitigate Race Conditions: For critical transactions, especially those involving financial rewards, implement server-side mechanisms to prevent race conditions. This could involve transactional locking (e.g., database row locks) or ensuring idempotency for reward application logic, so that multiple identical requests only result in a single reward.
2. Secure Cookie Handling: When using cookies for referral tracking, ensure that the path attribute is carefully managed and that referral cookies are not susceptible to manipulation that would allow an attacker to set overly specific paths. Implement strong SameSite cookie policies and ensure all sensitive cookies are HttpOnly and Secure. This directly counters cookie fixation attacks.
3. Secure Mobile App Intent Handling: For mobile applications, avoid relying solely on user selection for sensitive data sharing if there's no functional reason for it. Implement stricter intent filters and data validation within the receiving application. Validate the source and content of incoming referral data to prevent mobile design hijacking where a malicious app could alter the referral code.
4. Continuous Security Testing: Given that referral programs are often seen as "boring" functionality, they frequently escape thorough security scrutiny. Companies should prioritize dedicated security assessments, including penetration testing and bug bounty programs, specifically targeting these features. This should encompass both technical vulnerabilities and complex business logic flaws.

By proactively addressing these defensive implications, organizations can transform their referral programs from potential fraud vectors into genuinely secure and valuable growth engines.

Key Takeaways

• Referral programs are an overlooked attack surface: Despite their ubiquity, incentive referral programs are often neglected in security assessments, making them ripe targets for exploitation.
• Vulnerabilities span multiple categories: Attackers can exploit client-side gadgets, complex business logic flaws, race conditions, and sophisticated referral hijacking techniques to compromise these programs.
• Financial impact is significant: Flaws can lead to direct revenue loss for companies through fraud (e.g., infinite credit, self-discounting) and can erode user trust.
• Robust validation is paramount: Strict server-side input validation, comprehensive business logic checks (e.g., preventing alias email abuse, self-referral, order bypasses), and secure cookie/intent handling are essential.
• Race conditions are a real threat: Even seemingly simple referral flows can be vulnerable to race conditions, allowing attackers to multiply rewards if not properly protected with server-side idempotency or locking.
• Bug bounty experience can be frustrating: Despite uncovering impactful vulnerabilities, researchers may encounter low bounties, triagers who don't understand impact, or companies that fix issues without proper acknowledgment or payment.

About the Speaker(s)

Whit Taylor, known online as @un1tycyb3r, is an Application Pentester at Rhino Security Labs. Beyond his professional role, Whit is an active and enthusiastic bug bounty hunter and a dedicated security researcher, particularly focusing on open-source projects. He describes himself as a proud father and husband, sharing a glimpse into his personal life with his beautiful wife and a "very, very large 6 and a half-month-old." Outside of cybersecurity, Whit's diverse interests include playing the piano, powerlifting (demonstrated by his ability to deadlift 500 lbs), and fishing. His talk at DEF CON showcased his passion for uncovering overlooked vulnerabilities and contributing to the broader security community.