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

[bruce bruce]

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/e5fa838e/attachment.htm