RE: Current Project Design, Comments?

[Michael Loll <mloll () pointetech com>]

Session state will be handle by ASP.NET's session model, in-process for
starters.  Later, if they wish to use a web farm, we will change it to use
asp.net's session server option.

When any page loads, it will do at least two things:

1) Check a session variable to see if it exists, if not it will redirect to
the login page.
2) Check a session variable to compare against the role required for page
access, if the role is not present, it will redirect to a different page.

Upon a successful login, two session variables will be create - one to hold
the username, and one to hold the user's role.

-----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