RE: Current Project Design, Comments?

[Michael Loll <mloll () pointetech com>]

I do not use query strings, data is passed between pages via the "code
behind model" or the ViewState mechanism in ASP.NET, or via my custom
session variables.

-----Original Message-----
From: Logan F.D. Greenlee [mailto:lgreenlee () ciretose net] 
Sent: Friday, February 14, 2003 4:30 PM
To: Brass, Phil (ISS Atlanta); Michael Loll; webappsec () securityfocus com
Subject: RE: Current Project Design, Comments?


        In most cases one should not use query strings in ASP.NET. Critical
information such as account ID, or user information should be stored in the
users session. Most frequently this is a user object. The aspx forms are
then responsible for retrieving them from the user's session. By doing this
query string based attacks are mitigated. The "code behind model" helps to
reinforce this model. By using form post back all variables are held in the
form state.

_logan




-----Original Message-----
From: Brass, Phil (ISS Atlanta) [mailto:PBrass () iss net] 
Sent: Friday, February 14, 2003 4:12 PM
To: Michael Loll; webappsec () securityfocus com
Subject: RE: Current Project Design, Comments?

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.