| Sanitising input [message #172084] |
Sun, 30 January 2011 14:09  |
Mad Hatter
Messages: 1
Registered: January 2011
Karma: 0
|
Junior Member |
|
|
Hi all
I'm writing a simple script which will take a users input, save it to a
mysql database and then display it. I'm going to use htmlentities() to
clean things up which I hope will stop basic attacks but how else should I
sanitise my input?
|
|
|
|
| Re: Sanitising input [message #172087 is a reply to message #172084] |
Sun, 30 January 2011 15:00  |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Mad Hatter)
> I'm writing a simple script which will take a users input, save it to a
> mysql database and then display it. I'm going to use htmlentities() to
> clean things up which I hope will stop basic attacks but how else should I
> sanitise my input?
htmlentities() (or better htmlspecialchars()) is used for preparing
_output_ to an HTML page in order to prevent cross-site scripting
attacks. It doesn't sanitise your input that goes into the database!
That's what mysql_real_escape_string() and the like or prepared
statements are for.
Micha
|
|
|
|
| Re: Sanitising input [message #172089 is a reply to message #172084] |
Sun, 30 January 2011 16:35 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 30/01/11 14:09, Mad Hatter wrote:
> I'm writing a simple script which will take a users input, save it to a
> mysql database and then display it. I'm going to use htmlentities() to
> clean things up which I hope will stop basic attacks but how else should I
> sanitise my input?
strings - use mysql_real_escape_string before using the string value as
data in an sql statement, eg:
$the_text = $_POST['text_field'];
$the_text = trim($the_text);
$the_text = str_replace($old,$new,$the_text);
// maybe do some additional stuff to $the_text here
$safe_text = mysql_real_escape_string($the_text);
$qry = "update table set field = '$safe_text' where otherfield = '$keyval'";
mysql_query($qry);
floats and ints, use floatval or intval to read them from the post or
get array:
$the_float = floatval($_POST['number_field']);
$the_int = inttval($_POST['number_field']);
dates & times, if you allow these to be entered as text fields, you
might get meaningful data with parse_date or strtotime, but it might be
better to use numbers and handle them as ints, or select elements.
Note that you can absolutely never assume that the data you receive will
bear any connection with your web page. It is trivial for an attacker to
view your form html, and to generate his own form that calls your form
handler with whatever data he desires to send in every form element.
The fact that your select element for year has values from "2001" to
"2020" doesn't stop an attacker sending:
"';;drop *;;"
or a base 64 encoded image file, or anything else at all, so you need to
write your scripts so that they check everything and only accept data
that they recognise.
Rgds
Denis McMahon
|
|
|
|
| Re: Sanitising input [message #172096 is a reply to message #172084] |
Sun, 30 January 2011 19:47 |
P E Schoen
Messages: 86
Registered: January 2011
Karma: 0
|
Member |
|
|
"Mad Hatter" wrote in message
news:1vh6rvby4n32n$(dot)1rlvhdwm2g874$(dot)dlg(at)40tude(dot)net...
> I'm writing a simple script which will take a users input, save it
> to a mysql database and then display it. I'm going to use
> htmlentities() to clean things up which I hope will stop basic
> attacks but how else should I sanitise my input?
I am using www.HTMLpurifier.org and it works quite well. It allows some HTML
and it actually fixes broken or misplaced tags. Here is how I sanitize my
CGI input:
$in = $_POST ; // Get the CGI input variables
require_once 'C:/xampp/htdocs/library/HTMLPurifier.auto.php';
$config = HTMLPurifier_Config::createDefault();
$config->set('Core.Encoding', 'UTF-8'); // replace with your encoding
$config->set('HTML.Doctype', 'XHTML 1.0 Transitional'); // replace with your
doctype
$purifier = new HTMLPurifier($config);
foreach ($in as $key => $value) {
// Write to Raw.htm
fwrite( $fLog, "Raw: $key -> $value\n");
$pure_html = $purifier->purify($value);
$in[$key] = $pure_html;
fwrite( $fLog, "Pure: $key -> $in[$key]\n");
}
Paul
|
|
|
|
| Re: Sanitising input [message #172099 is a reply to message #172096] |
Sun, 30 January 2011 19:55 |
Felix Saphir
Messages: 8
Registered: December 2010
Karma: 0
|
Junior Member |
|
|
P E Schoen <paul(at)pstech-inc(dot)com> wrote:
> "Mad Hatter" wrote in message
> news:1vh6rvby4n32n$(dot)1rlvhdwm2g874$(dot)dlg(at)40tude(dot)net...
>
>> I'm writing a simple script which will take a users input, save
>> it to a mysql database and then display it. I'm going to use
>> htmlentities() to clean things up which I hope will stop basic
>> attacks but how else should I sanitise my input?
>
> I am using www.HTMLpurifier.org and it works quite well. It
> allows some HTML and it actually fixes broken or misplaced tags.
> Here is how I sanitize my CGI input:
Just to prevent misunderstandings: As Michael and Denis already
wrote, do NOT mistake HTML "cleanup" for sanitising user input.
It might be useful to use strip_tags() to remove unwanted HTML
from input, but that's not the same thing.
Felix
|
|
|
|
| Re: Sanitising input [message #172102 is a reply to message #172084] |
Sun, 30 January 2011 21:39 |
Ross McKay
Messages: 14
Registered: January 2011
Karma: 0
|
Junior Member |
|
|
On Sun, 30 Jan 2011 14:09:11 +0000, Mad Hatter wrote:
> I'm writing a simple script which will take a users input, save it to a
> mysql database and then display it. I'm going to use htmlentities() to
> clean things up which I hope will stop basic attacks but how else should I
> sanitise my input?
For databases, your best bet is the advice on this website:
http://bobby-tables.com/
"There is only one way to avoid Bobby Tables attacks
* Do not create SQL statements that include outside data.
* Use parameterized SQL calls.
That's it. Don't try to escape invalid characters. Don't try to do it
yourself. Learn how to use parameterized statements. Always, every
single time."
See http://bobby-tables.com/php.html for PHP instructions. My preference
is PDO with bindValue(), YYMV.
Also, you may prefer the lighter htmlspecialchars() to htmlentities() if
your output is UTF-8 (which it should be):
http://au2.php.net/manual/en/function.htmlspecialchars.php
--
Ross McKay, Toronto, NSW Australia
"Let the laddie play wi the knife - he'll learn"
- The Wee Book of Calvin
|
|
|
|
| Re: Sanitising input [message #172103 is a reply to message #172102] |
Sun, 30 January 2011 21:50 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/30/2011 4:39 PM, Ross McKay wrote:
> On Sun, 30 Jan 2011 14:09:11 +0000, Mad Hatter wrote:
>
>> I'm writing a simple script which will take a users input, save it to a
>> mysql database and then display it. I'm going to use htmlentities() to
>> clean things up which I hope will stop basic attacks but how else should I
>> sanitise my input?
>
> For databases, your best bet is the advice on this website:
>
> http://bobby-tables.com/
>
> "There is only one way to avoid Bobby Tables attacks
>
> * Do not create SQL statements that include outside data.
> * Use parameterized SQL calls.
>
> That's it. Don't try to escape invalid characters. Don't try to do it
> yourself. Learn how to use parameterized statements. Always, every
> single time."
>
> See http://bobby-tables.com/php.html for PHP instructions. My preference
> is PDO with bindValue(), YYMV.
>
> Also, you may prefer the lighter htmlspecialchars() to htmlentities() if
> your output is UTF-8 (which it should be):
>
> http://au2.php.net/manual/en/function.htmlspecialchars.php
No, that is not the "only way".
First of all, it is necessary to include outside data. How, for
instance, are you going to get the customer's name if you don't allow
outside data?
And properly escaping strings protects against attacks just as well as
using parameterized statements does.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: Sanitising input [message #172112 is a reply to message #172089] |
Mon, 31 January 2011 01:17 |
Norman Peelman
Messages: 126
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Denis McMahon wrote:
> On 30/01/11 14:09, Mad Hatter wrote:
>
>> I'm writing a simple script which will take a users input, save it to a
>> mysql database and then display it. I'm going to use htmlentities() to
>> clean things up which I hope will stop basic attacks but how else should I
>> sanitise my input?
>
> strings - use mysql_real_escape_string before using the string value as
> data in an sql statement, eg:
>
> $the_text = $_POST['text_field'];
> $the_text = trim($the_text);
> $the_text = str_replace($old,$new,$the_text);
> // maybe do some additional stuff to $the_text here
> $safe_text = mysql_real_escape_string($the_text);
> $qry = "update table set field = '$safe_text' where otherfield = '$keyval'";
> mysql_query($qry);
>
> floats and ints, use floatval or intval to read them from the post or
> get array:
>
> $the_float = floatval($_POST['number_field']);
> $the_int = inttval($_POST['number_field']);
>
> dates & times, if you allow these to be entered as text fields, you
> might get meaningful data with parse_date or strtotime, but it might be
> better to use numbers and handle them as ints, or select elements.
>
> Note that you can absolutely never assume that the data you receive will
> bear any connection with your web page. It is trivial for an attacker to
> view your form html, and to generate his own form that calls your form
> handler with whatever data he desires to send in every form element.
>
> The fact that your select element for year has values from "2001" to
> "2020" doesn't stop an attacker sending:
>
> "';;drop *;;"
>
To the best of my knowledge, the PHP/MySQL library doesn't allow more
than one sql statement in the same query.
> or a base 64 encoded image file, or anything else at all, so you need to
> write your scripts so that they check everything and only accept data
> that they recognise.
>
> Rgds
>
> Denis McMahon
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: Sanitising input [message #172115 is a reply to message #172103] |
Mon, 31 January 2011 03:43 |
Ross McKay
Messages: 14
Registered: January 2011
Karma: 0
|
Junior Member |
|
|
On Sun, 30 Jan 2011 16:50:15 -0500, Jerry Stuckle wrote:
> No, that is not the "only way".
Sure, but I reckon it's the OP's best bet (as I stated).
> First of all, it is necessary to include outside data. How, for
> instance, are you going to get the customer's name if you don't allow
> outside data?
There is absolutely no need to include "outside data" in an SQL query.
You can have placeholders in the query and use a prepared statement,
which is what http://bobby-tables.com/ is advocating.
> And properly escaping strings protects against attacks just as well as
> using parameterized statements does.
Absolutely, when done correctly, and never omitted when required, and...
or you can just follow a policy of using prepared statements to present
varying and user-submitted data to the database. I reckon the OP wants
to know how not to shoot him/herself in the foot, and I reckon prepared
statements is the easiest way to prevent that shot.
And when it comes to PHP and its myriad ways to submit queries to the
different databases, I personally prefer to use something like PDO that
presents a largely consistent interface for doing that across the
different databases.
Utilising prepared statements is similar enough across PHP/PDO, ADO,
Java, and .NET that one only needs to understand the basics of using
prepared statements to be capable of writing safe database code on each
of those platforms.
No need to remember that mysql_escape_string() is damaged and that
mysql_real_escape_string() is the safe one, as compared to
mysqli_escape_string() which is safe because it's an alias of
mysqli_real_escape_string(), and that pg_escape_string() is safe and
there isn't a pg_real_escape_string(), and that you might need to use
addslashes() for an ODBC database connection e.g. to Access or MSSQL,
etc.
Albeit if using PDO, you can probably use the quote() function on the
connection for many databases (but not ODBC connections), and not be
concerned about such guff... but even the manual page for that function
advises the use of prepared statements instead:
http://au2.php.net/manual/en/pdo.quote.php
Once the OP becomes expert, they can happily seek out the use-case
appropriate escaping mechanism if they want. But the simple answer to
the OP is for databases, just use prepared statements and you won't come
unstuck.
--
Ross McKay, Toronto, NSW Australia
"The chief cause of problems is solutions" -Eric Sevareid
|
|
|
|
| Re: Sanitising input [message #172116 is a reply to message #172106] |
Mon, 31 January 2011 03:52 |
Ross McKay
Messages: 14
Registered: January 2011
Karma: 0
|
Junior Member |
|
|
On Sun, 30 Jan 2011 17:18:30 -0500, Sherm Pendley wrote:
> LOL! Someone actually made one of my favorite xkcd strips into a site?
> I love it! If you're curious:
>
> <http://xkcd.com/327/>
Yeah, I'm torn between that one and these:
http://xkcd.com/149/
http://xkcd.com/292/
http://xkcd.com/303/
http://xkcd.com/627/
:)
(yes, I'm slacking off, it's too bloody hot to work)
--
Ross McKay, Toronto, NSW Australia
"Some people, when confronted with a problem, think "I know,
I'll use regular expressions." Now they have two problems.
- Jamie Zawinski
|
|
|
|
| Re: Sanitising input [message #172117 is a reply to message #172115] |
Mon, 31 January 2011 04:12 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/30/2011 10:43 PM, Ross McKay wrote:
> On Sun, 30 Jan 2011 16:50:15 -0500, Jerry Stuckle wrote:
>
>> No, that is not the "only way".
>
> Sure, but I reckon it's the OP's best bet (as I stated).
>
>> First of all, it is necessary to include outside data. How, for
>> instance, are you going to get the customer's name if you don't allow
>> outside data?
>
> There is absolutely no need to include "outside data" in an SQL query.
> You can have placeholders in the query and use a prepared statement,
> which is what http://bobby-tables.com/ is advocating.
>
>> And properly escaping strings protects against attacks just as well as
>> using parameterized statements does.
>
> Absolutely, when done correctly, and never omitted when required, and...
> or you can just follow a policy of using prepared statements to present
> varying and user-submitted data to the database. I reckon the OP wants
> to know how not to shoot him/herself in the foot, and I reckon prepared
> statements is the easiest way to prevent that shot.
>
> And when it comes to PHP and its myriad ways to submit queries to the
> different databases, I personally prefer to use something like PDO that
> presents a largely consistent interface for doing that across the
> different databases.
>
> Utilising prepared statements is similar enough across PHP/PDO, ADO,
> Java, and .NET that one only needs to understand the basics of using
> prepared statements to be capable of writing safe database code on each
> of those platforms.
>
> No need to remember that mysql_escape_string() is damaged and that
> mysql_real_escape_string() is the safe one, as compared to
> mysqli_escape_string() which is safe because it's an alias of
> mysqli_real_escape_string(), and that pg_escape_string() is safe and
> there isn't a pg_real_escape_string(), and that you might need to use
> addslashes() for an ODBC database connection e.g. to Access or MSSQL,
> etc.
>
> Albeit if using PDO, you can probably use the quote() function on the
> connection for many databases (but not ODBC connections), and not be
> concerned about such guff... but even the manual page for that function
> advises the use of prepared statements instead:
>
> http://au2.php.net/manual/en/pdo.quote.php
>
> Once the OP becomes expert, they can happily seek out the use-case
> appropriate escaping mechanism if they want. But the simple answer to
> the OP is for databases, just use prepared statements and you won't come
> unstuck.
Except there is a tremendous amount of overhead in PDO - I've had two
sites I have had to rewrite without it to get respectable performance.
And bound parameters are not without their own overhead, either.
Not to say you shouldn't use PDO or bound parameters - they have their
uses. But a good programmer understands the different ways of doing
things and the advantages and disadvantages of each, instead of just
saying "this is the best way for you". It may or may not be the "best
way".
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sanitising input [message #172119 is a reply to message #172117] |
Mon, 31 January 2011 05:01 |
Ross McKay
Messages: 14
Registered: January 2011
Karma: 0
|
Junior Member |
|
|
On Sun, 30 Jan 2011 23:12:09 -0500, Jerry Stuckle wrote:
> Except there is a tremendous amount of overhead in PDO - I've had two
> sites I have had to rewrite without it to get respectable performance.
When was that, 2006? I understand it was the case once that PDO was much
slower than using the mysql_* or mysqli_* functions, but I've yet to run
into a performance problem that wasn't my own stupid fault.
> And bound parameters are not without their own overhead, either.
But minimal overhead, compared with the actual database statement
execution.
> Not to say you shouldn't use PDO or bound parameters - they have their
> uses. But a good programmer understands the different ways of doing
> things and the advantages and disadvantages of each, instead of just
> saying "this is the best way for you". It may or may not be the "best
> way".
First crawl, then walk, then run. I'd rather the OP got to running with
two intact feet. Then they can determine the best way. ITMT, their
question has been well answered by several posters now, and they get to
pick their path.
Optimise last!
--
Ross McKay, Toronto, NSW Australia
"The documentation and sample application having failed me,
I resort to thinking. This desperate tactic works, and I
resolve that problem and go on to the next"
- Michael Swaine, "Programming Paradigms", Dr Dobb's Journal
|
|
|
|
| Re: Sanitising input [message #172120 is a reply to message #172119] |
Mon, 31 January 2011 05:10 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/31/2011 12:01 AM, Ross McKay wrote:
> On Sun, 30 Jan 2011 23:12:09 -0500, Jerry Stuckle wrote:
>
>> Except there is a tremendous amount of overhead in PDO - I've had two
>> sites I have had to rewrite without it to get respectable performance.
>
> When was that, 2006? I understand it was the case once that PDO was much
> slower than using the mysql_* or mysqli_* functions, but I've yet to run
> into a performance problem that wasn't my own stupid fault.
>
About 4 months ago. PDO is still slower. It has to use the same mysql_
functions that PHP uses - it just adds an additional layer before
calling them. I got a significant performance increase simply by
dropping PDO in favor of native calls.
>> And bound parameters are not without their own overhead, either.
>
> But minimal overhead, compared with the actual database statement
> execution.
>
An overly broad statement which is not at all absolutely true. The
overhead of the bound parameters may easily exceed that of an efficient
statement execution. And whether the overhead is minimal or not - it is
still added overhead.
>> Not to say you shouldn't use PDO or bound parameters - they have their
>> uses. But a good programmer understands the different ways of doing
>> things and the advantages and disadvantages of each, instead of just
>> saying "this is the best way for you". It may or may not be the "best
>> way".
>
> First crawl, then walk, then run. I'd rather the OP got to running with
> two intact feet. Then they can determine the best way. ITMT, their
> question has been well answered by several posters now, and they get to
> pick their path.
>
Yes, and I've found in over 20 years of corporate programmer training
that it's best to teach the lower level stuff first, along with the
gotchas and restrictions. That way the programmer better *understands*
the process - and can make more informed decisions.
I've seen people who always try to take the quick and easy way out. It
works for a while - but eventually it comes back to bit them every time.
That's why I was able to make several thousand dollars converting the
site from PDO to native calls - the guy who first wrote it thought PDO
was the slickest thing since snot on a doorknob and couldn't be beat.
Well, he was wrong, and unfortunately it cost the customer.
> Optimise last!
UNDERSTAND FIRST!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: Sanitising input [message #172122 is a reply to message #172120] |
Mon, 31 January 2011 05:38 |
Ross McKay
Messages: 14
Registered: January 2011
Karma: 0
|
Junior Member |
|
|
On Mon, 31 Jan 2011 00:10:00 -0500, Jerry Stuckle wrote:
> About 4 months ago. PDO is still slower. It has to use the same mysql_
> functions that PHP uses - it just adds an additional layer before
> calling them. I got a significant performance increase simply by
> dropping PDO in favor of native calls.
Sounds like you must have had poor PDO code, and rather than fix it, you
replaced it with good mysql_* code. Others do not find significant
performance increases. But go ahead, blame PDO instead of your ability
to use PDO correctly :)
>> But minimal overhead, compared with the actual database statement
>> execution.
>
> An overly broad statement which is not at all absolutely true. The
> overhead of the bound parameters may easily exceed that of an efficient
> statement execution. And whether the overhead is minimal or not - it is
> still added overhead.
Sure, broad... but typical. There are always cases where optimisation
finds a better way. I have yet to be seriously hamstrung by using PDO
over mysql_* or pg_*.
>> First crawl, then walk, then run. I'd rather the OP got to running with
>> two intact feet. Then they can determine the best way. ITMT, their
>> question has been well answered by several posters now, and they get to
>> pick their path.
>
> Yes, and I've found in over 20 years of corporate programmer training
Appeal to accomplishment -- noted. Shall we measure, or will you accept
that I have one too?
> that it's best to teach the lower level stuff first, along with the
> gotchas and restrictions. That way the programmer better *understands*
> the process - and can make more informed decisions.
>
> I've seen people who always try to take the quick and easy way out. It
> works for a while - but eventually it comes back to bit them every time.
> That's why I was able to make several thousand dollars converting the
> site from PDO to native calls - the guy who first wrote it thought PDO
> was the slickest thing since snot on a doorknob and couldn't be beat.
> Well, he was wrong, and unfortunately it cost the customer.
Again, sounds like some bad PDO code that could have been written better
but you (over?) charged the customer to convert vast tracts of it from
PDO to mysql_* because... you don't know enough about PDO?
As for snot on door knobs, I've yet to find a database interface that
I'm entirely satisfied with, and PDO leaves a lot to be desired (e.g.
only has parameter bindings for string, int, boolean, null and blob).
But I certainly wouldn't teach a new hire to use different and sometimes
conflicting interfaces for different databases when there is a somewhat
unified one at hand, especially when its performance is near native.
>> Optimise last!
>
> UNDERSTAND FIRST!
Perhaps you should try that one too :)
--
Ross McKay, Toronto, NSW Australia
"If ye cannae see the bottom, dinnae complain if ye droon"
- The Wee Book of Calvin
|
|
|
|
|
|
| Re: Sanitising input [message #172127 is a reply to message #172112] |
Mon, 31 January 2011 12:05 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 31/01/11 01:17, Norman Peelman wrote:
> Denis McMahon wrote:
>> On 30/01/11 14:09, Mad Hatter wrote:
>>> I'm writing a simple script which will take a users input, save it to a
>>> mysql database and then display it. I'm going to use htmlentities() to
>>> clean things up which I hope will stop basic attacks but how else
>>> should I
>>> sanitise my input?
>> Note that you can absolutely never assume that the data you receive will
>> bear any connection with your web page. It is trivial for an attacker to
>> view your form html, and to generate his own form that calls your form
>> handler with whatever data he desires to send in every form element.
>>
>> The fact that your select element for year has values from "2001" to
>> "2020" doesn't stop an attacker sending:
>>
>> "';;drop *;;"
> To the best of my knowledge, the PHP/MySQL library doesn't allow more
> than one sql statement in the same query.
Regardless of what eventually gets passed to the database, my points
here are that (a) you can not rely on anything to control the format of
data that your form handler receives; and (b) people will send malicious
data to try and break your website.
Rgds
Denis McMahon
|
|
|
|
| Re: Sanitising input [message #172131 is a reply to message #172122] |
Mon, 31 January 2011 12:51 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/31/2011 12:38 AM, Ross McKay wrote:
> On Mon, 31 Jan 2011 00:10:00 -0500, Jerry Stuckle wrote:
>
>> About 4 months ago. PDO is still slower. It has to use the same mysql_
>> functions that PHP uses - it just adds an additional layer before
>> calling them. I got a significant performance increase simply by
>> dropping PDO in favor of native calls.
>
> Sounds like you must have had poor PDO code, and rather than fix it, you
> replaced it with good mysql_* code. Others do not find significant
> performance increases. But go ahead, blame PDO instead of your ability
> to use PDO correctly :)
>
No, the PDO code was good. And it was not my code. But you obviously
have not had to deal with high traffic sites and/or do not know how to
properly design/optimize a database.
>>> But minimal overhead, compared with the actual database statement
>>> execution.
>>
>> An overly broad statement which is not at all absolutely true. The
>> overhead of the bound parameters may easily exceed that of an efficient
>> statement execution. And whether the overhead is minimal or not - it is
>> still added overhead.
>
> Sure, broad... but typical. There are always cases where optimisation
> finds a better way. I have yet to be seriously hamstrung by using PDO
> over mysql_* or pg_*.
>
See above.
>>> First crawl, then walk, then run. I'd rather the OP got to running with
>>> two intact feet. Then they can determine the best way. ITMT, their
>>> question has been well answered by several posters now, and they get to
>>> pick their path.
>>
>> Yes, and I've found in over 20 years of corporate programmer training
>
> Appeal to accomplishment -- noted. Shall we measure, or will you accept
> that I have one too?
>
Your overly broad statements show otherwise.
>> that it's best to teach the lower level stuff first, along with the
>> gotchas and restrictions. That way the programmer better *understands*
>> the process - and can make more informed decisions.
>>
>> I've seen people who always try to take the quick and easy way out. It
>> works for a while - but eventually it comes back to bit them every time.
>> That's why I was able to make several thousand dollars converting the
>> site from PDO to native calls - the guy who first wrote it thought PDO
>> was the slickest thing since snot on a doorknob and couldn't be beat.
>> Well, he was wrong, and unfortunately it cost the customer.
>
> Again, sounds like some bad PDO code that could have been written better
> but you (over?) charged the customer to convert vast tracts of it from
> PDO to mysql_* because... you don't know enough about PDO?
>
People pay my rate because they know I produce - as in this case. The
original programmer did an OK job with the code, but performance fell
when traffic grew.
And yes, I know a lot about PDO - I've used it on many projects over the
years. But I also know where it fails - and performance is not its
strong point.
After all - PDO eventually has to call the mysql_xxx functions.
However, there is the additional layer in PDO which takes processing
time on a busy system.
> As for snot on door knobs, I've yet to find a database interface that
> I'm entirely satisfied with, and PDO leaves a lot to be desired (e.g.
> only has parameter bindings for string, int, boolean, null and blob).
> But I certainly wouldn't teach a new hire to use different and sometimes
> conflicting interfaces for different databases when there is a somewhat
> unified one at hand, especially when its performance is near native.
>
Every database has its own extensions. I don't try to teach a
programmer 10 different databases at once. Find the database they're
going to be using. Teach ANSI standard SQL plus the interface and
extensions (and, in MySQL's case, restrictions) for the database they
will be using.
>>> Optimise last!
>>
>> UNDERSTAND FIRST!
>
> Perhaps you should try that one too :)
I do. And that includes both the advantages AND DISADVANTAGES of using
something.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Sanitising input [message #172143 is a reply to message #172126] |
Mon, 31 January 2011 23:39 |
Norman Peelman
Messages: 126
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Captain Paralytic wrote:
> On Jan 31, 1:17 am, Norman Peelman <npeel...@cfl.rr.com> wrote:
>> To the best of my knowledge, the PHP/MySQL library doesn't allow more
>> than one sql statement in the same query.
>
> Luckily enough, php is better than your best (as a Google search for
> "php multiple queries mysql" would have shown you):
> http://php.net/manual/en/mysqli.multi-query.php
>
Well then, that seems like an invitation for injection. The standard
mysql extension does not.
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
| Re: Sanitising input [message #172145 is a reply to message #172143] |
Tue, 01 February 2011 00:53 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 31/01/11 23:39, Norman Peelman wrote:
> Captain Paralytic wrote:
>> On Jan 31, 1:17 am, Norman Peelman <npeel...@cfl.rr.com> wrote:
>>> To the best of my knowledge, the PHP/MySQL library doesn't allow more
>>> than one sql statement in the same query.
>>
>> Luckily enough, php is better than your best (as a Google search for
>> "php multiple queries mysql" would have shown you):
>> http://php.net/manual/en/mysqli.multi-query.php
> Well then, that seems like an invitation for injection. The standard
> mysql extension does not.
I'm glad you feel that it is safe to assume that you never need to worry
about sql injection if coding php / mysql_* functions. You are obviously
supremely confident that mysql_query() will never be changed to support
multiple sql statements. I mean, it's obvious that this could never
happen, right? It's an impossibility. No-one would ever code it as an
enhancement to to the mysql_* functions, so you don't need to worry that
some day in the future, when a hosting company updates a server,
suddenly your websites might become vulnerable because you assumed that
a function would never change in a backward compatible manner that might
suddenly expose a vulnerability that everyone (well, you, anyway)
assumed they were safe from.
You carry on thinking that. Personally I think it would be negligent to
assume that there will never be a future change to or a bug in the
mysql_query interface that might allow such an attack to succeed and
that my code will always be protected against sql injection by this
feature of the implementation.
So yeah, I always assume that sql injection is something that needs to
be considered as an attack vector even if the environment that I'm
currently coding for claims, in its current incarnation, to be
inherently hardened against that attack vector.
Rgds
Denis McMahon
|
|
|
|
| Re: Sanitising input [message #172147 is a reply to message #172145] |
Tue, 01 February 2011 11:26 |
Norman Peelman
Messages: 126
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Denis McMahon wrote:
> On 31/01/11 23:39, Norman Peelman wrote:
>> Captain Paralytic wrote:
>>> On Jan 31, 1:17 am, Norman Peelman <npeel...@cfl.rr.com> wrote:
>>>> To the best of my knowledge, the PHP/MySQL library doesn't allow more
>>>> than one sql statement in the same query.
>>> Luckily enough, php is better than your best (as a Google search for
>>> "php multiple queries mysql" would have shown you):
>>> http://php.net/manual/en/mysqli.multi-query.php
>
>> Well then, that seems like an invitation for injection. The standard
>> mysql extension does not.
>
> I'm glad you feel that it is safe to assume that you never need to worry
> about sql injection if coding php / mysql_* functions. You are obviously
> supremely confident that mysql_query() will never be changed to support
> multiple sql statements. I mean, it's obvious that this could never
> happen, right? It's an impossibility. No-one would ever code it as an
> enhancement to to the mysql_* functions, so you don't need to worry that
> some day in the future, when a hosting company updates a server,
> suddenly your websites might become vulnerable because you assumed that
> a function would never change in a backward compatible manner that might
> suddenly expose a vulnerability that everyone (well, you, anyway)
> assumed they were safe from.
>
I never said any such thing - sanitizing input is always important.
As for mysqli allowing it, why open a security hole?
> You carry on thinking that. Personally I think it would be negligent to
> assume that there will never be a future change to or a bug in the
> mysql_query interface that might allow such an attack to succeed and
> that my code will always be protected against sql injection by this
> feature of the implementation.
>
Again, I never said that feature is the (or my) sole protection
against injection.
> So yeah, I always assume that sql injection is something that needs to
> be considered as an attack vector even if the environment that I'm
> currently coding for claims, in its current incarnation, to be
> inherently hardened against that attack vector.
>
> Rgds
>
> Denis McMahon
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]