Asset Access Restriction Methods – Block Unwanted Visitors

When building an awesome web app or website, we sometimes want people to be able to embed parts of our web app/website into their own. That could be an iframe holding a ‘like’ button, a simple image that they want to reuse or even our entire app embedded in an iframe.

But how do we control who has access, who is allowed to use up our bandwidth and query our service?

We define the problem as controlling access to assets

By assets we mean: anything that can be queried from our site.

Access Restriction: Allow some, block all

When talking about access control, we enter the domain of security. And when talking security, whitelisting should be the approach taken to tackle the problem. It is easier to control who is allowed to access your assets than it is to control who is not. It is simply impossible to know all the boogie monsters of the internet.

To protect our assets, we hire a gatekeeper to only let the ones we trust in. Once hired, we give him access to a whitelist we control, and let him do all the heavy lifting. Problem solved. But how should the gatekeeper lift?

Lifting tactics

Depending on how secure you want the gatekeeper to be and what the client asked for, different tactics can be used.

A common approach used is checking the Referer header. That method has 3 big drawbacks:

The referer is also set when people access your website using a link

The referer is sent to your server by the client, and could be altered

The referer might not be set at all

However, for static assets such as images, js and css, those drawbacks are not an issue. Your assets should only be loaded when users are visiting our website directly (or from a trusted site). The general idea is to block others hotlinking them. The referer will thus always be on your whitelist. Unless you don’t trust yourself – but then you have bigger issues.

Bro, do you even lift?

Depending on the setup used, the query made passes through a series of gates. The simple setup is: Client -> HTTP server -> application code

So where does your gatekeeper sit? The client is a de facto no go for access control because he is an unreliable lying piece of human. The HTTP server and the application code on the other hand are useful options. Both give us strong tools to check the HTTP_HOST.

HTTP servers know how to lift

The strength in having your HTTP server handle your access control is speed. There is no need to fire up the application code for every request. This can drastically improve performance because we do not need to load an entire application stack/thread (e.g. mod_php) into memory.

Depending on your HTTP server, different solutions are available.

Apache

In Apache, there are two different methods. We can use mod_rewrite or Allow/Deny.

What about those iframes?

As mentioned, relying on the referer isn’t always a good idea. It is not only data from our unreliable human, it also gives us no clue as to whether we are in an iframe or not. There is simply no way of knowing.

We could however hire a hitman to help our GateKeeper. Our hitman will be dispatched to the humans that look suspicious (e.g. the ones with an untrusted referer). The hitman will use JS as his weapon:

Sadly enough, someone arriving from an untrusted domain has the same referer as someone else that accesses us using an iframe from that untrusted domain. Assets, however, will have the referer set to our domain (even in an iframe situation) – so sending a hitman here is overkill. Simply denying access is enough – or you could send a random kitten image.

That is why we have our hitman check if we are in an iframe. If so, we have him kill our target:

if (top.location.href != self.location.href) {
//kill the target
}

The only thing we need to do know is to have our GateKeeper add the hitman to the payload sent to the client. Easy!

Jeroen Meeus is a developer that knows how to appreciate his glass of CH3CH2OH with well written code to read on a lazy sunday. When frustrated, he tends to share those frustrations at his so-called blog.