how to replace and string in a "SELECT ... IN ()"

[Tino Wildenhain]

Hi,

Michael Mabin wrote:
> If the inputs are edited prior to the construction of the string and 
> these fields are used for more than one update then it's not an exploit. 
>  It's simply a matter not repeating yourself when coding.

In python we do not fear that.

> In this particular case too, we're talking about a list of integers that 
> gets inserted into a string.  If the list is validated prior to its 

Its a list, if it indeed has integers in it is uncertain. It is so very
easy to check that that it doesnt even make sense to write such lengthy
emails about how bad you want to avoid it. Just do it. And even more so
if you are telling others how to do things make sure they do not so easy
shoot themselfes in their feet.

> insertion into an SQL statement then there is no exploit.  If I write a 
> batch program (not a web program) that retrieves this list of integers 
> from other sources and validates the data prior to using it in an SQL 
> statement, that should be sufficient.  

This might be well true but if you have a look at your original 
contribution you see that all these your asumtions are just not in.

> As far as wrong and right is concerned. I think it's more about doing 
> what is appropriate according to the circumstances.  As a rule you 

If its easy to do, why not just doing it correctly (or robust) in all
circumstances to just avoid overlooking a case?

> should only code what is appropriate for the circumstances.  If it's 
> appropriate to code more simply without introducing unnecessary 
> complexity you should do so.

But you did not tell us about your asumtations about the circumstances.

> I work in the data warehousing ETL world, where we have to perform field 
> edits or transformations to load source data into databases.  If I'm 

Thats wrong. You do not "edit" fields. You have a validating type path 
and _always_ the database is most authoritative about what it accepts.
Any other concept is just wrong and outright dangerous. There are
many examples of how this works out (just check bugtraq)

> already performing edits on these fields and if these fields are going 
> to be used for more updates downstream, it's wasteful to perform them 
> again when I build the SQL insert with the list and execute it. 

I still don't know what you mean by "edit" ;) If you mean filter out
special chars with for example replace("bad stuff","good stuff") check
your idea again, this is not going to work. (google for default permit)

> Finally, whatever happened to the practice of granting appropriate 
> privileges to IDs that perform database operations?  Shouldn't the 
> person acting in the capacity of DBA ensure that the user updating or 
> retrieving data from the database does not have DROP, ALTER, or CREATE 
> privileges on that database? 

This of course is another layer which should be added - but you would
not need to - you edited the fields, right? ;)

Sorry, it was not meant to put you to the wall but you insist so much
on your still dangerous solution while top posting the hell out of
this thread I just could not ignore it ;)

T.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20080927/baf29de7/attachment-0001.bin>