<location> path authorization is not properly checked for override restrictions

Discussion in 'ASP .Net Security' started by Gery D. Dorazio, Aug 13, 2004.

  1. Hi,

    This is to make developers aware of a possible problem that shows up in the
    authentication mechanism in the Web.Config files. Here is the scenareo:


    The directory structure that reveals this problem is this:

    /Admin/Products/Test1


    The application Web.Config file in the root directory is this:

    <configuration>
    <system.web>
    .....

    <authentication mode="Forms">
    <forms name=".MyWebsite" loginUrl="Login.aspx" protection="All"
    timeout="60" path="/">
    </forms>
    </authentication>
    <authorization>
    <allow users="*" /> <!-- Allow all users -->
    </authorization>

    </system.web>

    <!-- secure intermediate directories -->
    <location path="Admin" allowOverride="true">
    <system.web>
    <authorization>
    <allow roles="Admin" />
    <deny users="*" />
    </authorization>
    </system.web>
    </location>

    <location path="Admin/Products/Test1" allowOverride="false">
    <system.web>
    <authorization>
    <allow roles="User,Admin" />
    <deny users="*" />
    </authorization>
    </system.web>
    </location>

    </configuration>


    There is another Web.Config file in the /Admin/Products directory with this
    in it:

    <configuration>
    <location path="Test1" allowOverride="false">
    <system.web>
    <authorization>
    <allow roles="PowerUser" />
    <deny users="*" />
    </authorization>
    </system.web>
    </location>
    </configuration>


    Here is what happens:

    1) I login and my roles are User and Admin so either role allows me into the
    /Admin or /Admin/Products directories.
    2) But if I type in the url
    www.mywebsite.com/Admin/Products/Test1/Default.aspx it takes me to the login
    page. It should not. It should give an error that the web.config is not
    configured properly...but it does not.


    Analysis:

    1) The original web.config file <location> tag contains the
    allowOverride='FALSE' setting and it appears to NOT be honored OR it is
    overridden.
    2) The <location> tag in the web.config file in the /Admin/Products file is
    honored.
    3) No configuration error is encountered.

    Conclusion:
    It was at first thought that the algorithm used by the
    UrlAuthorizationModule first builds the authentication schema based on the
    directory structure, populates each directory with its settings and then
    does a top down check of whether any authorizations should be accepted based
    on the allowOverride setting...and if any are inconsistent with the
    allowOverride setting, throw an exception. However, this can not be the case
    since no error is thrown in the sample code above.

    Another possible algorithm is that the topdown check of authorization occurs
    AS THE TREE IS BEING TRAVERSED. If this is the case, which it appears to be
    given the characteristics of this error, the data in the config files above
    would then escape that algorithm test because the <location> element in the
    root config file specifies a directory that is ahead of the checking
    algorithm.


    So...to check this another way and verify my sanity, I changed the
    web.config in the /Admin/Products directory so that all users were allowed
    into the /Admin/Products/Test1 directory...eg to this:

    <configuration>
    <location path="Test1" allowOverride="false">
    <system.web>
    <authorization>
    <allow users="*" />
    </authorization>
    </system.web>
    </location>
    </configuration>


    And low and behold it allows me to access a page in the
    /Admin/Products/Test1 directory WHETHER I AM LOGGED ON OR NOT...

    Now for the potential hidden and sneaky hack....(unless someone has access
    to the web.config files this is probably unlikely)...but from a disgruntled
    employee this could be disastrous....say you have a directory that does
    payment authorizations or lists credit card information and it is an admin
    page only. Now someone modifies the web.config files as above, goes in
    anytime without even logging in and accesses the information...bingo, we
    have a problem Houston....let alone someone else just stumbling onto this
    situation from the internet.


    Looks like a case of programming the job to do what it is supposed to do but
    not to prevent what it is not supposed to do. (defensive programming) Also,
    this shows a general problem with XML type data that is used as program
    control information...especially in this type of scenareo where a 'linked'
    set of XML files is involved.


    Cheers...and comments welcome...sorry so long, this was a big headache and I
    had to get it off my chest.

    Thanks,
    G



    --
    Gery D. Dorazio
    Development Engineer

    EnQue Corporation
    1334 Queens Road
    Charlotte, NC 28207
    (704) 377-3327
    Gery D. Dorazio, Aug 13, 2004
    #1
    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. yurps
    Replies:
    1
    Views:
    6,871
    rajeshthangarasu1983
    Feb 29, 2008
  2. runescience
    Replies:
    0
    Views:
    4,239
    runescience
    Feb 23, 2006
  3. Replies:
    3
    Views:
    399
    Joe Kaplan \(MVP - ADSI\)
    Mar 10, 2006
  4. SeanRW
    Replies:
    1
    Views:
    353
    Dominick Baier [DevelopMentor]
    May 25, 2006
  5. Mike

    ASP.NET Role Authorization Override

    Mike, Jun 9, 2009, in forum: ASP .Net Security
    Replies:
    4
    Views:
    1,038
Loading...

Share This Page