Secure a php proxy? - php

Question

So on my site (https://example.com) I have a page that parses the last.fm API and pulls back the images off their akamai CDN and displays them on the page.
The thing is all the images are served on HTTP ONLY, https is not supported.
e.g: http://userserve-ak.last.fm/serve/64s/76030502.png
I have an image proxy written in php:
<?php
header('Content-Type: image/png');
if(isset($_GET['img'])){echo file_get_contents($_GET['img']);}
?>
This works perfectly, however, is NOT secure at all, I want it so that only my server can use the image proxy and as such a hash in the URL might be the best option?
https://example.com/proxy.php?url=http://last.fm/image.jpg&hash=hashhere
I had thought of using:
md5($_GET['img']."privatekeyhere");
Then my problem turned to, how to I put the private key in the javascript code without the whole world having access to it?
Any help much appreciated.
I have since written this script that is somewhat effective but still open to being circumvented:
<?php
$args = $_GET['q'];
$date = date('m-d-Y-h-i', time());
list($hash,$img,$auth) = explode("/", $args);
if($hash=="need" && $auth=="key"){
$checksum = md5($img.$date);
echo $checksum;
}
if($hash==md5($img.$date))
{
header('Content-Type: image/png');
echo file_get_contents('http://userserve-ak.last.fm/serve/64s/' . $img);
}
?>
This can be called like so: https://www.mylesgray.com/lastfm/need/76030502.png/key
The auth code can then be plugged in to display the image: https://www.mylesgray.com/lastfm/{code-here}/76030502.png
However it doesn't take long for someone to figure out they can set up a script to poll for a key every minute - any advice?

Answer 1

Generate unique tokens. You're on the right track with a hash, but if you keep your private key constant, it'll eventually get brute-forced. From there, rainbow tables say hi.
You're effectively going to have to borrow a leaf or two from mechanisms used to prevent CSRF abuse, as you're effectively trying to do the same thing: limit the user to one query per token, with a token that cannot be regenerated by them.
There are tons of ways to do this, and the usual trade-off is between efficiency and security. The simplest is what you've suggested - which is easily brute-forceable.
At the opposite end of the spectrum is the DB approach - generate a unique token per visit, store it in a DB, and validate subsequent calls against this. It is pretty DB-intensive but works out relatively well - and is virtually impossible to break unless the token generation is weak.