Menu
▾
▴
[Tikiwiki-devel] Jitfilter and our community
|
From: WEBER P. <Pat...@co...> - 2008-10-30 20:07:44
|
Hi Louis-Philippe ! I agree that filtering variables this way will be very flexible, but I fear that it will make TikiWiki less secure on the long term due to our community. To be more precise and honest : We welcome everybody to become a TikiWiki developper, even people with very few development skills. This is, from my point of view, a good philosophy that we must really preserve. This make TikiWiki different from most of the other projects (developping the wiki way ;) ). BUT, due to this, we may have more and more code that does not correctly use the filtering. I suppose that some developpers won't correctly filter their variables and some others not filter at all (because of lazyness or simply because they don't understand all this stuff). Since the filtering is not mandatory, it will work :( We don't have the manpower to verify filtering everywhere in new features. It may regularly result in adding new security holes in each release. I don't want that. Security is too important. I'm not against a solution based on jitfilter or anything else. I just think that it's a bad idea to filter in all scripts this way. There is other solutions that are more acceptable, IMO. For example: 1) filtering during tiki-setup to be sure it's always done before using variables in small and not well verified or new scripts (like what we do right now), 2) filtering XSS on the output only (like giving smarty output to htmlpurifier), and keeping a simple type filtering on input (we have both on input right now), 3) filtering the way you are doing it, but with a default aggressive filtering (like the one we have now in sanitization) if no filter is explicitely done For solution 1, which is currently used and for which we all know the weaknesses, it could be enhanced by simply: - not doing XSS filtering on variables that does already not allow characters used by XSS attacks (see 'strong var type checking' in tiki-setup_base.php), - removing <x> with something like a simple function xss_unfilter() that could be applied on other variables when using them. For solution 2, it is the only solution that will really protect us from XSS. This is because filtering inputs is not enough since you can imagine a way to generate an XSS after the filtering by using wiki plugins or other input modifications, cookies, DB, ... This solution, using HTMLPurifier on the output, was proposed a long time ago. I think it's quite secure (for XSS), but there is a performance problem (not sure, did no benchmark using HTMLPurifier) For solution 3, why not. To conclude: - Don't forget that TikiWiki Community is open to anybody, - Security should be done everywhere and newbies, not very skilled developpers or lazy contributors don't have to worry about too much details, - Filtering should not complicate the code. It should be as transparent as possible for developpers, - XSS will be correctly handled by an output filter (e.g. smarty post_filter). If HTMLPurifier can do this with a small impact on performances, I'll vote for it, - Specifying more precise/relevant input filters on each scripts could be OK, but with a default really secure filter for variables that could have been forgotten by people adding them What do you think ? Sorry, I should have react earlier on your jitfilter experimental branch, but I didn't found the time :/ Nyloth. -----Original Message----- From: lph...@us... [mailto:lph...@us...] Sent: Thursday 30 October 2008 19:50 To: tik...@li... Subject: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[15413] branches/experimental/jitfilter/ tiki-view_tracker.php Revision: 15413 http://tikiwiki.svn.sourceforge.net/tikiwiki/?rev=15413&view=rev Author: lphuberdeau Date: 2008-10-30 18:50:09 +0000 (Thu, 30 Oct 2008) Log Message: ----------- [MOD] More filters Modified Paths: -------------- branches/experimental/jitfilter/tiki-view_tracker.php Modified: branches/experimental/jitfilter/tiki-view_tracker.php =================================================================== --- branches/experimental/jitfilter/tiki-view_tracker.php 2008-10-30 15:52:12 UTC (rev 15412) +++ branches/experimental/jitfilter/tiki-view_tracker.php 2008-10-30 18:50:09 UTC (rev 15413) @@ -328,6 +328,7 @@ $ins_fields["data"][$i]["value"] = ''; } elseif ($fields["data"][$i]["type"] == 'u') { // user selection + $_REQUEST->replaceFilter( $ins_id, 'username' ); if (isset($_REQUEST["$ins_id"]) and $_REQUEST["$ins_id"] and (!$fields["data"][$i]['options_array'][0] or $tiki_p_admin_trackers == 'y')) { $ins_fields["data"][$i]["value"] = $_REQUEST["$ins_id"]; } else { @@ -364,6 +365,7 @@ } } elseif ($fields["data"][$i]["type"] == 'g') { // group selection + $_REQUEST->replaceFilter( $ins_id, 'groupname' ); if (isset($_REQUEST["$ins_id"]) and $_REQUEST["$ins_id"] and (!$fields["data"][$i]['options_array'][0] or $tiki_p_admin_trackers == 'y')) { $ins_fields["data"][$i]["value"] = $_REQUEST["$ins_id"]; } else { @@ -382,6 +384,7 @@ } } elseif ($fields["data"][$i]["type"] == 'c') { // checkbox + $_REQUEST->replaceFilter( $ins_id, 'alpha' ); if (isset($_REQUEST["$ins_id"]) && $_REQUEST["$ins_id"] == 'on') { $ins_fields["data"][$i]["value"] = 'y'; } else { @@ -440,6 +443,7 @@ } } elseif( $fields["data"][$i]["type"] == 'y' ) { // country list + $_REQUEST->replaceFilter( $ins_id, 'striptags' ); if (isset($_REQUEST["$ins_id"])) { $ins_fields["data"][$i]["value"] = $_REQUEST["$ins_id"]; } This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ------------------------------------------------------------------------ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Tikiwiki-cvs mailing list Tik...@li... https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs |