11

A security report we conducted through an outside company reported XSS vulnerabilities in FCKeditor which we're using in our PHP application.

They pointed out that accessing URLs such as:

http://www.ourdomain.com/fckeditor/editor/filemanager/browser/mcpuk/connectors
    /php/connector.php?Command=837<script>alert(0)</script>&Type=837
    <script>alert(1)</script>&CurrentFolder=837<script>alert(2)</script>
    &ExtraParams=837<br><br><br><iframe src=http://www.google.com/ 
    height=100% width=100%></iframe>

Leads to code such as the following being generated (from browser -> view source):

Invalid command.Array<br />
(<br />
[Command] => 837<script>alert(0)</script><br />
[Type] => 837<script>alert(1)</script><br />
[CurrentFolder] => 837<script>alert(2)</script><br />
[ExtraParams] => 837<br>
<br>
<br>
<iframe src=http://www.google.com/ height=100% width=100%></iframe><br />
)<br />

I have no idea what this internal php script of FCKeditor does and whether it could become a source of XSS content into my system? Is this a genuine issue?

Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121
siliconpi
  • 1,087
  • 1
  • 10
  • 20

2 Answers2

12

Usually there's not much you can do about vulns in 3rd party components.
Among your options:

  • Start by upgrading to the latest version. If that fixes it, you're done.
  • Contact the vendor responsibly, and get a fix from them.
  • If it's open source, try to patch it yourself - or find someone who did. Just make sure you do it right, and fixing XSS can be complicated and/or confusing.
  • If none of the above options are possible, consider removing this component from your system. It's always a risk, when taking some other component blindly, if you're not able to get it fixed...
  • In fact, make it a policy to do a security review on any 3rd party code before integrating it into your system.
  • If you absolutely MUST continue to use a vulnerable component - reconsider :). But really, if its a done deal, consider protecting it with a WAF (web application firewall). Doesn't solve the problem, but it can help prevent exploitation...
AviD
  • 72,138
  • 22
  • 136
  • 218
  • 1
    +1. I love the "In fact, make it a policy to do a security review on any 3rd party code before integrating it into your system.". This can be very usefull! – Chris Dale Jan 06 '11 at 09:12
11

FCKEditor is a platform-independent text editor for web applications.

This kind of exploit is a reflected XSS attack vector. You can read more about it in this question here: can-anybody-explain-xss.

This is happening because the FCKEditor does not sanitize the input given in the variables, leading the application to reflect the variables back to the user.

I would recommend following steps:

  • upgrading to the latest FCKEditor
  • Patch it myself and if that does not fix the problem I would patch it myself by applying proper sanitizing to the script. In your case it looks like a simple (int) cast would be enough to address this issue.
  • Request vendor patch ASAP

You can also see a list of other exploits to FCKEditor over at exploit-db.com. Just remember to keep patching your applications!

Community
  • 1
Chris Dale
  • 16,119
  • 10
  • 56
  • 97
  • 1
    Instead of patching it yourself, why not contact the vendor responsibly, and get a fix straight from them? – AviD Jan 05 '11 at 22:28