Wednesday, July 27, 2011

Using the HTTPHandler tag to protect your content

Protecting your content from unauthorized access can be a fulltime job.  To help protect your files from being read through the URL or in Header requests, you can employ a technique by using HTTPHandlers.
In this case, we have a website that has to read and utilize .ini files depending on which system the website has been deployed on.  The code-behind of the application will still need to read the ini file, however we do not want users having access to the file through the URL: http://www.somewebsite.com/myWebConfig.ini
By typing in the previous address into the URL, the .Net Framework would look for a Handler so that it knows how to render the resource to the user.  Since we have not setup a Handler for ini files, it will simply render the file to the user in text format.  To get a concept of what happens when you have no handler for a requested resource, we’ll remove the handler for the typical ASP.Net web form.  To do this, you will need to open Visual Studio and create a new website.  Open your web.config and in the system.web node add a HTTPHandler node and then we will issue a remove statement:
Web.config file


Code Snippet
1.  <system.web>
2.  <httpHandlers>
3.  <remove path="*.aspx" verb="*"/>
4.   </httpHandlers>
5.    </system.web>
Now when you run your web site, it simply renders the page as text (because it has no Handler and thus no idea how to process the page).  This is why if you request a txt file it will render the text file.  However, if your site deals with txt files and needs to process them, you can write a Handler, register it in the web.config and then process the request through the website (This is how we can write a Syntax Highlighter that will highlight and make readable a .vb or .c file – which is essentially a text file only we have registered a Handler that knows how to process the page).  Keeping this in mind, you can write a Handler for practically any type of resource you want, or you can even dream up your own (I’m thinking a .chad resource would be awesome!)
Keeping Unwanted Access Out:
Now that we have a little understanding on how Handlers help us process resources, we have an idea of what we need to do to limit access to those resources.
<system.web>
<httpHandlers>
      <add path="*.aspx" verb="*" 
 type="System.Web.HttpForbiddenHandler" validate="true"/>
    </httpHandlers>
  </system.web>
How does this limit access?  Well the System.Web.HttpForbiddenHandler is simply a Handler that issues a HTTP 403 Error: Not Authorized, effectively locking the user out and displaying a rather unfriendly MS ASP.NET error page.  If you trap the error with customErrorPages, you could direct them to a much friendlier page letting the user know that what they are trying to access is a no no.  This is much more efficient than writing your own HttpForbiddenHandler as it is a System.Web class and native to the .Net Framework thus you are not adding the overhead of referencing another assembly.
In the past, developers have added many add tags for references to the same Handler.  This does two things, it creates and instance of the Handler for each requested resource and also makes your web.config larger, harder to read and less efficient.  So instead we use (for best practices):
      <add path="*.ini,*.config,*.txt" verb="*" 
 type="System.Web.HttpForbiddenHandler" validate="true"/>
Comma separating the values is the most efficient way to use the path parameter.
Extending or limiting access to your website’s resources is absolutely essential in the .Net 4.0 Framework.
Happy .Netting… Saleh

No comments:

Post a Comment