htmlspecialchar on author name done after firing events to plugins instead of before

[Beat]

Hi devs,

Just wanted to give a heads-up of a regression bug in joomla 1.5.13+
introduced by a "late sanitization from possibly corrupted database
content" done way to late and only in default core Joomla templates
(also in Beez core template override).

1) it doesn't cure the vulnerability aside of core templates and
templates which do not override content output
2) it breaks all content plugins which were putting html links to the
user profile in that author spot. E.g. CBAuthorBot, BK Author Link and
Agora AuthorBot, gAuthor.

Question: Would it be possible to do the database-content cleanup
BEFORE template, and also BEFORE calling the plugins triggers instead
of after calling the plugin triggers, to avoid htmlspecialcharing the
html code coming from joomla plugins ?

Details here:
http://forum.joomla.org/viewtopic.php?f=473&t=428193&p=1809544#p1809544

Logically, sanitization of corrupt database should be done during
upgrade of Joomla, or as soon as read from database at latest.

At least, as I understand, it's only "author" which might be corrupt
in database, not "created_by_alias" ?

Thanks for your attention,
Beat
http://www.joomlapolis.com/

p.s. posting backlink to here from forum.

[Ian MacLennan]

The issue isn't corruption of the database so much as who is able to enter those values that appear on the site that could make the site vulnerable to an XSS attack.

The better solution is to make sure filtering is done in the same manner that content is filtered (with a configurable blacklist/whitelist filter).  If somebody wants to investigate and submit a patch we'd be more than happy to review it.

Ian

[Amy Stephen]

Even with better (meaning more flexible) input filtering, core still
should filter input and escape output, as is being done now. Not
everyone wants to use complete HTML filtering and that output should
then be escaped.

Shiflett argues two practices, when consistently followed gets rid of
top 5 security issues:

- Filter input
- Escape output

http://shiflett.org/blog/2005/feb/my-top-two-php-security-practices

If anything, I'd argue the core should do this in the view after the
plugins run and before running the layouts. Technically, escaping as
you display the content is the best way (like is done in the core.)
But, I think Beat raises a good point about non-core override
layouts.

One of the plugins I looked at doesn't escape the output and then
changes an array element that is text (author name or alias) to
include a link. That creates a problem when the output is escaped.
But, moving the escaping of output before the plugins only makes it
less secure and provides no assurances that plugins will escape the
output (the example I looked at does not) and there is no assurance
that another plugin won't create the same problem by escaping the
output, too.

Some of these examples in that thread might be better modules. Some of
the ones listed seem to do it correctly by changing the article->text
and not a specific array element.

I'd say if there is any debate it would be about where core should
escape the output - and there, I would argue inside of the view since
that is the last point that core will always have control. (Of course,
third party components would have to follow that pattern.)

My 2 cents.

[Beat]

Ian,
Yes, good idea. The standard html input filtering instead of
htmlescaping would be fine too, as you really want to remove standard
XSS like script tags. No need to have white/blacklist settings. The
standard "bad-list" is fine, as scripts can go into the head section
of page.

So that would be just replacing the call to escape to the call to the
html-input-sanitization.



Amy,
Thanks for your "2 cents".

I replied also to your forum post, so won't repeat it here, except by
linking to my reply there:
http://forum.joomla.org/viewtopic.php?f=473&t=428193&p=1810018#p1810018

To get back to the backwards-compatibility issue here (feel free to
start another topic for web-security in general):

Basic problem is that the database content for names should be clean
text-only thanks to input filtering, as assumed by components,
plugins, modules and so on.

Ok, that seems wasn't done properly in previous joomla releases.

Now how and where to fix it ? :
1) in database at upgrade ?
2) at read-out of database only for joomla's internal uses ?
3) or at very end in the chain as done now for content author names ?

Obviously, only 1) will sanitize properly, and protect all extensions
which assumed database to be a safe source, properly input-sanitized,
like joomla supposed too until now....

2) and 3) won't cure the multiple issues in components, modules, and
plugins still assuming database to have been properly input-filtered.

Now I'm only suggesting to move from solution 3) to 1) or at least to
2) in order to fix this backwards-incompatibility.

Of course, I'm open to better solutions too, but didn't see a better
one yet (see my forum post for details), except Ian's which is fine
too to cure the bug of current fix at level "3)".

With Respect and Best Regards,
Beat
http://www.joomlapolis.com/