method would allow you to more easily create other types of responses
for SQL injection attacks then just throwing an exception. However, you
admit that at present you only want to throw exception. It is a well
known best practice to never add code for possibilities you are not
sure will need to be handled in the future. You are adding complexity
for the hope that you will need it later. If you need it later, just
deal with it then. Second, you are adding overhead to every request as
opposed to just those that are clearly malformed data. Why attempt to
check for SQL injection attacks on every request as opposed to just
checking the ones that throw SQL exceptions? Finally and most
importantly, you gain zero benefit from doing anything other than
throwing an exception. What possible good could it do to return a
specific HTTP error response as opposed to an exception? Does that make
any difference to the attacker? Does it make you any more secure? I
suggest that it only provides a placebo effect for you since you feel
like you are proactive when in actuality you have done anything
additional on the security front.
Matt Liotta
R337 Consulting LLC
http://r337.com
On May 9, 2004, at 6:15 PM, Paul Vernon wrote:
> As I alluded to but probably wasn't too clear on, if I can detect a SQL
> injection rather than just relying on CFQUERYPARAM, I can do
> something a bit
> more pro-active regarding a response.
>
>
> For example, if I leave all of the work to CFQUERYPARAM, all I will
> get is
> an exception on the query which I can catch but, I can't be sure
> exactly why
> the exception occurred, is it a SQL injection, is it just a SQL
> problem, is
> my database alive etc, etc, etc. The catch section would have to have
> several handlers built into it to work effectively.
>
> On the other hand, by explicitly checking for SQL injections prior to
> hitting a CFQUERY, I know in a much more elegant way when I have
> found a SQL
> injection attempt and therefore I can do something more than just
> throw an
> excpetion. In my example, I DID choose to throw an exception but I
> could
> just as easily have returned a http 500 error or a http 403 or just a
> plain
> old 302 to the Disney site or do anything else I see fit to do.
>
>
> I do use CFQUERYPARAM but I was always taught to program defensively
> and a
> mantra that I was given a long time ago was "Exception handlers are
> good...
> but if you can avoid them by coding intelligently, do so." That
> doesn't mean
> don't put exception handlers in your code, and personally, I use them
> liberally. The thing is, all I use them for is handling exceptions,
> not for
> getting out of writing validation routines to check on SQL injections
> etc :)
>
>
> Paul
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
