in reply to Preventing injection attacks

That's just completely useless. I would suggest you use placeholders and/or the $dbh->quote method - or a nice abstraction layer like DBIx::Class - that way you don't have to scan your input for anything.

Attempting to catch malicious input is misguided in most cases. You should either only allow known good - verifiable - input or make sure the content of the input doesn't matter.

update:

I think there is room for a Perl module that can screen against all attacks through stored procedures of any database app.
And the problem with that is that you won't know about all potential attacks. Besides that I suspect the code to detect all known attacks would soon be orders of magnitudes larger than the code it's supposed to protect - with all the potential for bugs in and/or security holes caused by the scanning code.
"What should it profit a man, if he should win a flame war, yet lose his cool?"

Replies are listed 'Best First'.
Re^2: Preventing injection attacks
by Ionitor (Scribe) on Apr 02, 2007 at 14:12 UTC

    Agreed. However, if for some reason your app actually requires the ability to input actual queries (like a SQL tutorial, maybe), you should probably be relying much more on the database's built-in security model. If you give an untrusted user real access to a database that you don't want them altering/destroying, a fragile regex is not going to save you.

    As an aside for similar efforts, no regex of that length should be a one-liner. At the very least, you should be using the /x switch and commenting what you want to do. Even better would be building the regex in several chunks, so that a syntax error might have a prayer of being found.

[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Seekers of Perl Wisdom