Front page | perl.dbi.users |
Postings from March 2008
Thanks for the reply (and the DBI, its great). Just one additional question: Can unchecked data somehow harm the database? I guess the definite answer depends on the database server but usually the database should not care about the inserted data (apart from size), right? I know there are alway security risks to consider, I just dont want to overlook something important. I will probably do an unchecked untainting of the bind params and treat the data from the database carefully (with the assistance of TaintOut). Hendrik Am Mo, 3.03.2008, 21:37, schrieb Tim Bunce: > On Mon, Mar 03, 2008 at 03:04:33PM +0100, Hendrik Schumacher wrote: > >> Hi. >> >> >> I use DBI and DBD::mysql (both up-to-date versions from cpan) in a >> mod_perl application. >> >> When constructing the SQL statements I >> 1) untaint the vars used to concat the actual statements >> 2) use (partly tainted) vars in bind_param() and execute(). >> >> >> In the eternal struggle for more security I tried to use Taint => 1 in >> my database connect now. >> >> Unfortunately using tainted vars in bind_param() and execute() results >> in Taint errors. Since I dont want to excessively filter the vars I use >> in my binds, the only solution would be to blindly untaint the bound >> vars. Is there a reason for the taint check of the bound params? > > Yes. > > >> Would there be any >> security risk in doing a $x =~ /^(.*?)$/; $x = $1; for the bound params? >> > > That depends on your application. > > >> If not, why does DBI taint check them? How should I proceed? >> > > SQL Injection attacks are just one kind of security problem. > Tainting prevents unchecked data getting into the database tables, > as well as preventing it 'corrupting' the SQL. > > (Arguably there's little point in taint checking placeholders that are > only used in a where clause, for example, but the DBI has no way of knowing > how placeholders are being used.) > > Tim. > >Thread Previous