A new XSS vulnerability was identified on Paypal.com earlier today, found by d3v1l and disclosed on both Security-Shell and XSSed. The problem is with the parameter sender_country in a transaction called nvpsm. NVP is Paypal’s API for Merchants to use when interacting with the Paypal web site, it stands for Name-Value Pair. SM is short for ‘send money’. A problem such as this can be used to capture a user’s session (essentially log in as that user) and perform privileged actions (money transfers) as that user, as well as send a user a valid Paypal URL but then redirect them to a malicious third party site (phishing, malware, etc.).
The following is provided as example in the posts mentioned earlier:
Which results in:
Paypal is reflecting the supplied script in the error message they are displaying, as seen in the HTML source of the page:
Error COWException: invalid country ""><script>alert('XSS')</script>"
Rather then display an alert box, an actual attacker would either redirect the user as shown below, or capture and send their session cookie (a piece of text the browser stores temporarily to identify a user’s logged in session) to a third party web site.
https://mobile.paypal.com/nvpsm?amount=50.0¤cy_code=USD&sender_country=%22%3E%22%22 %3E%3E%3E%3E%3Cmeta%20http-equiv=%22Refresh%22%20content=%220;url=http://www.google.com /%22%3E%20%22%22
XSS at a High Level (from previous post)
While the definition is ever expanding, XSS attacks are generally considered a type of injection problem where malicious input is injected into an otherwise trusted web page causing an unexpected behavior such as sending data to or from an unknown third party web site (cross site). Because the script is being run in the context of the trusted web site, it has access to cookies such as session tokens, as well as any other user information available within the security context of that web site. XSS vulnerabilities are somewhat common in web applications and will occur unfettered wherever untrusted input is not validated by the web application or encoded before output back to the user.
PayPal (from previous post)
The San Jose based company is owned by eBay and has more than 78 million customer accounts. As such the service is used to clear many of the transactions on the popular auction site. The service allows users to send money without needing to share financial information, a key enabler for sending and receiving money from third parties on the Internet. They are in some 190 markets around the world and can work with 19 different currencies.
In 2008 roughly $60 billion dollars moved through Paypal’s systems.
Paypal does make available additional authentication protection in the form of a one time password token called a ’security key’ by them (similar to the ones made popular by RSA). The token costs five dollars and is available to residents of Australia, Germany, Canada, the United Kingdom and the United States. Paypal however allows a bypass of this hard token by allowing the user to enter further information such as credit card or bank number, severely impacting its effectiveness as a security measure.
Further authentication “on the front door” of the web site (the login screen) does not prevent a user session from being hijacked after authentication as is possible in a cross site scripting attack like this one.
It is worth it to note that PayPal is PCI compliant, being subject to quarterly vulnerability scans, as stated on their site.
Users have the ability to go through a process to apply for a refund from PayPal if their account is broken into, but this is not always a clean process. A site should almost never reflect (redisplay) input received from an untrusted source (“the user”), which in this case is the browser, without escaping the output. PayPal has had similar problems with cross site scripting in the past, including an incident back in March. While XSS attacks can be downplayed, a site such as PayPal that performs money transfers (for users of eBay it is basically the only way to send and receive payment) usually has to address these problems quickly. A more comprehensive approach (a shared function that encodes all output originating from untrusted input on the site) is something they could start looking towards to protect their users.
Filed Under: Cross Site Scripting