Securing PHP Code that Creates Images

I have a pretty nice php web site, that's also reasonably secure.
However, I wrote some php code to create some dynamic images based on
database data, but I can't figure out how to secure this script?


when I reference the php code via img src="myimage.php", none of my
session variables are available for use in the script. So, without my
session variables, how am I suppose to ensure that the script is only
run by a valid user, rather than just anyone who can blindly type in
random parameters to my image creation script?


I'm really stumped on this one.

Steve wrote:

> I have a pretty nice php web site, that's also reasonably secure.
> However, I wrote some php code to create some dynamic images based on
> database data, but I can't figure out how to secure this script?
>
> when I reference the php code via img src="myimage.php", none of my
> session variables are available for use in the script. So, without my
> session variables, how am I suppose to ensure that the script is only
> run by a valid user, rather than just anyone who can blindly type in
> random parameters to my image creation script?
>
> I'm really stumped on this one.

Not sure why you would be having problems with the session stuff, and anyway
it's not a perfect solution because it won't work if they don't have
cookies enabled.

I had a similar problem with one of the sites I manage, and it was
compounded by people linking to generated images putting additional load on
the server and generating additional traffic.

We recently released a completely revised version of the site with a new
design and I rewrote the engine that generates the images. Now instead of
generating the images by doing something like foo.php?param1=x&param2=y
type of thing, we generate all the images while the page is being created
with what are essentially random image names (they're md5 hashes of the
data that goes into makign up the image).

The image is then saved to the filesystem and linked to in the page as eg
637b9aa7da08f0c649367a39f9d5023a.jpg Once every hour a script runs on the
server which deletes any of these temporary images that were generated more
than two hours ago. (If the image is requested again on a page and the file
exists, the timestamp is updated to the current time).

The advantage of doing it this way is that people cannot directly access the
image generation script, and there's no possibilty of hotlinking to the
image from another site as they'll get a broken image after 2 hours. The
only downside I can see is that if the browser returns a cached page after
a couple of hours they may end up with some broken images, but this appears
to be pretty rare from browsing the server logs.

This solution may or may not be useful for you depending on a variety of
factors. If you want some further info feel free to email me - just change
blackhole for chris in my email address.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

Chris Hope <blackhole@electrictoolbox.com> wrote in message news:<7o5ad.11801$JQ4.749785@news.xtra.co.nz>...
> Steve wrote:
<snip>
> > when I reference the php code via img src="myimage.php", none of my
> > session variables are available for use in the script.

It shouldn't happen unless your script is buggy.

> Not sure why you would be having problems with the session stuff, and anyway
> it's not a perfect solution because it won't work if they don't have
> cookies enabled.

Not sure, what are you talking about.

<snip>
> The advantage of doing it this way is that people cannot directly access the
> image generation script, and there's no possibilty of hotlinking to the
> image from another site as they'll get a broken image after 2 hours.

Incidentally, hotlinking can be *easily* fixed with session and
output buffering techniques.

--
| Just another PHP saint |
Email: rrjanbiah-at-Y!com

R. Rajesh Jeba Anbiah wrote:

> Chris Hope <blackhole@electrictoolbox.com> wrote in message
> news:<7o5ad.11801$JQ4.749785@news.xtra.co.nz>...
>> Steve wrote:
> <snip>
>> > when I reference the php code via img src="myimage.php", none of my
>> > session variables are available for use in the script.
>
> It shouldn't happen unless your script is buggy.
>
>> Not sure why you would be having problems with the session stuff, and
>> anyway it's not a perfect solution because it won't work if they don't
>> have cookies enabled.
>
> Not sure, what are you talking about.
>
> <snip>
>> The advantage of doing it this way is that people cannot directly access
>> the image generation script, and there's no possibilty of hotlinking to
>> the image from another site as they'll get a broken image after 2 hours.
>
> Incidentally, hotlinking can be *easily* fixed with session and
> output buffering techniques.

Except you cannot rely on sessions. If they don't have cookies enabled in
their browser then every request will appear to be from a new session.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Hope wrote:

[snip]
> Except you cannot rely on sessions. If they don't have cookies
> enabled in their browser then every request will appear to be from a
> new session.
>

Unless you use URL rewriting to carry the session ID. See "Passing the
Session ID", about 1/2 the way down this page:

http://php.net/manual/en/ref.session.php

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBatStgxSrXuMbw1YRAlkhAJ95EpLJ2Vj+6uFp/k/ytiRBQbjq5QCgoo8J
T9zW4YBEE+kKsbV9svRIBmY=
=qmZh
-----END PGP SIGNATURE-----

