Re: encoding to prevent sql injection in both perl and php

As you do not know how PHP has escaped or encoded the data, there is unfortunately no easy way to reverse the effects of the sqlite_escape_string function outside of PHP.

However, I really wonder if escaping the data when storing it in the sqlite database is a good thing. Rather than blindly accepting any odd data and relying on the sqlite_escape_string function to store it safely into the database, IMHO one should validate the data before storing it and rejecting data which has unacceptable content. Of course the fact that sqlite can store any type of data in any column whatever its declared data-type (some consider this a bug, other think it is a feature) allows you to be careless in storing data and there is really no need --it seems-- to encode/decode your data.

Of course since MySQL uses static typing for its columns you must take care of what you are storing, unless you always use BLOB-columns.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Comment on Re: encoding to prevent sql injection in both perl and php Select or Download Code

Replies are listed 'Best First'.

Re^2: encoding to prevent sql injection in both perl and php
by herveus (Prior) on Aug 24, 2006 at 23:45 UTC

As I read mandog's description, I see the SQLite data store being used as a simple, asynchronous transfer mechanism for getting user input from the PHP to the Perl. Clearly, the Perl side needs to Do Things To The Data along the lines of untainting it (in effect), as the data in SQLite is unfiltered.

Base 64 encoding should be a portable scheme for encoding in PHP and decoding in Perl for closer examination. Once it is encoded, there will be only printable characters, and none of them will be single-quotes. Thus, running it through sqlite_escape_string will not do anything to the string.

yours,
Michael

[reply]


There's more than one way to do things
	PerlMonks