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

[Helmut Hummel]

Hi,

On 27.09.10 19:27, Ernesto Baschny [cron IT] wrote:
> Jigal van Hemert schrieb am 27.09.2010 17:10:
>>
>> Now an admin can introduce XSS in the news messages. The header text is
>> htmlspecialchars'ed, but the body text isn't. It can easily be processed
>> by  RemoveXSS::process(), can't it?
>>
>> I tried it with < script >alert('XSS');< /script > (without the spaces)
>> in both header and text, but it triggered my Antivirus software in the
>> temporary internet files.
> 
> I thought about that too.

Me too. Obvious isn't it ;)

> First reaction was like Steffen: "Why? An admin can do everything
> anyway". But overall, most issues arise from the fact that the admin can
> edit all content and he can *install extensions*. As soon as you disable
> EM (which is now possible, as EM is a sysext), your admin cannot do
> "everything".
> 
> Of course the backend is by far not safe for XSS from admin-users, but I
> think we can at least disallow it to happen with new things we are
> introducing.

I pointed out several times on several TYPO3 mailing lists, that the
concept of a super user account which is allowed to do everything an
outdated concept security wise and that we should think of possibilities
to either limit the rights of admin users in TYPO3 or empowering regular
users to do some (but not all) maintenance tasks.

But this is not at all in the scope of this RFC.

> So I agree with Jigal that on new features we should care to allow the
> admin to do no more than what the new feature is supposed to to. Adding
> a RemoveXSS call is probably the easiest way to handle it in this
> situation, as we clearly mark that content from being "sanitizeable".

I did not intervene in this particular case because of:

1. An admin probably cannot install extensions if the EM is disabled,
but it is still in the scope of an admin to create and maintain template
records and html templates. An admin has also access to the plain HTML
content elements. As of now it is impossible to prevent a malicious
admin doing a Cross-Site Scripting attack.

2. The securest way would be to HTML escape the data entered. So if we
would like to do something secure here we would need to abandon the
possibility to enter plain HTML.

3. removeXSS is very limited and in a kind of unmaintained state. It
also produces false positives, which can lead to rather unexpected results.

4. Although it is not very comfortable to enter plain HTML (you need to
escape things like "&", "<", ">" yourself) there may be usefull in some
cases to higlight something (<b>IMPORTANT</b>) by using HTML tags. It
could probably also be useful to create a popup by JavaScript to really
higlight something.


Because of the first point, I do not have a problem not sanitizing the
body of the notes.

> 4) Added the t3lib_div::removeXSS call when rendering the entry in the
> login form.

Because of the third point I would preferably not allow HTML at all
instead of using removeXSS. I think for that usecase plaintext would be
enough, wouldn't it?

If we do it without HTML we also enhance the usability because when
writing a news an admin does not have to manually take care of
linebreaks or escaping special characters (like mentioned above).

Find attached the version 5 ot the patch which simply replaces the
removeXSS call with nl2br(htmlspecialchars()).

But I'm also fine with Ernesto's (only would remove removeXSS then) or
Ingo's version.

+1 by reading and testing all mentioned versions. I let the committer
decide ;)

Regards Helmut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 15812-v5.patch
Type: text/x-patch
Size: 6671 bytes
Desc: not available
URL: <http://lists.typo3.org/pipermail/typo3-team-core/attachments/20100927/cc1ddbc4/attachment.bin>