I didn't admit that I only want to throw an exception, I said that for the
purposes of the test rig that I *chose* to throw an exception. That is a
BIG difference. The code I posted was just that, a working test that would
illustrate what I was thinking concisely and effectively.
On your second point I think that any overhead incurred by adding code is
one that must be weighed against the possible benefits that the code
introduces.
On your third point, I think that pro-actively catching an attempt and
returning a relevant HTTP error code is far better than just throwing an
exception. When you come to review your server logs from a security
standpoint, what do you look for? Personally, I look for exceptions and for
specific HTTP error codes. Which ones are easier to check out? The HTTP
error codes of course because they are obvious.
Every exception that I have to check out, I have to review to see if it
should be there, if its a bug in the code or if it is an attempted hack of
some kind. Chasing exceptions usually takes up much more time than chasing
down the HTTP error codes and why they are there....
This isn't about being more secure, or even thinking that I'm more secure. I
know that CFQUERYPARAM will stop all known SQL hacks dead. I even stated
that I use it everywhere I can. Therefore this idea cannot be a placebo as I
already know that if CFQUERYPARAM is in place, the DB is secure from SQL
injection attacks. It doesn't make me feel better about life the universe or
anything, what it does do is help me save a hell of a lot of time poring
over reams of server logs looking for security anomolies. Don't you think it
would be nice to have things like access denied showing as a 40x error
instead of a generic exception that could have been caused by a bug in the
code or a plethora of other possibilities?
Paul
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
