RE: Current Project Design, Comments?

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 Received on Fri Feb 14 16:21:44 2003