Re: New release is HERE! Vexim 2.2.2 RC1, Google code, and more!

  Got it. Thanks for the explanation, Mike!

Here's a potential example of the unflexibility you mentioned: I haven't 
checked it, but it looks like with this logic in place, not only the 
user cannot have characters like % or $ in their password, but they are 
also never warned that these characters are being removed from the 
submitted password.

Rimas


2010.05.14 13:04, Mike Garratt rašė:
> "config/functions.php" is included at the top of all php files which 
> contains code at the top sanitize all POST & GET variables.
>
> Specifically:
>    // Strictly three aren't alone functions, but they are functions of 
> sorts
>    // and we call it every page to prevent tainted data expoits
>    foreach ($_GET as $getkey => $getval)     {
>        $_GET[$getkey] = preg_replace('/[\'";$%]/','',$getval);
>    }
>    foreach ($_POST as $postkey => $postval)     {
>        $_POST[$postkey] = preg_replace('/[\'";$%]/','',$postval);
>    }
>    $globals = array('_GET', '_POST');
>    foreach ($globals as $i => $val) {
>        foreach ($$val as $j => $var)    {
>            if ( isset($$var) )  {
>                unset($$var);
>            }
>        }
>    }
>
> So the POST variables aren't technically being inserted "directly" 
> into SQL statements, just the sanitizing is centralised.  The key 
> thing to note here is it is vital that any additional files added to 
> the source includes config/functions.php at the top.
>
> I wouldn't have necessarily approached it this way if I was writing 
> this from the ground up (this approach can be a little inflexible when 
> you want to permit any of the stripped characters + harder to see that 
> the input is sanitized when auditing) but I wanted to minimize the 
> scope of the changes I was doing to just cover security fixes as much 
> as possible and avoid rewriting vast sections of the code.
>
> Cheers,
>
> - Mike
>
> On 14/05/2010 7:34 a.m., Rimas Kudelis wrote:
>>  2010.05.13 22:24, Avleen Vig rašė:
>>> This is a big release, full of some quite critical security fixes.
>>> This has been needed for a very long time, and I'm really glad they
>>> were able to do this.
>>
>> Woohoo! Though I still see $_POST variables being put right into sql 
>> statements. Are they being processed in any way before doing that?
>>
>> As a side note, expect a UTF-8 support patch from me in a few weeks 
>> (got some unrelated work to do ATM).
>>
>> Rimas
>>


_______________________________________________
Vexim mailing list
[email protected]
http://silverwraith.com/mailman/listinfo/vexim