[Bug 481536] Review Request: enano - Enano CMS, a php-based modular content management system

bugzilla at redhat.com bugzilla at redhat.com
Fri May 29 18:56:22 UTC 2009


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=481536





--- Comment #15 from Dan Fuhry <dan at enanocms.org>  2009-05-29 14:56:20 EDT ---
I don't think you really understood what I was communicating. What I mean by
that statement is as follows.

User input is, of course, always sanitized. I'm not an idiot. What I mean is
that Enano checks values that are already "trusted" (pulled from the database,
or sent through validation already) a second time before sending them to third
party libraries, so that any potentially unsafe input is eliminated before it
could possibly touch 3rd-party code.

If you have, for example, an XSS vulnerability that can be exploited through
MediaWiki's table code, we fix Enano's preprocessor to filter it out, instead
of fixing MediaWiki's table code. To the outside world at large, the
vulnerability is still closed; we just are extra careful to make sure trouble
doesn't ever reach the vulnerable code.

I know this is controversial because it seems like a band-aid or hackish
solution instead of fixing the underlying problem. That's true in a sense.
Anybody that writes Enano plugins is going to read the API documentation and
see that the correct way to sanitize text is with RenderMan::preprocess_text(),
and the correct way to render it is RenderMan::render(), and that stuff like
MediaWiki's table code is considered a private API. If developers avoid using
private APIs, there won't ever be a security concern with regards to 3rd-party
libraries.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.




More information about the Fedora-package-review mailing list