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

Michael Mabin d3vvnull at gmail.com
Sat Sep 27 20:11:09 CEST 2008


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

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

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

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?

On Sat, Sep 27, 2008 at 9:14 AM, Tino Wildenhain <tino at wildenhain.de> wrote:

> Hi,
>
> Michael Mabin wrote:
>
>> so you wouldn't object then to something like
>>          '.... in (%)' % ','.join([str_edit_for_exploit(x) for x in
>> aList])
>> if str_edit_for_exploit applied security edits?
>>
>
> Whats an security edit btw? If it is something meant to turn possibly
> insecure data into 'secure' then, no I would still object.
> Why? Because its a bad example of "default permit". Its always better
> to have a whitelist - even more so when its so easy to do.
>
> Its just a habit you develope - if you never do it right, how would you
> know when and how to do it right when you need to?
>
> Tino
>



-- 
| _ | * | _ |
| _ | _ | * |
| *  | * | * |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20080927/fea6fc02/attachment.html>


More information about the Python-list mailing list