For many, the most obvious use of our popular LinkDeny filter for Microsoft IIS Web servers is to block the illegal theft of bandwidth (called leeching), usually in the form of direct image hotlinking.  However, LinkDeny wasn’t designed just for that particular problem… In fact, the product aims to provide a multitude of access control mechanisms that can be used on arbitrary URLs.   Think of LinkDeny as the step before you force authentication or even the one after authentication, an extra step where you can effectively keep people from abusing your site or application.  
 
One of the most interesting ideas we included was the idea of providing enforced URLs by using a message authentication code (MAC) on the query string.  It appears that Amazon thinks this is an interesting idea as well, as they have recently added it to the Web Services APIs (http://docs.amazonwebservices.com/AmazonDevPay/2007-12-01/DevPayDeveloperGuide/WebQueryStringAuth.html).  Amazon calls this "Query String Authentication" or "Pre-Signed URLs". 

You can follow the link for the details but here's how it works in a nutshell:
 
Suppose you have a product that stores data using Amazon's Simple Storage Service (S3) and, to keep things simple, that also uses Amazon's billing and account management service (DevPay) to make sure you get paid when someone uses your product.  Now it might be very convenient in this situation if you could give third parties (your customers) direct access to your S3 data, without having to proxy all their requests.  The question arises though: how can you do this while still getting paid for the use of the data?
 
The answer is that you can provide your customers with a URL to use that is "pre-signed" with a secret (a key) that only you and Amazon know about.  If someone tries to get at your data to whom you have not given this magic URL, they don't get a thing.  The URL itself becomes an authentication mechanism for your legitimate customers.
 
The recipe for doing this is not complex.  If you have an Amazon Web Services account, you already have a secret key, plus an identifier (an access key id) that corresponds to it.  When forming the URL, you simply use that private key to hash various elements of the request, and then pass that hash, along with the access key id, on the query string.  To prevent replay attacks, you also pass an expiration time.  On the S3 side, Amazon's authentication routine simply takes access key id, looks up your corresponding access key, and uses it to recompute the hash on the request.  If the hashes match, they know this request is authentic, and the data is sent back.
 
The neat thing about this is that the entire authentication is handled in the URL itself.  There are no other HTTP headers or handshakes or anything of the kind.  Making your data available, while restricting it to authenticated users, becomes as easy as exposing a URL.
 
Now, this happens to be the same basic approach that LinkDeny can take, in order to prevent your valuable external files like images and scripts from being hijacked.  This is called the LinkDeny URL Time Limit feature.  The difference between LinkDeny's approach and the Amazon API is that all you have to do is supply a mask (a sequence of arbitrary characters) in the URLs that are in your source code (for instance, the src attributes of your image tags) -- and LinkDeny does all the rest. 
 
As your pages are sent out from the server, the mask in those URLs is replaced with a time-limited MAC that is based, as in the Amazon scheme, on a private key.  This is analogous to your providing legitimate customers with pre-signed URLs for all your dependent files.  That would be impossible to manage manually of course, but LinkDeny handles that part for you, keeping track of the currently-valid requests and rejecting any that hit their expiration time-outs, or that lack a valid signature.  While the basic use for this is to protect images and other page elements, you could easily adapt it to a RESTful Web service as well.
 
So there you have it, if you want to provide a RESTful Web service via your URLs, either purposefully or by accident, it is time to install LinkDeny and enjoy the same protection Amazon does -- without all the code!
 
Cheers,
Port80

Here is a short and sweet list of free IIS security tools by Kevin Beaver @ TechTarget (he wrote the classic Hacking for Dummies):

http://searchsecurity.techtarget.com.au/articles/24798-Free-tools-to-improve-IIS-security

Port80's HeaderCheck and other free HTTP analysis tools are mentioned  in there as well (toot-toot goes the horn), but it is a useful list of tools.  And free is nice, given the price of gas and all!

Cheers,
Port80

PS Our Deal Packs are not “free“, but they are a little lighter on the ol' budget -- check them out at http://www.port80software.com/deals/.

 

 

 

Given latency and constrained connections out there, if you ever receive this download warning, make sure you have lots of food and water stored up for the wait:

http://www.w3schools.com/downloadwww.htm

There are some files even HTTP compression and caching cannot help!

: )

Cheers,
Port80

 

Learn how to send less data, less often in this new archived webinar from Port80 Software!

Port80 Software invites you to view a webinar on Web performance solutions... We recently reviewed the Web acceleration market, where Port80 Software solutions like httpZip, ZipEnable, CacheRight, and w3compiler come to play on IIS Web server performance, and how to analyze HTTP compression and Expiry Cache Control solutions with HTTP analysis tools. 

Agenda -- Web Performance Solutions for Microsoft IIS Web Servers:

- Common Web Performance Challenges
- The Web Acceleration Market
- Analyzing the HTTP Request/Response Cycle
- HTTP Compression
- Expiry Based Cache Control
- Questions and Answers...

Login to Access the Archived Webinar:

- Go to https://www119.livemeeting.com/cc/port80/view?id=Web_Performance_Solutions_1.
- Enter your name, the Recording ID if not already entered (Web_Performance_Solutions_1), bypass the Recording Key (this is not required), and then click View Recording.
- You will be presented with two format options on the next screen:



- We recommend choosing the second version as the first version does not include video.
- Click the Windows Media icon under ‘View’ for the Microsoft Office Live Meeting Replay version, and this will launch the Webinar in Windows Media Player (http://www.microsoft.com/windows/windowsmedia/default.mspx).
- If you have any trouble logging into the Webinar, please just ask for help at support@port80software.com.

Thanks for watching, and please let us know if you have a topic for our next webinar event or if we can answer any questions on IIS performance!

Best regards,
Port80 Software

The recent wave of SQL injection attacks has made mainstream news, just in case you have not seen it:

Hundreds of Thousands of Microsoft Web Servers Hacked

Jeremiah Grossman and others have made the point, accurately, that this is not a Microsoft IIS Web server issue, but rather that Web developers not adhering to security best practices are to blame (for shame, it is not like we have enough to do already!):

Security expert: Don't blame Microsoft for mass site defacements

To solve this puzzle, look no further than controlling parameters, permissions and sanitizing your inputs with a Web application firewall or WAF like ServerDefender AI or the upcoming ServerDefender VP.  Yes, you can learn to write more secure code, but why wait to get protected or deal with recoding legacy bits?  Get a WAF, and get PCI complaint, something we all need to be focusing on now.

Cheers,
Port80

PS BTW thanks to Jeremiah for being one of the early believers in ServerMask... it is nice to watch as his security star rises!

Minor releases rarely get headlines, but why not? They are important as well!  

This interim release of httpZip has important changes for improved reporting and swatting a few bugs, so if you are a Zip customer or a just checking out HTTP compression, download the new bits. However, get ready for a major httpZip upgrade in the future, as 64 bit is on the way. We are working on getting the code out to our beta testers as soon as we can.

So, if you aren’t on the Zip bandwagon yet, remember that even with massive broadband penetration, your Web users always want more speed (http://www.emarketer.com/Article.aspx?id=1006022).

More to come,
Port80