> user comes
> back and types in kjdfljsldfl they don't get taken to that
> circuit, because
> it's different this time.
This would not be acceptable in many situations, because it prevents bookmarking and renders search engines useless.
> >> 3. The objection to using cfquery is multifaceted. There is
> the
> >> risk of SQL
> >> injection if your not doing the correct validation. If your
> >> errors are not
> >> being handled correctly you can give away table and column
> names
> >> in the
> >> error message.
>
> >So don't you think it's more important to handle errors properly
> than say
> "don't ever use <cfquery>"?
>
> I think that with all the benefits of procedures, if you have them
> available, you're a fool not to use them, and not just because of the
> enhanced security. Obviously proper error handling is important
> AS WELL.
> This is not an either/or argument, rather a complimentary one.
What's wrong with:
<cfquery>
exec my_stored_proc
</cfquery>
?
> >> 2. By using plain text variable names your going to give the
> potential>> intruder a decent insight into your application
> design, and this
> >> will give
> >> them the ability to make educated guesses as to your other
> circuit
> >> names.
>
> >So?
>
> So by understanding the structure of an application, you can then
> begin to
> analyze it's weaknesses. In the environment in which I work we
> want to give
> them as little as possible to go on.
>
> >You've got bigger problems should someone gain access to your
> file system.
>
> Is that so?? I disagree. If someone gains access to my web
> server they
> have nothing. Now my db which is on the other side of a firewall,
> and only
> accepts connections from specific ips, if they got in that it
> could become
> problematic. Why? Because there are no user names or passwords
> stored on
> my web server. There is no way to open a direct connection into
> my db
> without having a user account on the db. Your rights and roles
> are also
> stored in that db, not in the application, and so you would not
> really get
> anything other than images and source code. You don't even get
> the code of
> the procedure calls, and so you are still blind to the schema of
> my db.
If I have complete access to your file system, this means that I can, say, create a file that monitors tcp/ip traffic between your web server and db server and sends the packets over to me where I can then scan for your password. Or I could simply delete everything on the web server.
>
> Kwang, again, this is a layered approach to security. No one
> thing is going
> to protect you from everything. You just continue to lock down
> things in
> order to mitigate risk. You can never be without risk, and anyone who
> thinks they have completely secured their site deserves to be
> attacked.Listen man. You do whatever you feel comfortable doing.
> No more, no less.
> But moving towards my CISSP and GSEC, having been a cyber threat
> analyst for
> the last two years, and soon to be managing a federal CERT, I can
> tell you
> this, there is always going to be some new exploit. It's going to be
> something you didn't think of. But that zero day exploit isn't
> going to be
> the one that does all the crazy damage. It's going to be some known
> vulnerability that you could have prevented from putting your
> system at
> risk. (slammer, blaster etc.) By duplication of your efforts, by
> overlapping your protection you're trying to create a shell around
> yourapplication and it's data.
If what you're building is that important to secure, I recommend that you never ever make it available on the public internet.
Obscurity is just one more tool
> you can use to
> do that.
I used to work with a security/cryptology expert. His #1 rule:
"Never, ever use obfuscation".
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
