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