Membership - Database Security

[rbfigueira]

Hi friends,

In our institution we want to install the Membership Database (tables,
stored procedures, views, etc) in one separated database for share of all web
application (avoid installing in each new asp.net application database all
the tables, stored procedures, views, etc for support the Membership). The
problem is if some web application (developer) put the same applicationName
in the web.config file and destroyed or changes the data from other web
application.

I think you are the two guys that can answer to this Security Problem -
Membership.

Normally, an instance of SqlMembershipProvider knows which application name
to use by looking at the value of the applicationName configuration
attribute. The default configuration in machine.config sets applicationName
to /, so most developers will probably want to explicitly redefine membership
providers in their applications to use a more suitable name.

The one constraint on the applicationName attribute though is that it is
statically defined. After you set the value in configuration, the provider
remembers that value for the rest of its lifetime.

Suppose this approach:
In one server you have 3 Databases.

1- Membership Database (tables, stored procedures, views, etc) for
supporting the membership providers. The idea here is to share the same
structure (database) and avoid installing in each new asp.net application
database all the tables, stored procedures, views, etc for support the
Membership.

2- Database "site1" that support one application asp.net 2.0 -
applicationName ="site1"

3- Database "site2" that support one application asp.net 2.0 -
applicationName ="site2"

We have 2 distinct asp.net 2.0 applications. One has in the web.config the
applicationName ="site1" (refers to the Database (2) "site1" and use the
Membership Database (1)) and the other has the applicationName ="site2"
(refers to the Database (3) "site2" and use the Membership Database (1)). In
both applications we can create the users and assign different permissions.

Security Problem:
In the Membership Database (1) we have different roles, profiles, etc for
each different web application. If someone/programmer install other different
asp.net application in the same server (example: "site3") and use the same
Membership ConnectionString and give, for mistake, the same applicationName
(ex: applicationName ="site2") of other asp.net web application that allready
exist, this "new" application will override or can change the Membership data
(roles and users profiles) of the "site2" ?

Note that the Membership Database will be the same to all asp.net web
applications and we will give to the programmer the same Membership
ConnectionString (credentials).

This problem is real ? If yes, what we can do to avoid that problem?

Best regards

 

[Steven Cheng[MSFT]]

Hello Rbfigueira,

From your description, you have multiple ASP.NET 2.0 Web appliations that
will use membership/role services to secure themselves. However, you're
wondering whether it is proper to store these applications's
membership/role data in a shared database or separately, correct?

I think your analysis about the shared database condition is reasonable.
Yes, if we configure multiple ASP.NET 2.0 application's membership provider
to use the same shared database, each SqlMembershipProvider should use a
different "ApplicationName" so that their data can be identified correctly.
Also, your worry is correct that if another new application join and also
use the same membership database and incorrectly configure with an
"ApplicationName" duplicated to another existing application, it will use
the existing membership data of that application incorrectly.

For such scenario, I think you can consider the following solution:

1. Still configure multiple ASP.NET applications to use the shared
membership database, however, you make the user/roles management (insert,
update...) in a separate admin application so that the membership data can
only be modified through that admin web application(connect to sql through
a particular login with powerful permission). And for normal web
application, the windows security identity or sql login(if you use sql
connection in connectionstring) only has read-only permission( this is
necessary for application's membership/role validation and querying ...).

2. Use separate database for each web application, this will completely
prevent application's data being corrupted though it may add data storage
overhead.

How do you think? Please feel free to let me know if you have any other
questions or ideas on this.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[rbfigueira]

Hi Steven,

Other solution is to change the static nature of the applicationName setting
to be dynamic by writing a very basic derived provider. we can see that in
the book "Professional ASP.NET 2.0 Security, Membership, and Role Management"
- Stefan Schackow. Great book !!

I understand both the solutions but in my opinion and because of that
“security problem†should exist another parameter field to avoid that kind of
solutions. For example, MSFT could create one parameter field
“applicationMembershipKey†that should have one character password or
something like that. That additional parameter will avoid all that kind of
solutions.

Example:

<add name="AspNetSqlMembershipProvider" applicationName="/Site1"
applicationMembershipKey=â€as548965dâ€â€¦.. />


Thanks again for your help

Best regards,
Ricardo Figueira (rbfigueira)

 

[Steven Cheng[MSFT]]

Thanks for your reply Ricardo,

I think your solution is a nice one .

Yeah, Stefan Schackow is the program manager of web UI team. He is quite
experienced on this and often some experience on the membership and other
providers.

BTW, not sure whether you've already read the following article as there
also listed plenty of resoures about ASP.NET membership service:

#ASP.NET 2.0 Membership, Roles, Forms Authentication, and Security
Resources
http://weblogs.asp.net/scottgu/archive/2006/02/24/438953.aspx

As always, please don't hesitate to post here if there is anything we can
help.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.