php-general Digest 9 Jun 2012 17:48:58 -0000 Issue 7847
Topics (messages 318201 through 318205):
Re: SQL Injection
318201 by: Lester Caine
318202 by: Govinda
318203 by: Ashley Sheridan
318204 by: Govinda
Re: Your Amazon.com order confirmation.
318205 by: tamouse mailing lists
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Jim Lucas wrote:
Not to refute the above advice one bit (not to mention oppose the arguments
against escaping in general) ... but just curious - can anyone demo a hack
that effectively injects past mysqli_real_escape_string(), while using utf-8
? It may just be a matter of time (or already?) before
mysqli_real_escape_string is *proven* ineffective (w/utf-8) ... but here I am
just attempting to gather facts.
Ah, but what if I use sqlite or postgres?
Or Firebird ;)
IMHO, the discussion needs to be a the best way to prevent SQL injection across
all possible DB types. Not just mysql.
The main thing to avoid is building queries from elements that are directly
loaded from the form inputs. While it is difficult to build sort elements for
queries that use parameters, having a mechanism like ADOdb's datadict where one
can filter SQL based on the identified field names does make life easier.
While the problems of dealing with student names such as 'Delete from student'
are easily solved by only using them in parameter arrays.
A few simple basics cover the vast majority of traditional SQL injection
problems?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--- End Message ---
--- Begin Message ---
>> Ah, but what if I use sqlite or postgres?
>
> Or Firebird ;)
good point.
>> IMHO, the discussion needs to be a the best way to prevent SQL injection
>> across
>> all possible DB types. Not just mysql.
>
> The main thing to avoid is building queries from elements that are directly
> loaded from the form inputs. While it is difficult to build sort elements for
> queries that use parameters, having a mechanism like ADOdb's datadict where
> one can filter SQL based on the identified field names does make life easier.
>
> While the problems of dealing with student names such as 'Delete from
> student' are easily solved by only using them in parameter arrays.
>
> A few simple basics cover the vast majority of traditional SQL injection
> problems?
Yes, apparently.
Part of why I even asked is to get a sense of the shelf life on legacy code
(that relies on escaping) which I am not keen to have to re-write, for free,
until I really must.
-Govinda
--- End Message ---
--- Begin Message ---
Govinda <govinda.webdnat...@gmail.com> wrote:
>>> Ah, but what if I use sqlite or postgres?
>>
>> Or Firebird ;)
>
>good point.
>
>
>>> IMHO, the discussion needs to be a the best way to prevent SQL
>injection across
>>> all possible DB types. Not just mysql.
>>
>> The main thing to avoid is building queries from elements that are
>directly loaded from the form inputs. While it is difficult to build
>sort elements for queries that use parameters, having a mechanism like
>ADOdb's datadict where one can filter SQL based on the identified field
>names does make life easier.
>>
>> While the problems of dealing with student names such as 'Delete from
>student' are easily solved by only using them in parameter arrays.
>>
>> A few simple basics cover the vast majority of traditional SQL
>injection problems?
>
>Yes, apparently.
>
>Part of why I even asked is to get a sense of the shelf life on legacy
>code (that relies on escaping) which I am not keen to have to re-write,
>for free, until I really must.
>
>
>-Govinda
>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
I think you can happily sanitise data where it makes sense, and use bound
parameters elsewise. So when you expect a number, its easy to check for and
force a sensible default. Likewise for things like dates, or names of articles
(probably a popular need with a CMS) you can check and enforce particular
characters.
Outside of that, without bound params you run a potential risk (even if only
slight). You can do stuff like base64 encode values, but then you lose a lot of
the ability to search through your DB after.
Thanks,
Ash
http://ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
> I think you can happily sanitise data where it makes sense, and use bound
> parameters elsewise. So when you expect a number, its easy to check for and
> force a sensible default. Likewise for things like dates, or names of
> articles (probably a popular need with a CMS) you can check and enforce
> particular characters.
>
> Outside of that, without bound params you run a potential risk (even if only
> slight). You can do stuff like base64 encode values, but then you lose a lot
> of the ability to search through your DB after.
What would you say in the case of having used CodeIgniter (w/it's modified
'Active Record Class', before PDO was an (easy/built-in) option in CodeIgniter)
to develop an app that serves content in dozen(s) of languages through a custom
international CMS... and now they want "a search box" so end users can search
all the pages (db data) of the "site" for that country (in that country's main
language)? IOW form input that I cannot just force/sanitize to e.g. (english)
alphanumeric (+ spaces), and I cannot just switch to using PDO without
rewriting all the code in all the model files.
Thanks
-Govinda
--- End Message ---
--- Begin Message ---
On Fri, Jun 8, 2012 at 9:23 AM, Dan McCullough <dan.mccullo...@gmail.com> wrote:
> I was hoping for a TV
I'm still waiting on my delivery of a case of tuscan whole milk....
--- End Message ---
