Enforce output sanitizing

[zool]

When an image is drag-and-dropped into the edit field the onmouseover and other event attributes remain intact. There should of course be server-side validation, but currently the XHTML snippets produced are unsafe in themselves and make javascript code injection way too easy.

[fredck]

What if one really wants the event attributes to remain untouched? We can't simply strip them.

Also, as as you have said, the injection could be in any case easily done without a proper server side check.

Any proposal?

[zool]

That is true. It is a tricky question. Is client-side validation better than no validation at all?

I suppose what's really needed is some kind of validation method/function in the integration modules. For PHP there are XHTML validator modules like  KSES. I haven tried it out though.

On the third hand, people might use FCKeditor for trusted users. But I think many people have a false feeling of that the output is safe, and that client-side-validation is sufficient. Is a visible note in the installation instructions enough?

[alfonsoml]

I don't see a real benefit to add the needed code to provide such protection in the client side as it can easily bypassed, and on the other hand it can bring new errors and problems for the people that don't want their event handlers touched.

Besides event handlers you should also look for javascript expressions in the style properties, and so many other things that you really need a server side code to do proper clean up of anything that you allow, and I wouldn't allow anything resembling html from an untrusted source.

[martinkou]

How about making it an option in the server side integration code? Some filtering is definitely needed if you want to put FCKeditor in a public site, like a public forum.

From a brief inspection of source code, KSES seems to work by allowing only a user configured set of XHTML tags and attributes, and disallowing the rest. There are some checks it can do with the attribute values as well. But right now it cannot check for something like this:

<a href="javascript:make_computer_explode();" />

or

<div style="background-image: url(javascript:eval(document.all.my.exploit.code))" />

But I guess these can be prevented by disallowing "javascript:" in risky places.

[fredck]

One important feature that we'll be working on for version 3.0 is "code sanitizing". It will not be a client side feature. It will be part of the server side integration files. It should be possibly extensible by end developers, so they can also define their custom rules.

There are many articles in the web about it. I invite all you to come with nice links we should check when working on it. Thanks.

[fredck]

We'll be working on sanitization on future releases, when introducing the server side integrations, which will not be available in the first release.