RE: Current Project Design, Comments?

[alex () netWindows org]

On Tue, 18 Mar 2003, Vitor Ventura wrote:

> I am currently on a project designing an ASP.NET-based application for a
> client.  I would welcome any comments on my security design so far.

Don't run beta code.

Why .NET? What sold you on it from a security standpoint that was more
compelling than the argument that it's totally new code that is not yet
tested (and hasn't seen the standard Microsoft "third try's a charm"
treatment)? Do the benefits of .NET in your environment outweigh the
risks? (that's something only you and/or your client can answer)
 
> Communication Protection
> ------------------------
> Client Web Browser to Web Server: 128-bit SSL encryption
> Web Server to Database Server: IPSec (via Windows 2000 Server)

The encryption means a lot less than what you do with your keys. Who
signed your keys? Are they actually checked in any meaningful way when
you setup a connection? How do you store them? etc...

As Prof. Spafford once said:

        "Using encryption on the Internet is the equilvant of arranging
        an armored car to deliver credit card information from someone
        living in a cardboard box to someone living on a park bench."
 
it's who/what you've got on the ends of those connections that matters.
Are they Win2K boxen? If so, do you know how to properly secure them? If
not, go back to Square One, do not pass go, do not collect $200.

> Authentication
> --------------
> Client to Web Server: Custom authentication against a username/password
> stored in Oracle DB.  The database actually only stores the username, a hash
> of the password, and a random salt value used in the hashing process.  No
> password is actually stored in the database.

What kind of password strength are you enforcing? What about rotation?
Is password changing allowed? Is it required? Enforced?

> Web Server to Database Server: A single identity is used to talk to the DB
> server from the Web Server.  These credentials are stored on the Web Server
> in encrypted form and are decrypted when needed (and stored in memory). 
>
> The key for decryption is the password of the web account - this is all handles
> via Window's data protection api.

Since the DPAPI relies on the strength of this password for it's saftey,
is this a strong password? Have you run LOpht Crack on the box/account?

How about the ACL's on that users's homedir? (it's where the "Master
Key" for the DPAPI is stored by default).

Is this password rotated? Are password strength requirements enforced in
an ongoing manner?
 
> Authorization
> -------------
> Client to Web Server: Subsystems of the application are protected via custom
> role-based security.  Each user has a "role" and if that page is not
> viewable by that role, they are redirected to a different page.

Is this the same error page as if the resource does not exist at all? If
not, you've got an information disclosure problem.

> Web Server to Database Server: The trusted identity has minimum rights to
> the specified tables and procedures needed to perform its duties.

Have you verified that all triggers for those tables can affect only
those tables? Is that user allowed to load new PL/SQL or Java Stored
Procedures after deployment?
 
> Pretty standard in the web world, correct?

Yep, sounds like you've got a good start on it. Depending on your/your
client's security requirements, a code review (preferably by people that
know what they're doing) could be in order. Also, what you've outlined
says nothing about many of the more critical security and information
design decisions you probably made over the course of the project. Such
as, is critical customer data both readable and writeable by the same
systems? What kind of perimiter defenses do you have in front of those
chewy Windows boxen? Are tasks and privledges broken out correctly? I
could go on for days = )

Without a much fuller description of the goals, requirements, and design
of the system, we can only make vague recommendations that ammount to
band-aids. My advice is to contract with a security person to assess
your risk if it's really a requirement for you.

HTH.