This issue, nicknamed a "web cache deception attack," was discovered by Israeli security researcher Omer Gil, who says it affects many online services.
Gil, who works as an information security team leader at EY Hacktics Advanced Security Center in Tel Aviv, says he already contacted three major companies affected by the issue.
All three companies fixed their issues. PayPal is one of the three, while the other two asked the researcher to refrain from publishing their name.
Bleeping Computer has reached out to Gil and inquired if the attack vector he discovered is a widespread issue among today's web services.
"I believe it's a widespread issue," Gil told Bleeping Computer. "I'm sure it is, but I wasn't looking for more."
"Found this in 3 websites out of only ~30 I was looking at," the researcher added. "I focused my research on applications with bounty programs only. Got 3 in total. I'm sure there are plenty more out there which [are vulnerable but] aren't part of bounty programs. Didn't test those."
The researcher, who is a newcomer to the bug bounty scene, has already received $3,000 from PayPal for his findings. He also described the web cache deception attack vector in a blog post, but a short summary of the attack is available below.
The entire premise of a web cache deception attack relies on how servers created cached pages.
Some servers cache pages with various degrees of personal data. This cached pages aren't normally available for unauthenticated users.
Taking PayPal as an example, Gil discovered that if a user accesses a link pointing to a non-existent resource, the PayPal server will create a cache for the URL section up until the non-existent resource.
For example, accessing https://www.paypal.com/myaccount/home/attack.css would create a cache for https://www.paypal.com/myaccount/home/.
In this particular example, this cached page would include user details as account balance, transaction data, email address, the last four digits of the user's debit/credit card, and possibly more.
All the attacker has to do is to convince a user to access one of these URLs leading to a non-existent resource. The server would cache the page holding personal information and add it to its list of cached pages.
An attacker would then only have to access the same malformed URL in order to receive the cached paged, and indirectly all the user's personal details.
Gil recorded three videos showing his attack in action, creating three caches on the PayPal servers and then accessing the same pages via a Private Browsing session, without logging into PayPal.
Below you can see URLs with red showing the non-existent resource, and green the cached page.
According to Gil, this attack is not limited to only certain kind of filename extensions, such as JS and CSS files.
The researcher found that more than 40 file extension types could be used for the attack, ranging from the popular AVI, DOC, and JPEG, to unknown extensions such as CCT or AIFF.
aif, aiff, au, avi, bin, bmp, cab, carb, cct, cdf, class, css, doc, dcr, dtd, gcf, gff, gif, grv, hdml, hqx, ico, ini, jpeg, jpg, js, mov, mp3, nc, pct, ppc, pws, swa, swf, txt, vbs, w32, wav, wbmp, wml, wmlc, wmls, wmlsc, xsd, zip
All triggered the creation of a (wrong) cache page, even if the link they pointed to didn't exist. Gil says in the case of PayPal, this cache paged hanged around for about five hours, and even more if someone reaccessed the wrong link.
This is not a attack vector to ignore. The researcher told Bleeping Computer that besides PayPal, "for these other two [companies] I took complete control over the [user] account, since the [cached] response contained security answers or session ID."
"The big thing is that it's not about a vulnerability in a specific cache component, or a developing technology, or web server," Gil tells Bleeping Computer.
"It's an attack vector," he emphasises. "It can work with .NET, PHP, Java. [It] can work with IIS, Apache, any other web server, and [it] can also work with various cache components, including major CDNs, reverse proxies and load balancers," Gil added. "It's all around configuration issues."
The two conditions required for this attack to work, according to Gil, are:
In his blog post, the researcher recommends the following mitigations for all server administrators interested in protecting their users.