3

I have a website that allows user uploads of content. Part of the design, to date, involves storing the user content on a NAS that has been configured with a separate app pool in IIS that has scripting disabled, shorter lifespans, no cookies, etc for CDN-type behavior as a subdomain (static.domain.com vs. www.domain.com). I have complete control over this process and all the instances. The design decision behind this was to allow for cheaper storage of uploaded documents (instead of wwwroot or a DB) and help mitigate some security concerns by disallowing scripting.

The concern I have now is that CDNs, and this setup, are by nature very permissive and do next to no checking or validation. Are there any reasonably effective measures to discourage idle sharing of this user content? I know nothing will stop determined or malicious people, but I want to at least prevent this user content from being available at large to the general populous. All of the links to the content will be behind a paywall at the 'www' subdomain, but the content itself will be behind the 'static' subdomain.

Ideas I had so far:

  1. HTTP Referer checking
  2. Obfuscated filenames (I know, I know...)
  3. Cookie testing with URL rewrite? (IIS8)
  4. ...
  5. Ask stackexchange
Bryan Boettcher
  • 2,754
  • 4
  • 21
  • 31

1 Answers1

1

Are there any reasonably effective measures to discourage idle sharing of this user content?

Rate limiting would be the simplest thing to do:

So for example, a request coming from a particular IP address, may not download a picture file more than 10 times in 1 hour. So what a customer should be able to do, is create a rule that when activated for a specific URI destined for a container protected by the rule, does the following:

1)  Looks at the incoming URI. 
2)  Checks if the URI is for a file that is inside a container defined in a rule (image container for example) 
3)  Pulls out HitCount(integer) for this URI by requester’s IPAddress+URI(Key) 
4)  Checks if HitCount for this URI from that IP has exceeded the allowed hit count (defined by user) during (a time frame defined by user). 
5)  If HitCount is equal to the limit, then CDN serves 403. Else CDN serves the content.

6)  When a timeframe defined by a user has elapsed, The HitCount goes back to 0, and requests can continue until HitCount limit has been reached again.

Hotlink protection would be another:

When enabled, the "Hotlink Protection" option ensures that other sites cannot suck up your bandwidth by building pages that use images hosted on your site. Anytime a request for an image on your site hits Cloudflare, we check to ensure that it's not another site requesting them. People will still be able to download and view images from your page, but other sites won't be able to steal them for use on their own pages.

In other words, HTTP Referrers that are not in-zone and not blank will be denied access. Supported file extensions are gif, ico, jpg, jpeg, and png.

**Protected**: http<nolink>://example.com/pic.jpg  
**To bypass**: http<nolink>://example.com/hotlink-ok/pic.jpg

Signed URLs would be a third:

When signed URL handling is enabled on a backend, Cloud CDN gives special handling to requests with signed URLs. Specifically, requests with a Signature query parameter are considered signed. When such a request is received, Cloud CDN verifies the following:

The HTTP method is GET or HEAD.
The Expires parameter is set to a future time.
The request's signature matches the signature computed using the named key.

If any of these checks fails, a 403 Forbidden response is served. Otherwise, the request is either proxied to the backend or served from the cache. All valid signed requests for a particular base url (the part before the KeyName parameter) will share the same cache entry. Responses to signed and unsigned requests do not share cache entries. Responses are cached and served until the expiration time you set.

References

Community
  • 1
Paul Sweatte
  • 382
  • 2
  • 15