Referral rewards programs are nearly ubiquitous today, from consumer tech to SaaS companies, but are rarely given much security oversight. In this blog post we’ll dig into the common technical implementations of rewards programs on web apps, common security issues with each approach, and recommendations for secure development of similar programs. In a subsequent post, we’ll explore real-world examples of these vulnerability classes in detail.

Referral rewards programs generally follow this flow:

1. A user shares a referral code or link with a prospective user
2. The user signs up using shared code or link
3. The user receives some reward for signing up or completing some requirement and the user of whom the referral code belongs
4. The user receives a reward

These rewards come in various forms to incentivize referrals. Companies commonly offer discounts on purchases, store credit that can be used for future transactions, or application-specific rewards tailored to their product. Some programs even provide cash rewards, making them particularly attractive to users. So the theft of referral rewards can lead to either direct or indirect financial impact.

Referral links and codes come in various forms and configurations. Applications usually offer a method to share via email or text, or offer the ability to copy the link for sharing.

The way in which this referral relationship is established after the referral is sent can come in a few configurations:

1. URL to cookie
2. URL to request that applies/links the code to the new account
3. Referral code as a promo code

In the URL to cookie implementation, the prospective user receives a referral link from an active user. Upon visiting this link, the user is usually prompted to signup for a new account. The application will extract the referral code value and it will set a referral code cookie with that code as the value. This cookie gets sent with the signup request, maintaining the referrer to referred user. Following signup, the application awards the referrer and sometimes the newly signed up user, depending upon the terms of the referral program.

In the URL query parameter to client-side initiated request implementation, it works similar to when an app utilizes a cookie, but in this case the value is placed within multiple requests initiated by the client-side javascript, such as a fetch request. This typically follows the following logic:

1. Referral Code is extracted from query parameter.
2. The client-side code sends the referral code in a validation request.
3. If the code is valid, a second request created by the client-side code applies the referral to the pending account.
4. Upon signup completion and any required action by the new account, the referral rewards are applied according to the terms of the referral program.

Many applications opted to have the pending user apply the code at checkout as a promo code. This implementation can also be used in combination of the URL parameter to Client-Side Initiated request which in turn adds the referral code as a promo code after passing validation.

Twenty plus companies running these referral programs were assessed as a part of this research. That research produced 25+ submissions of various bug classes including business logic errors and race conditions along with a wide-spread issue with mobile applications called referral hijacking. These referral programs were also discovered to be a great place to search for client-side gadgets such as client-side path traversals and cookie injection.

Applications often will have functionality or bugs that are either of little impact, or aren’t a vulnerability by themselves, but when used in conjunction with other functionality or low impact bugs, can be used to achieve a serious vulnerability. These bugs can be referred to as gadgets, and when assessing the security of the client-side of the application, it’s important to identify any potential gadgets. Within the referral program functionality, two gadgets can be found:

1. Cookie Injection
2. Client-Side Path Traversal

For cookie injections, this can lead to bugs both with a referral reward focus and beyond. When an attacker controls the cookie value, the first option is to attempt a Carriage Return Line Feed (CRLF) Injection and attempt to get response header injection. If that is successful the attacker can set arbitrary cookies, allowing for a technique known as cookie tossing (Read here for more on cookie tossing).

In the case where a CRLF injection is not possible, but the attacker is able to escape the value and set the domain and path cookie attributes, then the attacker can do a limited version of cookie tossing, specifically targeting the referral rewards functionality. By setting the path to the specific path where the referral code is applied, an attacker can ensure that their referral code is used because the browser prioritizes cookies with a more specific path.

For client-side path traversals (CSPT’s), this can lead to two bug classes: Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF). Client-side path traversal attacks focus on exploiting this weakness in order to make requests to unintended API endpoints.

The way this turns into XSS is when the response of the API request is dangerously placed within the DOM. When an attacker can combine this CSPT with another gadget such as a file upload or an open redirect that allows for control over the response, then the attacker can achieve XSS.

For CSRF, this occurs when the CSPT can be leveraged to make a state changing request with the request method of the request that the attacker controlled. While the preferred scenario would be for the controlled request to be a POST or a PUT request, there are still instances of GET based CSRF’s in modern applications that can be uncovered. (Read here for more on Client-Side Path Traversals)

The most common bug type found in these implementations were some form of business logic flaw. The implementation logic within these various programs made various assumptions on how the user would interact with the program and this led to various instances where the intended flow could be circumvented. Some areas where assumptions might occur can include:

• Validation of the referral code or other validation requests/flows
• That users will follow the intended flow
• User will only enter expected input

It is also possible in referral rewards implementations for a user to get multiple rewards for a single code redemption if a race condition exists in the request that applies the code. Utilizing the single-packet attack, an attacker can send multiple identical requests that arrive at the server at the same time, which can result in a user getting multiple rewards for a single referral.

Referral hijacking is a new attack vector found during this research that encompasses the ability for an attacker to change the referral link/code that is sent to a prospective user to the attacker link/code, thus hijacking the referral and becoming the receiver of the reward given to the referrer. One attack path to referral hijacking was discovered: cookie fixation.

As mentioned in the cookie-injection gadget section, an attacker can fixate a cookie for a victim by setting the path cookie attribute to a specific path. According to RFC 6265, when a browser finds multiple cookies with the same name, the cookie with the more specific path gets prioritized and sent first. This means that in situations where the referral program is using the URL to Cookie implementation, an attacker with the ability to fixate a cookie can fixate the referral cookie containing the attacker referral code and set the path to the request that applies the referral code, which will lead to the attacker hijacking the referral and receiving the reward instead of the original referring user.

In order to prevent the above vulnerabilities, companies have several steps they can take to securely develop referral program functionality.

1. For business logic flaws, avoid making implicit assumptions about user behavior or the behavior of other parts of the application.
2. For cookie-injection, validating/sanitizing user input before applying it to a cookie value.
3. For client-side path traversals, sanitize/validate input before concatenating it with a client-side generated request.
4. For race conditions, the remediation can vary, but the strategies mentioned in this resource are a great start.
5. For referral hijacking via cookie fixation, the remediation for cookie-injection applies as well as preventing other methods of setting a cookie such as Cross-Site Scripting (XSS).

In this first part of our series, we’ve explored the fundamental architecture behind referral rewards programs, identifying three common implementation patterns and the security vulnerabilities that frequently accompany them. From business logic flaws to cookie injection, client-side path traversals, race conditions, and the newly identified referral hijacking attack vector, these programs present a rich attack surface that is often overlooked during security reviews.

Companies implementing referral programs should carefully consider the security implications of their chosen approach, following the recommendations outlined above to mitigate potential vulnerabilities. A proper implementation can provide the business benefits of a successful referral program without exposing the company to unnecessary risk.

In Part 2 of this series, we’ll move from theory to practice by examining real-world examples of vulnerable referral programs. We’ll provide detailed case studies of exploits discovered during our research, demonstrating how these vulnerabilities manifest in production environments and the impact they can have.