K3 Input library "replacement"

Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> Sun, 31 Mar 2013 23:45:22 +0200
Newsgroups gmane.comp.web.gallery.devel
Message-ID <CA+z51A7A9pPMyAoUC8KgQPmX2-fFz8Vu+J+b4JYhxaQhifd2Ww@mail.gmail.com>
Hey gang,

Disclaimer: I am not a XSS pro... those with more experience are
encouraged to correct me as needed :-).

So, K3 did away with the Input module, and finding a "replacement" is
kinda tricky.  A bit of history:

v2.x: Input library handled inputs and performed a regex-based XSS
cleaning (see Input::xss_clean_default(), for which
Security::xss_clean() was effectively an alias).

v3.0: Input library removed in favor of handling $_GET/$_POST/$_COOKIE
directly.  XSS cleaning moved to Security::xss_clean(), which can be
used to more-or-less get the same results as the old 2.x Input
library.

v3.0.5: Security::xss_clean() deprecated due to its inability to
reliably clean XSS.

v3.1: Security::xss_clean() removed.

Whereas Kohana didn't leave a ton of documentation/discussion on the
topic, its sister framework CodeIgniter did.  The summary: "xss_clean
doesn't."
http://github.com/EllisLab/CodeIgniter/issues/1705
http://github.com/EllisLab/CodeIgniter/issues/2066

There are some great links and reading in the threads above, some with
stronger opinions than others, but with a pretty consistent consensus:
regex-based XSS cleaning is fundamentally flawed.  So, rather than
ship Kohana with a faulty function, the Kohana team removed it
entirely.

The consensus also seems to be that HTMLPurifier is *the* way to go.

So, it seems that we have a few options:
- Put the same XSS filter we use in 3.0.x back into 3.1.x.  We have
history and a track record with it, and it's small and quick, but we
also have no external support and quite a few sites that say this is
an increasingly bad idea.
- Roll our own beefed-up, still small and quick (e.g. likely
regex-based) XSS filter.  If this is the option, then someone else
will need to jump in as I certainly don't have the expertise to do
this well.
- Include HTMLPurifier.  This is the most highly-recommended route to
take, is *very* actively maintained, and is quite secure.  It also
would eliminate the need for some modules to use $_REQUEST to get
around the filtering (see email thread with Dave).  However, it would
increase our package size and decrease our speed a little.

My current feeling is that we should bite the bullet and go with the
last option, as it seems to be the the option that is the most secure,
the simplest to code up, the easiest to maintain, and the most
future-proof.

Thoughts?

Take care,
Shad

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]