Chris wrote:

>> Except you cannot rely on sessions. If they don't have cookies
>> enabled in their browser then every request will appear to be from a
>> new session.
>>
>
> Unless you use URL rewriting to carry the session ID. See "Passing the
> Session ID", about 1/2 the way down this page:

That's true.

However in my case, it was far more efficient to generate the images before
they would be requested as there can be up to 6 generated images on a page,
and the speed increase was over 500% than creating each one as they were
requested.

Also, the caching aspect of it (ie writing the file out to the filesystem
for a set period of time) was also useful for my solution as the same image
may be requested multiple times by the user within three to four pageviews,
and this may or may not have been cached by the browser.

Overall page generation time has sped up considerably and the server load
has decreased dramatically. We generate roughly 50 thousand of these images
a day so every time/load saving is important.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

Chris wrote:

> Chris Hope wrote:
>
>>Except you cannot rely on sessions. If they don't have cookies
>>enabled in their browser then every request will appear to be from a
>>new session.
>
> Unless you use URL rewriting to carry the session ID. See "Passing the
> Session ID", about 1/2 the way down this page:
>
> http://php.net/manual/en/ref.session.php

Yup, I got into the habit of using trans-sid when I started messing with
sessions - I haven't looked back since. ;)

--
Justin Koivisto - spam@koivi.com
http://www.koivi.com

Steve wrote:
> I have a pretty nice php web site, that's also reasonably secure.
> However, I wrote some php code to create some dynamic images based on
> database data, but I can't figure out how to secure this script?
>
>
> when I reference the php code via img src="myimage.php", none of my
> session variables are available for use in the script. So, without my
> session variables, how am I suppose to ensure that the script is only
> run by a valid user, rather than just anyone who can blindly type in
> random parameters to my image creation script?
>
>
> I'm really stumped on this one.

Make sure the $HTTP_REFERER is from an "allowed" domain... any page on
your site that accesses the php script will have your domain as the
referer... anyone trying to use the script "off domain" will have a
different referer.

I have client's sites that do not have php on their host, so I whitelist
their domains to access my scripts. It seems to work well...

Fox
************

Fox wrote:

> Steve wrote:
>> I have a pretty nice php web site, that's also reasonably secure.
>> However, I wrote some php code to create some dynamic images based on
>> database data, but I can't figure out how to secure this script?
>>
>>
>> when I reference the php code via img src="myimage.php", none of my
>> session variables are available for use in the script. So, without my
>> session variables, how am I suppose to ensure that the script is only
>> run by a valid user, rather than just anyone who can blindly type in
>> random parameters to my image creation script?
>>
>>
>> I'm really stumped on this one.
>
> Make sure the $HTTP_REFERER is from an "allowed" domain... any page on
> your site that accesses the php script will have your domain as the
> referer... anyone trying to use the script "off domain" will have a
> different referer.
>
> I have client's sites that do not have php on their host, so I whitelist
> their domains to access my scripts. It seems to work well...

However, you also need to allow the images to be seen if the
$_SERVER['HTTP_REFERER'] is not set; some people install software (or their
browser allows them to) that prevents this information being passed to the
server, and they'll get broken images even though you don't intend this to
happen for those people.

--
Chris Hope - The Electric Toolbox - http://www.electrictoolbox.com/

Chris Hope wrote:
> Fox wrote:
>
>
>>Steve wrote:
>>
>>>I have a pretty nice php web site, that's also reasonably secure.
>>>However, I wrote some php code to create some dynamic images based on
>>>database data, but I can't figure out how to secure this script?
>>>
>>>
>>>when I reference the php code via img src="myimage.php", none of my
>>>session variables are available for use in the script. So, without my
>>>session variables, how am I suppose to ensure that the script is only
>>>run by a valid user, rather than just anyone who can blindly type in
>>>random parameters to my image creation script?
>>>
>>>
>>>I'm really stumped on this one.
>>
>>Make sure the $HTTP_REFERER is from an "allowed" domain... any page on
>>your site that accesses the php script will have your domain as the
>>referer... anyone trying to use the script "off domain" will have a
>>different referer.
>>
>>I have client's sites that do not have php on their host, so I whitelist
>>their domains to access my scripts. It seems to work well...
>
>
> However, you also need to allow the images to be seen if the
> $_SERVER['HTTP_REFERER'] is not set;

Think about this for a second... no referer, no see... it's *my*
bandwidth. I don't need anyone hijacking the scripts for their own purposes.

> some people install software (or their
> browser allows them to) that prevents this information being passed to the
> server, and they'll get broken images even though you don't intend this to
> happen for those people.
>