How it was possible to run a XSS worm on RunKeeper

Do you know RunKeeper?

RunKeeper is a GPS fitness-tracking application supporting more than 23 million users, launched in 2008. RunKeeper is a Boston-based company, which raised $10 million in a Series B financing, led by Spark Capital. It also hosts a built-out Health Graph displaying health and fitness related data, specific to the user. This application also has an online social network of users that share progress, goals, training programs and mapped routes. What makes this application unique is having released an open API for outside developers to plug into RunKeeper users feeds. (in Wikipedia)

When I was using this nice web application I stumble across some vulnerabilities that could be used by malicious users to create a XSS worm.
This could be achieved by using two type of vulnerabilities.

CSRF on Accounts Settings
It was possible to launch a CSRF attack (http://pt.wikipedia.org/wiki/Cross-site_request_forgery) on Account Settings. Using a external HTML form, a crafted site with a auto-submit JavaScript, a malicious user could modify all the information on a authenticated RunKeeper user without them knowing. This happened because RunKeeper forms lacked a security token or any other validation which allowed a user to POST a request on external sources.

Persistent XSS on name field - Account Settings
This was very dangerous and a major security risk. In the wrong hands it could be used to launch dangerous attacks and infect millions of users.

The XSS was automatically executed on user Account Settings and on the profile page of the user affected - http://runkeeper.com/user/dsopas/profile. Even the public profile was affected with this issue (no need for authentication).

When saving the profile, the POST request to http://runkeeper.com/settings?saveProfile= submits the following:

username=dsopas&fullName=David+Sopas&gender=M&birthday=May+01+2000&location=&athleteType=CYCLIST&goal=Sports&achievementGoal=MAINTAIN&workoutFrequency=FIVE_PLUS&skillLevel=INTERMEDIATE

Imagine a specially crafted site with a auto-submit form taking advantage of the CSRF I mentioned with the "fullName" parameter:

CLICK HERE "><img src=x onerror=prompt(document.cookie)><div x="

This would save the authenticated user new "fullName". Each time a user visited his profile would launch the attack (in my proof-of-concept it shows the victims cookie).

Modifying this POC a little bit, a malicious user could have a worm propagating on RunKeeper - stealing users cookies, gathering private information, propagating malware, ...

How dangerous?
In 2005, a XSS worm called Samy carried a payload on MySpace that would display the string "but most of all, Samy is my hero" on a victim's profile. When a user viewed that profile, they would have the payload planted on their page. Within just 20 hours of its October 4, 2005 release, over one million users had run the payload, making Samy the fastest spreading virus of all time.
This was also possible to achieve with this RunKeeper security issues.

I would like to say that RunKeeper handled this security issues very serious and they seem to really care about security and their clients.
I'm glad I helped them.

Timeline
10 Oct 2013: Got first contact with RunKeeper and sent the advisory
11 Oct 2013: RunKeeper replied that they're working on both issues
21 Oct 2013: RunKeeper gave me a detailed information on patching plan
05 Nov 2013: RunKeeper confirmed that both issues are fixed
12 Nov 2013: Full disclosure