G
Gery D. Dorazio
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
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