|
|
Posted by The Natural Philosopher on 08/31/07 20:15
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.
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 ;-)).
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
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;
}
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..;-)
}
Navigation:
[Reply to this message]
|