Membership - Database Security

Discussion in 'ASP .Net Security' started by rbfigueira, Oct 18, 2006.

  1. rbfigueira

    rbfigueira Guest

    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
     
    rbfigueira, Oct 18, 2006
    #1
    1. Advertising

  2. 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.
     
    Steven Cheng[MSFT], Oct 19, 2006
    #2
    1. Advertising

  3. rbfigueira

    rbfigueira Guest

    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 !! :p

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

    Best regards,
    Ricardo Figueira (rbfigueira)


    "Steven Cheng[MSFT]" wrote:

    > 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, Oct 19, 2006
    #3
  4. 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.
     
    Steven Cheng[MSFT], Oct 20, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ABC
    Replies:
    5
    Views:
    604
    Scott Allen
    Nov 23, 2005
  2. 00_DotNetWarrior
    Replies:
    6
    Views:
    2,651
    Juan T. Llibre
    May 13, 2006
  3. Keith
    Replies:
    1
    Views:
    2,363
    Keith
    Jul 3, 2006
  4. cs_in_va
    Replies:
    1
    Views:
    538
    Eliyahu Goldin
    Mar 6, 2008
  5. Tino Donderwinkel
    Replies:
    2
    Views:
    816
    Tino Donderwinkel
    Jun 18, 2008
Loading...

Share This Page