RE: Prevent security bypass

["Adam" <a.bardsley () lancaster ac uk>]

I might be wrong about this but I couldn't find anything on MS' site (who
can?) but I thought the standard NT challenge response was sent unencrypted.
If this has changed I'd love to know because t would sure make my life
easier :)

Adam

-----Original Message-----
From: Chris Travers [mailto:chris () travelamericas com]
Sent: 06 February 2003 07:20
To: Adam
Cc: webappsec () securityfocus com
Subject: Re: Prevent security bypass


Adam wrote:

> It depends how secure you want it as a lot of people have said but I would
> personally go for what you suggested as bar the v.expensive suggestions or
> the ones relying on being on the same NT network you arent going to get
> anything very secure. We have a secuirty script called on each secure page.
> The overhead doesnt seem that bad tbh.
What makes you say that?  If you are on NT, then any insecurities of the
authentication protocol are ALREADY going to affect you.  Applying
diversity in depth might buy you something but only if it is paired with
good NT security practices,  Besides, if your server is not secure, you
are already screwed.

The way I design my web applications which require granularity of
permissions for different users or other advanced security features is
based on the following principles:

1)  Primary Security on Backend-- don't try to do any more enforcement
than you have to on the middleware.  And avoid ANY enforcement of
anything important on the front-end.  Instead, try to do as much
enforcement with the backend components as possible and only suppliment
with the middleware as needed.  The idea here is that you enforce
permissions using the web server, operating system, and/or information
store (such as RDBMS and LDAP) as much as possible because these are the
most robust security-wise, and they can be attacked independently
anyway.  Furthermore these are the only solutions that can globally
protect the information (from inside the web context or outside it).

2)  Supplimental Security in Middleware-- Sometimes, it is necessary to
place information in the information store in an insecure fassion,and
this could be used for DoS attacks.  One example might be a user profile
in an RDBMS system where all users will be able to write to and update
that table.  In this case, enforce additional security on the
middle-ware.  But this security is much more brittle and not as strong,
so it should not be relied upon as much.

3)  Protect content In Transport-- Use SSL to protect the content and
passwords.

Best Wishes,
Chris