Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #11056 > unrolled thread

Sanitising input

Back to article view | Back to comp.lang.php

Contents

  Sanitising input Mad Hatter <colin@class31.co.uk> - 2011-01-30 14:09 +0000
    Re: Sanitising input Jerry Stuckle <jstucklex@attglobal.net> - 2011-01-30 23:12 -0500
      Re: Sanitising input Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2011-01-31 16:01 +1100
        Re: Sanitising input Jerry Stuckle <jstucklex@attglobal.net> - 2011-01-31 00:10 -0500
    Re: Sanitising input Jerry Stuckle <jstucklex@attglobal.net> - 2011-01-30 16:50 -0500
      Re: Sanitising input Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2011-01-31 14:43 +1100
    Re: Sanitising input "P E Schoen" <paul@pstech-inc.com> - 2011-01-30 14:47 -0500
      Re: Sanitising input Felix Saphir <dasr060-usenet@yahoo.de> - 2011-01-30 20:55 +0100
    Re: Sanitising input Sherm Pendley <sherm.pendley@gmail.com> - 2011-01-30 17:18 -0500
      Re: Sanitising input Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2011-01-31 14:52 +1100
    Re: Sanitising input Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2011-01-31 08:39 +1100

#11056 — Sanitising input

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? 

[toc] | [next] | [standalone]

#11075

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#11081

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

[toc] | [prev] | [next] | [standalone]

#11223

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#11113

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#11193

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

[toc] | [prev] | [next] | [standalone]

#11167

"Mad Hatter"  wrote in message 
news:1vh6rvby4n32n$.1rlvhdwm2g874$.dlg@40tude.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 

[toc] | [prev] | [next] | [standalone]

#11205

P E Schoen <paul@pstech-inc.com> wrote:

> "Mad Hatter"  wrote in message
> news:1vh6rvby4n32n$.1rlvhdwm2g874$.dlg@40tude.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

[toc] | [prev] | [next] | [standalone]

#11184

Ross McKay <au.org.zeta.at.rosko@invalid.invalid> writes:

> 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/

LOL! Someone actually made one of my favorite xkcd strips into a site?
I love it! If you're curious:

  <http://xkcd.com/327/>

sherm--

-- 
Sherm Pendley
                                   <http://camelbones.sourceforge.net>
Cocoa Developer

[toc] | [prev] | [next] | [standalone]

#11187

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

[toc] | [prev] | [next] | [standalone]

#11248

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web