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 ]