[TYPO3-core] RFC: #15812: Add backend maintenance for login news

[Helmut Hummel]

Hi,

Am 07.10.2010 14:30, schrieb Steffen Gebert:
>
>> I personally never used that feature and plain text would be enough for
>> me. So I like the way it is implemented now. But I'm not the only one
>> using TYPO3, am I? ;)
>
> I'm using it and now it's very limited. I don't like it that way and
> don't want to use the old, deprecated feature. So why should RemoveXSS()
> not be enough?

To RemoveXSS:

Now I can elaborate a bit more since the security fix for it is out now.

Why I don't like RemoveXSS:

1. It is kind of unmaintained because nobody (except for Jigal some time 
ago) really digs into it keeping it up to date with every new attack 
vector that might appear in the future. It's just lying there and we 
hope it is doing it's job right. The latest security problem we had with 
RemoveXSS shows that this baby would need more care taking.

1a. The code is difficult (because of the regex) which makes it hard (at 
least for me) to understand what it really does.

2. It uses a blacklist approach, tampering some (probably all?) 
problematic keywords, mostly unaware of the context where they are used.

EDIT: It's much better than I thought, but still blacklisting is error 
prone and needs someone keeping the blacklist up to date. Although I'm 
not aware of a concrete problem, I'm pretty sure that a hacker could 
find a way around it. I would not bet a penny that this is totally secure.

3. The tampering it does might be goodfor some (most?) cases, but the 
result looks pretty ugly and it breaks the HTML output, produces invalid 
HTML.

4. Having said all this one last thing: It teaches a wrong lesson which 
is: "Yeah, let's use RemoveXSS and wer're done with security".

We use RemoveXSS in the core for some things, but we do it in very 
defined contexts and we _never_ use the output of it but simply check if 
RemoveXSS does anything on the string and if so return nothing instead.

That's why I'm conviced that using RemoveXSS for this very usecase would 
be a semi secure solution. We should either deny all HTML and escape the 
values (which is secure and that's how it is now) or just allow all HTML 
(with all drawbacks it has) and define this (also) as a TYPO3 admin 
task; because we all know an admin in TYPO3 has so much power (and it's 
not easy to change that), we can be fine accepting that (additional) 
very theoretical attack vector.

What we really need is HTML Purifier[1], which uses a whitelist 
approach, always returns cleaned up and valid! HTML as a result and is 
an open source project which is actively developed. I have it on my list 
to get it into 4.5, but had no time to do it until now.

Another solution would of course be to use RTE processing, but this has 
been discussed as beeing too complicated and/or not suited for the backend.


I hope I made my points a bit clearer now.

Regards Helmut

[1]http://htmlpurifier.org/