The Bug That Exposed Your PayPal Password

And Credit Card Number Too

When hunting for security issues, the pursuit for uncharted assets and obscure endpoints often ends up taking the focus away from obvious, but still critical, functionality.

If you approach a target like you are the first person to ever perform a security assessment on it, and check everything thoroughly, I believe you are bound to find something new — especially if the code you are testing has been in continuous development for a while.

This is the story of a high-severity bug affecting what is probably one of PayPal’s most visited pages: the login form.

Initial discovery

While exploring PayPal’s main authentication flow, I noticed a javascript file containing what appeared to be a CSRF token and a session ID:

This immediately drew my attention, because providing any kind of session data inside a valid javascript file usually allows it to be retrieved by attackers.

In what is known as a cross-site script inclusion (XSSI) attack, a malicious web page can use an HTML <script> tag to import a script cross-origin, enabling it to gain access to any data contained within the file.

Sure enough, a quick test confirmed the XSSI vulnerability and, although a javascript obfuscator was used to randomize variable names on each request, the interesting tokens were still placed in fairly predictable locations, making it possible to retrieve them with just a bit of extra work.

However, a secret is only as good as the damage you can do with it. I immediately set out to find out what exactly _csrf and _sessionID were and if they could actually be used in a real attack.

Digging further

After countless attempts to replace regular CSRF tokens inside authenticated requests on PayPal’s platform with the value of _csrf , I came to the conclusion that a classic cross-site request forgery attack was not possible using this specific token. Similarly, a victim’s _sessionID was unfortunately not enough to impersonate them on PayPal’s site.

Next, I went back to the vulnerable script and followed the tokens to find what they were actually used for. This led to a deep dive into one of PayPal’s main protection mechanisms used to prevent brute force attacks, the security challenge. While this functionality is used in many places, I will be focusing on the main login form.

The idea is pretty simple: After a few failed login attempts, you are required to solve a reCAPTCHA challenge before you can try again. The implementation, however, may raise some eyebrows.