XSS on FCKeditor

What's FCKeditor?
FCKeditor is a ready-for-use open source WYSIWYG text editor from CKSource designed to bring common word processor features directly to web pages, simplifying their content creation. It aims to be lightweight and requires no client-side installation. This tool is already deprecated and was updated to CKEditor but still many open-source projects use FCKeditor.

When using Drupal and PHPList I come across something that caught my attention. The about page (fck_about.html) of FCKeditor showed a window with the User-Agent, Browser and Platform. I thought to myself: I think we can inject something into this window.

I checked the source code and voilà...

document.write( '<b>User Agent<\/b><br />' + window.navigator.userAgent + '<br /><br />' ) ;
document.write( '<b>Browser<\/b><br />' + window.navigator.appName + ' ' + window.navigator.appVersion + '<br /><br />' ) ;
document.write( '<b>Platform<\/b><br />' + window.navigator.platform + '<br /><br />' ) ;

The lack of sanitizing those parameters will allow code to be executed on the browser.

To give a proof-of-concept, I used a Chrome plugin to change the User-Agent for a XSS vector.

Of course this vulnerability is not critical. It requires user interaction to exploit this. You always need to control the victims browser to execute an attack. Needless to say that if you have the victims browser the attacker didn't need to inject a XSS (IMO)...
It's a self-XSS so it needs more than a link to attack someone. It needs to be combined with other attack, like good social engineering skills. I reported this issue because even a self-XSS it's a vulnerability. It can be used to check vendors security response; what kind of vulnerabilities are most common on their products; etc.

By the way FCKeditor is still used in millions of websites and just to be sure update your version.

This issue was fixed on version 2.6.10.

We would like to announce a small update to FCKeditor. FCKeditor 2.6.10 is a minor security release that contains a fix for a recently reported issue where the About dialog window could hypothetically be used for an XSS attack provided that the user was forced by the attacker to change his browser properties.
Please note FCKeditor is a retired and no longer supported product. No further updates will be provided and it is highly recommended to upgrade to its successor, CKEditor, that is a far superior, feature-rich, and mature product.

Also present in 2.6.10 changelog:

Values displayed in the "About" dialog window were not properly escaped - reported by David Sopas.

My congrats to the CKSource team for the fast support showing that they're a company that cares about security.

Alexa reflected DOM XSS

Alexa Internet, Inc. is a California-based subsidiary company of Amazon.com which provides commercial web traffic data. Once it is installed, the Alexa Toolbar collects data on browsing behavior and transmits it to the Alexa website, where it is stored and analyzed, forming the basis for the company's web traffic reporting. As of 2013, Alexa provides traffic data, global rankings and other information on 30 million websites, and claims that 6 million people visit its website monthly.

When using Alexa.com website I found a reflected DOM XSS that could be used by malicious users to trick innocent visitors.
This vulnerability was present at tags.js from a remote location and the variable "tagSrc" lacked the proper sanitizing.

Vulnerable code:

t.tagSrc = '<div align="center">'+t.tagSrc+'</div>';
document.writeln(t.tagSrc);

When modifying the URL you can inject the code you want:

http://www.alexa.com/tfBuster.html#?flashVer=11&ver=1.25&th=11117008646&tagKey=4138765495&site=alexacom"></script><script>alert(document.cookie);</script><!--&adSpace=miscellanious&center=1&env=display

This issue already has been fixed but it took more than 3 months. It's strange that a company that's so big couldn't fix this type of vulnerability faster.
Malicious users could use this DOM XSS to spread phishing campaigns with a higher success rate.

Timeline:
13 December 2012: Reported this issue.
13 December 2012: Alexa replied and forwarded to engineering team.
26 December 2012: I requested a follow-up. They replied that still unpatched.
15 March 2013: Alexa replied that the DOM XSS has been fixed.