RE: Current Project Design, Comments?

["Tim Aranki" <tim.aranki () dev-quest com>]

Hi Michael,
I would also be careful when storing data in the viewstate.  Not only
does it add to the weight of the page, but I do not believe it is
encrypted.  In fact, I think it is just BASE64 encoded.  So I would not
be storing anything too sensitive there either (unless you are in SSL,
perhaps...).

I would/do only use the viewstate for processing the data in your UI,
but not store any real data there.

-tim

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


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.