A Tale Of A DOM Based XSS In Paypal
We have already disclosed lots of findings related to DOM Based XSS and this article talks about a pretty interesting DOM Based XSS vulnerability i found long time back inside paypal. A DOM Based xss vulnerability also known as the third type of XSS vulnerability or type 0. This vulnerability occurs due to the fact that developers don't sanitize the input before it reaches a sink. A Sink is defined as anything that generates HTML, not every sink is considered as dangerous, however there are some common sinks that should be avoided and are mentioned at DOM Based XSS wiki .
The situation with DOM Based xss is getting worse now a days, not only because of dynamic JS libraries such as YUI, Jquery, Jquery mobile etc, but also with programming languages such as PHP that are more natively supporting HTML 5 features. One of the aspects of a DOM Based XSS vulnerability that i discovered was with tracking scripts such as Eloqua, Sitestat, Omniture, etc as they often introduce dangerous sinks. Examples are here and here. The same is the case with sharing buttons such as google plus, addthis etc.
A Vulnerable Example from W3schools
The worsed part about DOM Based xss apart from it's complexity is the fact that lots of learning references and guides teach developers to code things in an insecure way i.e. in a way that would introduce vulnerabilities automatically. The following screenshot is taken from the jquery learning section of w3schools. The website needs no introduction, it is the most commonly referred websites for beginners to learn various programming language.
The Tale Of Paypal DOM Based XSS
The financing.paypal.com subdomain was a subject of DOM Based xss vulnerability. The subdomain had a feature which triggered my interest, which allowed the users to create ad units of different sizes. The size of the ad was being handled on the client side with the help of jquery.
https://financing.paypal.com/ppfinportal/adGenerator/webCopy?460 * 80
The above input would display "460 * 80" in front of the Selected Size Option, Changing the text with our own input would result in the same text being outputted on to the screen. This means that our input that is taken from a source is being passed through a sink to be displayed upon the screen. So, what happens if we change the input with our XSS payload, for example - <svg/onload=prompt(1)>.
With that being said, as per DOM Based XSS wiki google chrome does not encode certain characters when passed after a hash. Therefore, we could add an additional hash after the ? mark to get our payload executed.
With some debugging i was able to determine the exact cause of the vulnerability. The following screenshot highlights the line of code that was responsible for the cause of this vulnerability.
The line 517 represents the source being document.url, a split function is called which splits everything being sent after the ? mark and saves it inside a variable called url.