[asterisk-users] PHP can't insert - Can someone please help

[bruce bruce]

Here is the steel strong sanitizer:

$npaa = "$_POST[anpa]";
$nxxa = "$_POST[anxx]";
$blocka = "$_POST[ablock]";

# Sanitize
$blocka_san = strspn("$blocka", "0123456789");

*if ($blocka_san==4 && is_numeric($npaa) && is_numeric($nxxa) &&
is_numeric($blocka) && $npaa>=200 && $nxxa>=200 && $npaa!=900 &&
$npaa!=911) *
*
*
*              {*

  echo "Number passed sanitization";

              }

What do you think? :-)

-Bruce
On Sat, Jul 10, 2010 at 2:17 PM, bruce bruce <bruceb444 at gmail.com> wrote:

> Thanks again. Apparently all POST variables come through as strings. The
> function you pointed out is I think already built in php as
>
> is_numeric() <http://www.php.net/manual/en/function.is-numeric.php>.
>
> <http://php.net/manual/en/function.is-int.php>
> http://www.php.net/manual/en/function.is-numeric.php
>
> <http://www.php.net/manual/en/function.is-numeric.php>If that runs TRUE
> and if I keep my >=200 and !=911 or !900 I should be safe from SQL
> injections. And along with dial-out routes rules, I think I can make this
> stronger.
>
> I have my html/php file set so that the input field only takes 3 digit 3
> digit 4 digit (NPA, NXX, Block) so your purposal of: *'201,0); drop
> database YOUR_DATABASE'; *would fail due to big length and also I tested
> with inputing letters and my IF function caught it and exited.
>
> Further more, everything else (other than phone input fields) is drop down
> boxes with specific numbers or letters inserted in them. I should be 100%
> safe with those right?
>
> By using form POST there should be no other loop holes left opened right?
> It's not like php $_GET so people can't try typing to the browser in this
> format:
>
> http://www.w3schools.com/welcome.php?fname=Peter&age=37
>
> Thanks a lot,
> Bruce
>
> On Sat, Jul 10, 2010 at 1:41 PM, Gerald A <geraldablists at gmail.com> wrote:
>
>> Hi Bruce,
>>
>> On Sat, Jul 10, 2010 at 11:12 AM, bruce bruce <bruceb444 at gmail.com>wrote:
>>
>>> Further to my last post, I added this to santize. I also created a new
>>> mysql user with access to only findmefollow portion of the asterisk table
>>> for limited access and assigned only two simultaneous connections with only
>>> 10 changes queries per hour (as I know that no more queries will be put
>>> through probably)
>>>
>>> if ($npaa>=200 && $nxxa>=200 && $npaa!=900 && $npaa!=911)
>>>
>>> Should that suffice against SQL injections? The if condition changes the
>>> string to number so it removes the chance of people adding
>>> other characters and it also sticks to format NPANXXXX or 2XX2XXXX.
>>>
>>
>> There are two things -- the first is, who call this script? If it's
>> something you control 100%, you can mitigate the risk a bit. I don't really
>> like this tact, because if the script gets repurposed, you end up with
>> something that could be very dangerous.
>>
>> The second thing is simple -- most people think small here, but you have
>> to think big and know a bit about how PHP works. PHP strings are pretty
>> amazing things, and one of the pesky things is that you can put all kinds of
>> things in it. Now, if that string variable is created as a result of a form
>> input, then that string can be anything. For a moment, think about if it
>> $npaa = '201,0); drop database YOUR_DATABASE'; Now, that is pretty nasty,
>> and it would muck up further SQL injections, but now you get the idea. You
>> should always check to make sure the data you are getting is what you are
>> expecting, and exclude what you aren't.
>>
>> So, are your tests sufficient? I can't remember off the top of my head if
>> the string -> integer only considers the first number, or it considers the
>> whole string. (PHP usually errs on the side of ease of use, so I think my
>> snippet above would still pass your test). If your expecting only numbers,
>> I'd write a function that ensures that only numbers are parts of the input.
>> (And not just for the 3 above variables).
>> Really, you should never see $_POST("var") (or any PHP CGI variable) that
>> derives directly from user input.
>>
>> It takes a few minutes extra, but it'll save hours of sorting later if you
>> get hit by a SQL injection.
>>
>> Hope this helps,
>> Gerald
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100710/3a85b46a/attachment.htm