C# - Failure to Restrict URL Access

Definition by OWASP:

Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.

·         It is one of the common vulnerabilities listed in the OWASP. This will help the web developer to take security measures in the development process for avoid the URL access.

·         The specialized  Skilled or lucky person (hacker or attacker) can able to access the restricted URL access and started to invoke functions and pages.

·         Instead of following links attackers can access data sources files and collect sensitive data.

·         It is mainly because of user access settings User can able to access the page that are meant to restrict.

·         Every Web Application framework is vulnerable to the attack.

Reasons for the Failure to Restrict URL access

               

URL Access has to verify every page. Web page is supposed to be private or public.

·         Using forced browsing technique users can access unauthorized pages.

·         Hidden Pages can able to view with guessable URLs.

·         Outdated Access code control policy and lack of server side control policy lead to access the hidden/restricted page information.

·         Check whether authorization is required for the page.

·         Check whether page can be accessible to any authenticated user without checking the permission level.

·         Automated tools guess link will help us to find the folder and page names

For E.g., user/add

                Admin/usename.aspx

                Web config

                /Password.

                                Fig 8.1 Admin User Log in to view the user information.

                           Fig 8.2 Unknown User can access the admin page without authorization.

Prevent from Failure to Restrict URL Access

·         Required authentication for required pages.

·         Do the same for folder and files.

·         Use Role based authentication as much as possible.

·         Enforce security on both client and server.

·         Check before every operation

§   Initially we have logged in as start page and subsequent level we may think all the pages

 get protected.

§   Attackers simply by pass the security and access the rights.

§   This is not possible by .Net security provider.

·         Check policies instead of hard coded aspect implement highly configurable policies.

·         Use negative permission.

Example

Don’t Use

If (Web.Secuity.Identitiy.Role  ==”User”)

                Throw new Security Exception(“Denied”)

Use this

If (Web.Secuity.Identitiy.Role !=”Admin”)

                Throw new Security Exception(“Denied”)

Implementing ASP.NET Membership provider for authorization

Two ways to make the page authentication that are web configuration and site mapping.

     Web Configuration:

<location path="Admin">

 <system.web> <authorization>

<allow users="troyhunt" />

<deny users="*" />

</authorization>

</system.web>

</location>

      Site Mapping:

web .sitemap file which define site map

<?xml version="1.0" encoding="utf-8" ?>

 <siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >

<siteMapNode roles="*"> <siteMapNode url="~/Default.aspx" title="Home" />

<siteMapNode url="~/About.aspx" title="About" />

 <siteMapNode url="~/Admin/Default.aspx" title="Admin" />

</siteMapNode>

</siteMap>

A site-map entry in the Web.config under system.web which will enable security trimming:

<siteMap enabled="true">

<providers>

<clear/>

<add siteMapFile="Web.sitemap" name="AspNetXmlSiteMapProvider" type="System.Web.XmlSiteMapProvider" securityTrimmingEnabled="true"/>

</providers>

 </siteMap>

The navigation will inherit the authorization settings in the Web.config and trim the menu items accordingly.

Use Role Manager

Manage permissions at the role level, define this within our configuration where it can remain fairly stable and then manage the role membership in a more dynamic location such as the database. It’s the same sort of thing your system administrators do in an Active Directory environment with groups.

 

Resources

1. http://msdn.microsoft.com/en-us/library/ff648345.aspx

2. http://msdn.microsoft.com/en-us/library/ff647401.aspx

3. http://msdn.microsoft.com/en-us/library/ms178428(v=vs.80%).aspx

4. http://www.veracode.com/security/failure-to-restrict-url-access

5. http://www.slideshare.net/RapPayne/a8-failure-to-restrict-url-accesspptx