|
|
^ click above ^
|
|
05.21.03
Someone’s been stealing your content.
Really.
It’s easy to do, too. I’m talking about all the fancy jpgs, gifs, docs and pdfs on your site. Guess what? If I can hit them with a URL, they’re mine.
Don’t like it? Too bad.
If you have a default page, I can set up a spider to snake out all of your content in a couple of minutes. Google has been doing it for quite a while – they finger your site, snatch out all of your graphics and your entire HTML.
Ok, so now you’re saying “so what?” – the web is open to anyone, isn’t it? Well, yes and no. Sometimes, you don’t want to give someone access to your precious pdf file or your latest story crafted in Microsoft Word. You could use straight ACL security to guard these files, but not all of your end-users are going to be using IE – thus, the ACL authentication isn’t going to work for these unfortunate few. And guess what? The authentication process used by ASP.NET only applies those resources (.aspx, .ascx, .vb, .cs) that are mapped to the aspnet_isapi.dll. – ASP.NET authentication doesn’t work to protect .doc, .zip, or .pdf files.
Don’t even try and sneak by a file named 903890xx0s9ki49.pdf - It’s still not secure and you’re being foolish in assuming that obscurity is security. A good spider or a good hacker is going to be able to sniff your HTTP traffic and bust your ‘obscure secure’ security.
So, what’s the solution? Enter the HttpHandler.
|
|
HttpHandler Overview
The HTTPHander is a slick API that allows developers to snatch response/request methods and react to them without all the overhead of full-blown page handling. If you’ve done any C++ ISAPI work in the past, you’ll know where I’m going here.
Each and every HTTP request coming down the pipe in ASP.NET is handled by classes that implement the IHttpHandler interface. In our case, what we’re looking to do is intercept the request for a .doc or .pdf file and we’ll actually create a custom HttpHandler to determine if an end user has the proper credentials to try and access the file.
By now, everyone has seen examples of how you can trap custom extensions via HttpHandlers – one example out there is filtering out a request from a default.time page. Simply put, the HttpHandler does its job, and you context.response.write out the current time on the server.
Yawn.
Yet another example of useless code that no one will use.
Let’s take a look at some real code that you can use in your E-commerce site or just to secure access to files without resorting to ACL, FTP or forced browser requirements.
Modifying Web.Config
First things first: We need to add an XML tag to our web.config file in the folder we want to ‘secure’.
What we’re doing here is telling the IHttpHandler interface that we’d like to intercept requests for paths that end with .doc.
The verb attribute is used when you want to restrict requests via ‘POST’ or ‘GET’ or ‘HEAD’. You’ll just want to stick with a ‘*’ – this will allow all of the above.
The path attribute lets the HTTP runtime know what’s the valid path for a request. In this case, we’re telling the HTTP runtime that we’re interested in any resource that ends with .doc.
The type attribute lists out the .NET class that you’ve created to handle the request. It’s the fully qualified class name followed by the assembly name. [NAMESPACE].[CLASS], [ASSEMBLY NAME].
Adding a Custom Extension
Since we’re adding a custom extension to IIS (.doc, .pdf), we’ll need to map these extensions into IIS. Don’t make the mistake in thinking that just because a .doc or .pdf file opens in your browser that you’re good to go. You’ll need to get what’s executing server side vs. client side straight in your head. Once you’ve done that, check out the screen shots below:
Fire up your IIS Manager and then choose Properties --> Edit… You’ll need to navigate to the Home Directory tab and then click on the ‘Configuration’ button.
Next, you’ll have to add your ‘custom’ extension (.pdf, .doc) to the application configuration screen. Click the add button and fill in the needed information. It’s a fairly straightforward process, so you shouldn’t have too much trouble.
After you’ve got this critical step handled, you’re ready to move to the next step – coding your HttpHandler.
|
|
|
|
