Re: {SPAM?} Re: New release is HERE! Vexim 2.2.2 RC1, Google code, and more!

Mike Garratt <[email protected]> Fri, 14 May 2010 22:48:24 +1200
Newsgroups gmane.mail.exim.vexim.devel
Message-ID <[email protected]>
On 14/05/2010 10:16 p.m., Rimas Kudelis wrote:
>  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
>
Exactly... I had a problem importing users from another system that used 
md5crypt passwords... I wanted to paste their hash into an extra field I 
added for importing them, and the munging of the $ symbol got in the way.

- M

> 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


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