Back in July 2015 I reported an XSS issue to PayPal, it was a DOM XSS on “” 

It’s taken several months but with the issue now fixed I wanted to publish this post.


Let’s Start

I was poking around the checkout iframe PayPal integration on Github when I notice the clientApiUrl parameter contains a URL for a javascript file that the page automatically loads, when you try to change it you get a white page and a bunch of  JavaScript errors.

After a few minutes of digging I found the JavaScript code responsible for validating this URL.

return this._localhostRe.test(url) || this._braintreeDomainRe.test(url);

As you can see there are two validation methods, let’s take a look


The localhost validation regex is allowing any domain that starts with “http://localhost” (I guess the developers used it to test things on a local environment). So… I just need to create a subdomain named localhost on any domain and PayPal will happily load my script.

The exploit worked only on browsers that support mixed content due to the fact we can only load the script on http in order to pass the validation.

To exploit you’d just use the following|created_at=2015-09-30T18:45:01.236715762+0000&merchant_id=yrvvxhf7w35y8v9f&public_key=wmt6n4yhdfp47mbh&paypalBaseUrl=


Hope you guys found this post interesting, any questions or feedback, drop a comment below!

Webkit XSS Editor

This is a short writeup about a technic I found on how to use Webkit XSS editor to your advantage.

As every security researcher knows the “XSS editor” basically killed reflected XSS attacks on every webkit based browser. By reading the requested URL and compering it to the document output the “XSS editor” knows to identify potentially malicious code and block it, this sound grate right? well kind off.

The problem with this logic is that the “XSS editor” just block everything that looks suspicious. this could become a real problem in some cases. an attacker can leverage a JavaScript error to bypass some sort of filter or a validation.<script src="filters.js"></script>

In the example above I force the browser to block “filters.js“, you can also block inline scripts using the same method just include the code into some parameter on your request and the XSS editor will take care of the rest.

As I said this is only useful in some cases but you can pretty much brake any site with this. ; – )