|
|
Posted by Jerry Stuckle on 08/31/07 22:04
The Natural Philosopher wrote:
> ELINTPimp wrote:
>> On Aug 31, 2:18 pm, giloosh <giloos...@gmail.com> wrote:
>>> On Aug 30, 9:11 am, Jan Thomä <k...@insomnia-hq.de> wrote:
>>>
>>>
>>>
>>>> Jerry Stuckle wrote:
>>>>> Jan Thomä wrote:
>>>>>> I always use the placeholder notation for doing SQL. Concatening SQL
>>>>>> strings from input values is almost certainly a safe path to SQL
>>>>>> injection.
>>>>> Not if you properly cleanse your input. Ensure numeric values are
>>>>> really numeric, and string values are processed through
>>>>> mysql_real_escape_string(), for instance.
>>>> Thanks for the input, and yes I agree, you should definitely cleanse
>>>> your
>>>> input before feeding it to the database. My point was simply, that
>>>> when you
>>>> give this kind of work to a framework and always use the ?
>>>> notation, you
>>>> are safe from injection, even if you forget to check a single input
>>>> variable (which surely happens from time to time). Also you don't
>>>> have to
>>>> do the conversions to different formats manually, so you save a bit
>>>> of time
>>>> and effort.
>>>> Best regards,
>>>> Jan
>>>> --
>>>> _________________________________________________________________________
>>>>
>>>> insOMnia - We never sleep...http://www.insOMnia-hq.de
>>> thanks for the feedback...
>>> isn't is safe to just put quotes around the variable
>>> $id = $_POST['id']
>>>
>>> $q = "select * from table1 where id = '$id'";
>>>
>>> even if id holds none numeric characters, it's still safe... no?
>>
>> No. That introduces sql injection and cross site scripting
>> vulnerabilities. mysql_real_escape_strings, as previously suggested,
>> will help prevent against this.
>>
>
> Dunno what that means, but since Ive been working all day on this sort
> of stuff..
>
> 1/. $q = "select * from table1 where id = '".$id."'";
>
> is what you want. Note the order of quotes and dots.
>
> 2/. On my server - virgin php5 apache2 setup, all POST data gets escaped
> with backslashes into a format that is completely digestible by MySql.
> So no special processing is needed before inserting or updating data
> from $_POST[] derived variables.
>
mysql_real_escape_string is much safer - it takes into consideration the
charset currently in use, for one thing. Also, being a MySQL function,
it knows what MySQL needs or uses.
> 3/. One coding bug showed up interestingly when I had done
>
> $new_id=mysql_insert_id;
>
> instead of
>
> $new_id=mysql_insert_id();
>
> The insert of what surprisinlgly was NOT a syntax error, but a string
> called "mysql_insert_id" into an integer field resulted in the value
> zero being put in. (Javascript gives you a NaN response when you try and
> do maths on a string like (1,000 * 1,000) = Not a Number ;-)).
>
You would have gotten an E_NOTICE if you had them turned on (which you
should have in development).
> 4/. I did have an issue with redisplaying data that had come from a POST
> derived form..now normally I update the database, then read the data
> from the database back into the form: In this case I was testing 'failed
> to update, re-enter some data' and the backslashed stuff gave me issues
> with quotes and backslashes.
>
> Basically a variable that might be "Fred Bloggs" became \"Fred Bloggs\"
> after being POSTED. This went into mysql fine using the sort of query I
> outlined above. And checking using direct database access showed the
> data in *there* was in fact "Fred Bloggs"
>
> However if I wanted to reinsert that into e.g. text box as i.e.
> value="\"Fred Bloggs\"" it didn't work too well at all. Repeated updates
> left me with truncated data and/or multiple backlashes
>
mysql_real_escape_string() solves that problem, also.
> The key is as follows - in my particular apache php configs anyway - to
> do the following.
>
> Any POST data that needs to be inserted into input fields and the like -
> goes through this:-
>
> function sanitise($string)
> {
> $string=stripslashes($string); // remove any backslashes
> $string=htmlspecialchars($string); // turn oddities that HTML barfs
> // on into ampersand stuff
> return $string;
> }
You shouldn't be doing this on data going into the database.
htmlspecialchars() is a display function. Use it after reading out of
the database.
What happens, if for instance, you want to create a report to be
printed, say using PHP's CLI? Or even MySQL's CLI.
> If it's data derived from MySQL it comes out 'as written' with
> everything correct BUT that can confuse the browser..broswers don't like
> <> chars or '", but just running it through htmlspecialchars() is enough
> to sort THAT all out. Inverted commas and single quotes get the &blah;
> type treatment, and they display fine, and gets the correct stuff into
> the POST data when submitting the form - I know cos I sent three hours
> testing it.
>
> i.e. when I did a view source my input text box had
>
> value="&wahtever;Fred Bloggs&whatever;"
>
> inside it, but that showed up as "Fred Bloggs" IN the box, and POSTed up
> correctly as \"Fred Bloggs\" and went into SQL as "Fred Bloggs"
>
> So the correct php to generate THAT fragment would be
>
> echo ("value=\"".htmlspecialcars($my_value)."\"");
>
> And bugger., Ive just noted that the hardlinked copies of my library -
> one and the same file - have been busted into two different ones by my
> editor. It must be one of those that does a 'create tmp file, write it,
> unlink original, rename temp to original' that I so much hate... The
> quickest way to break SUNOS4 linked config files was to use EMACS to
> edit them..
>
> man diff..;-)
>
>
>
>
> }
>
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|