Nice writeups.. I'm glad I brought the topic up this morning because a lot
of good avice and insght has been given.
Everyone does it differently and all we can do is improve on what we thought
"secure" was yesterday.
Mike
> >> 1. If your properly encrypting the url your going to
> change your seed
> >> (key) every request. That way it is different every time
>
> >What possible value does this bring?
>
> If my user.login is encrypted one time as kjdfljsldfl and
> the user comes back and types in kjdfljsldfl they don't get
> taken to that circuit, because it's different this time.
>
>
> >> 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.
>
>
> >> 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.
>
>
> 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 your application and
> it's data. Obscurity is just one more tool you can use to do that.
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
