Re: MySql Injection advice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 13, 2009 at 5:52 PM, Ashley
Sheridan<ash@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, 2009-07-13 at 16:30 -0400, Bastien Koert wrote:
>> On Mon, Jul 13, 2009 at 4:18 PM, Haig Dedeyan<hdedeyan@xxxxxxxxxxxx> wrote:
>> > On July 13, 2009 09:48:54 am Haig Dedeyan wrote:
>> >> On Monday 13 July 2009 14:31:09 tedd wrote:
>> >> > At 3:53 PM -0400 7/12/09, Paul M Foster wrote:
>> >> > >On Sun, Jul 12, 2009 at 09:07:45AM -0400, tedd wrote:
>> >> > >
>> >> > ><snip>
>> >> > >
>> >> > >>  As for prepared statements, I'm no authority on them, but from what
>> >> > >>  I've read they are not going to be something I'll be practicing
>> >> > >>  anytime soon.
>> >> > >
>> >> > >Aside from Stuart's comments about slowness, what else have you read
>> >> > >that makes you discount the use of prepared statements? The PDO class
>> >> > >emphasizes that you're safe from SQL injection exploits, which seems a
>> >> > >big plus.
>> >> > >
>> >> > >Paul
>> >> >
>> >> > Paul:
>> >> >
>> >> > As I said, I'm no authority. However as I have read, prepared
>> >> > statements are for a limited set of instructions in MySQL. They can't
>> >> > be used for everything. Why should I learn one way to do something
>> >> > that isn't universal in the language?
>> >> >
>> >> > Additionally, I think the way I sanitize data is sufficient AND I
>> >> > understand it. *My* learning curve may introduce security problems
>> >> > that I am not willing to risk, at this moment. As I said, I have more
>> >> > than enough on my plate to digest -- including learning non-prepared
>> >> > statements in MySQL.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > tedd
>> >> >
>> >> > --
>> >> > -------
>> >> > http://sperling.com  http://ancientstones.com  http://earthstones.com
>> >>
>> >> Generally speaking, what I have always done to avoid MySQL injection is to
>> >> use mysql_real_escape_string() on all variables I'm chucking into the
>> >> database.
>> >>
>> >> This won't avoid hacks that involve people trying to insert other types of
>> >> code into your content, aka XSS, et al, though. What I do for cases like
>> >> these is try to be as specific as possible when allowing users to enter
>> >> data and try to sanitise it as much as possible.
>> >>
>> >> For example, a name field shouldn't contain anything other than letters, so
>> >> you can write a regex for that. Phone number fields should only contain
>> >> numbers, the odd + sign, and sometimes spaces and brackets if you're users
>> >> are really fastidious with their input.
>> >>
>> >> Sometimes this isn't possible, as in the case of a lot of free-text entry
>> >> boxes, so for those you should try and make some attempt to strip out tags
>> >> or html encode the data prior to displaying it.
>> >>
>> >> Anyway, that's my take on it, and it seems to work for me, but I'm always
>> >> welcome to know of other ways, as I'd prefer being told on the list than
>> >> finding out the hard way! :p
>> >>
>> >> --
>> >> Thanks,
>> >> Ash
>> >> http://www.ashleysheridan.co.uk
>> >
>> > Hi Ashley,
>> >
>> > for the phone #'s, I'm using int as the data type & storing each part of the
>> > phone # in its own cell,
>> >
>> > When it gets displayed, I add a dash in between each part of the phone #'s
>> > (country code-area code-1st set of digits-last set of digits)
>> >
>> > Cheers
>> >
>> > Haig
>> >
>> >
>> >
>> >
>>
>> I too, store them as an int but then create a mask to show then user
>> the correct format based on country
>>
>> --
>>
>> Bastien
>>
>> Cat, the other other white meat
>>
>
> What about other data? Is what I'm doing already sufficient do you
> think?
>
> Thanks
> Ash
> www.ashleysheridan.co.uk
>
>

I think it all comes down to how you view the data and the validation
routines. I keep those separate from the sanitation routines as my
validations need to be more fluid (thinking about dates, life date(
basically the last 100 years) vs event date (not in the past, but
within the next 24 hours (depends on where the client locations are))

>From a sanitation perspective, I don't have any issues with what you
are doing and in many cases I do the same thing. I just have extra
validation other factors of the data.

-- 

Bastien

Cat, the other other white meat

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux