RE: Current Project Design, Comments?

["Scott" <scottcm () usa net>]

An aspect of securing asp.net applications that I haven't seen mentioned is
.NET Framework's CAS.  Dot-Net offers code level security that you can
implement to enhance the security of the system in the event it is
compromised.  There's also the machine.config and web.config files that can
help enforce some basic security.

I'm not sure how your asp.net app is structured, but if the asp.net web
pages (.aspx) are interacting with dot-net assemblies (either as global
assemblies in the GAC - similar to old COM/COM+ components - or as private
assemblies) then you can enhance the security by using CAS.  For those not
familiar, CAS is Code Access Security - a new method of securing a system
and applications offered only with the .NET Framework.

For example, suppose you have a web app made up of web pages to present the
app to a user, private assemblies to handle your specific application
business logic, global assemblies to standardize your data access, and the
data store that contains the information the user wishes to act upon.  Using
CAS you could set it up so that only your global assemblies, compiled with a
certificate, are allowed to access the MS SQL and Oracle database drives
(the dot-net ones).  And only assemblies with a specific hash can are
allowed any access to assemblies with the "xyz" certificate.  If you really
wanted to lock things down you could specify that the global assemblies that
access the database drivers are only allowed to perform certain database
functions.

The end result is that any dot-net assembly (authorized or unauthorized)
that finds its way onto this system is unable to access the dot-net database
drivers unless they have the authorized certificate.  Also, any dot-net
assembly that does not have the correct hash is unable to utilize any
methods provided by your global assemblies.  So even if a site was
compromised, they would be unable to place their own code on the system to
access/compromise your data layer.

All that is well and good except it does nothing to prevent non-dot-net apps
from accessing the non-dot-net database drivers.  Big reason to migrate to
Windows 2003 (assuming it lives up to MS promises).  W2K3 offers Software
Restriction Policies which work on non-dot-net apps.  You could use this to
allow only specific (using hash value, for instance) apps to use the
database drivers.  Although this isn't available now, if you write your
application to support the CAS system you can implement this additional
feature when it's released.

Finally, don't forget about the machine.config and web.config files.  There
are several settings in there that can enhance security on the system for
asp.net apps.  I suggest reviewing the <system.web><webServices> section.
Specifically, consider removing the HttpGet and HttpPost options.  I'd also
recommend using the machineKey setting in the web.config rather than the
machine.config (this attribute is involved with encrypting session state).
I recommend using option to prevent other config file or apps from
overriding these options.  Another section to pay close attention is the
file extension associations - remove any that you don't need.

This post doesn't do CAS and the dot-net config files justice, but I hope it
helps broaden your security considerations.  Check out the dot-net framework
SDK (even though it has several errors) and msdn.

Wow.  After reading through my post I feel like an MS spokesperson. I think
I need a shower.  Seriously though, CAS and SRP are the first security
options offered by MS that I think are exciting improvements.  I sure hope
they are, otherwise I'm wasting a large amount of my time for naught.

Scott

-----Original Message-----
From: Michael Loll [mailto:mloll () pointetech com]
Sent: Friday, February 14, 2003 2:26 PM
To: webappsec () securityfocus com
Subject: Current Project Design, Comments?


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.

Communication Protection
------------------------
Client Web Browser to Web Server: 128-bit SSL encryption
Web Server to Database Server: IPSec (via Windows 2000 Server)

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.

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.

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.

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

Pretty standard in the web world, correct?  I am still trying to figure out
a universal way to handle SQL injections.  I garnered most of this from
Microsoft's whitepaper on secure ASP.NET applications.


--
Michael Loll
Consultant / Pointe Technology Group, Inc.
mloll () pointetech com / www.pointetech.com


* This email is my opinion and not that of my employer.