Cross origin CSRF via stored and reflected XSS
Poking around on the highly marketed Christian dating site, Christian Mingle, I was curious if I could locate any simple CSRF or XSS vulnerabilities; and well this lead to a string of XSS attacks that would ultimately give me member’s billing addresses. To successfully mount the attack, the attacker must only get a member to open a chat session and stored XSS will take care of the rest.
Two domains are in play here (think same-origin policy):
Since the “www” site was used for account management I started to look for parameters that would be good CSRF candidates. Since session cookies were “HttpOnly” protected and the password resets required knowledge of the current password, I looked to requests dealing with billing. At first glance this didn’t seem like it would work either since billing was handled by a 3rd party website. However, upon further review a unique session token was generated on the “www” domain to hand off the transaction.
Figure: Update Billing
Clicking to update billing information will redirect the member to the change_payment_method.html webpage which generates the session token, and then immediately redirects to https://secure.sparks.net/ with the token submitted in the requestData HTTP POST parameter.
Figure: Generate session token
Figure: Session token grants access to billing info on secure.spark.net
In order to access a member’s billing information, we’ll need their browser to request access to the billing page and send us the generated session token.
After a few tries, the following request parameter succeeded to execute for XSS:
So after this I was finally able to put together the following proof of concept together to perform CSRF to retrieve the session token via a stored and reflected XSS:
Figure: Script1.js hosted on some web server
Figure: Script2.js hosted on some web server
Now to get the party started just send this in chat:
Monitor your web logs and wait for the token to show up in the requestData GET parameter.