RE: Current Project Design, Comments?

["Brass, Phil (ISS Atlanta)" <PBrass () iss net>]

In addition to SQL injection, it sounds like you need to consider
row-level security.  Imagine you have a form target
view_account.asp?acct_id=10107.  Let's say I'm allowed to view account
10107, but Michael isn't.  If acct_id's are relatively predictable (and
this kind of ID is typically a sequential ID generated by database),
then Michael might request view_account.asp?acct_id=10107.  Or he might
even write a script to request all account IDs and see what he gets.

Also, I note that you made no mention of how you plan on keeping session
state - i.e. when a new request comes in, how do you know if the user
has already logged in or not, who the user is, etc.?  IIS session
object?  A custom session ID?

Phil

> -----Original Message-----
> From: Michael Loll [mailto:mloll () pointetech com] 
> Sent: Friday, February 14, 2003 3: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.