Confusion on HTML visibility

[jw88574]

Using Apache on an old PIII with Knoppix

I am playing with a captcha image builder on my personal site and it works
pretty good. It builds an image on the fly in var/www/pictures and hands
the actual code to a cgi script.

But, the image it makes can be seen by anybody just by surfing to
http://somehost/pictures. So putting a security feature in the document
root is probably not a good idea. Changing the path to build the image to
/usr/lib/cgi-bin/pictures solves the visiblity problem but the HTML code
that the cgi-script makes does not have the authority to see the new
location.

So it comes down to my not understanding the security of web scripts well
enough.

As I understand it, on this Apache the user comes in as user www-data.
The ownership and group to ./cgi-bin/pictures is www-data. I think this
is true because if the cgi-scripts aren't owned by www-data, they can't
won't run. But some of the documentation says that an Apache user always
comes in as unknown and I haven't resolved this issue yet, like why would
user unknown be allowed to run a script, rather than be escorted to
/dev/null.

After thinking about it, it would seem that by giving a world visible HTML
script the rights to see an image, whereever it is, it would be impossible
to keep that surfer from seeing the image in the raw, so to speak. To put
it another way, is there a method to allow an HTML script in the document
root to see and image (or file or whatever) and still prevent access to
that resource?

Tnx
James White

 

[Bone Ur]

Well bust mah britches and call me cheeky, on Tue, 18 Dec 2007 16:33:55
GMT (e-mail address removed) scribed:

Using Apache on an old PIII with Knoppix

I am playing with a captcha image builder on my personal site and it
works pretty good. It builds an image on the fly in var/www/pictures
and hands the actual code to a cgi script.

But, the image it makes can be seen by anybody just by surfing to
http://somehost/pictures. So putting a security feature in the
document root is probably not a good idea. Changing the path to build
the image to /usr/lib/cgi-bin/pictures solves the visiblity problem
but the HTML code that the cgi-script makes does not have the
authority to see the new location.

So it comes down to my not understanding the security of web scripts
well enough.

As I understand it, on this Apache the user comes in as user www-data.
The ownership and group to ./cgi-bin/pictures is www-data. I think
this is true because if the cgi-scripts aren't owned by www-data, they
can't won't run. But some of the documentation says that an Apache
user always comes in as unknown and I haven't resolved this issue yet,
like why would user unknown be allowed to run a script, rather than be
escorted to /dev/null.

After thinking about it, it would seem that by giving a world visible
HTML script the rights to see an image, whereever it is, it would be
impossible to keep that surfer from seeing the image in the raw, so to
speak. To put it another way, is there a method to allow an HTML
script in the document root to see and image (or file or whatever) and
still prevent access to that resource?

Depends on exactly what you mean by "access".

Regarding this image for instance, how would someone see it now without
using your page?

 

[Toby A Inkster]

To put it another way, is there a method to allow an HTML script in the
document root to see and image (or file or whatever) and still prevent
access to that resource?

Firstly, HTML is not a script.

Secondly you're answer is no. Any image that can be seen using <img> can
be seen by accessing the image's URL directly. Using the HTTP "Referer"
header, you might be able to kludge together a solution, but it will be
unreliable and can be easily worked around.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 12 days, 23:01.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/

 

[Sig]

Firstly, HTML is not a script.

Secondly you're answer is no. Any image that can be seen using <img> can
be seen by accessing the image's URL directly. Using the HTTP "Referer"
header, you might be able to kludge together a solution, but it will be
unreliable and can be easily worked around.

That's not always correct. The image need not be under the document root to be
displayed with readfile(). I have some images that are displayed with
<img src="/pv/incer3.php?z=blackler/1.jpg">, for example. The incer3 file
checks a session variable, and may decide to show the image using readfile().
If you enter the src url directly, whether you see the image will depend on the
session variables. There is no actual image url to enter.

 

[Toby A Inkster]

Toby A Inkster said:


That's not always correct.

It is always correct.

I have some images that are displayed with <img src="/pv/incer3.php
?z=blackler/1.jpg">, for example. The incer3 file checks a session
variable, and may decide to show the image using readfile(). If you
enter the src url directly, whether you see the image will depend
on the session variables. There is no actual image url to enter.

There is an actual image URL. It is:

http://whatever-your-host-is.example/pv/incer3.php?z=blackler/1.jpg

If I enter that into my browser's address bar directly, it will display
the image.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 3 days, 21:16.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/

 

[Andy Dingley]

It is always correct.

There are still dumb "anti bandwidth blagging" server-side scripts
that will refuse to serve it without seeing an acceptable referer
header (yes, they break if you view the original page without
sending the header).

 

[Toby A Inkster]

There are still dumb "anti bandwidth blagging" server-side scripts that
will refuse to serve it without seeing an acceptable referer header
(yes, they break if you view the original page without sending the
header).

And as per my original post in this thread:

| Using the HTTP "Referer" header, you might be able to kludge together
| a solution, but it will be unreliable and can be easily worked around.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 4 days, 4:34.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/

 

[Sig]

Toby A Inkster said:


That's not always correct.

It is always correct.

I have some images that are displayed with <img src="/pv/incer3.php
?z=blackler/1.jpg">, for example. The incer3 file checks a session
variable, and may decide to show the image using readfile(). If you
enter the src url directly, whether you see the image will depend
on the session variables. There is no actual image url to enter.

There is an actual image URL. It is:

http://whatever-your-host-is.example/pv/incer3.php?z=blackler/1.jpg

If I enter that into my browser's address bar directly, it will display
the image.
[/QUOTE]

You overlooked what I said about the session variable. Perhaps I should have
mentioned that the session variable is set under password control on a previous
page.

 

[Toby A Inkster]

You overlooked what I said about the session variable. Perhaps I should
have mentioned that the session variable is set under password control
on a previous page.

No, I did not. The session variable is simply a cookie as far as my
browser is concerned.

If I've acquired this cookie -- and we can assume that I have, given that
I've seen the image via an <img> tag (that's the entire premise of this
thread) -- then my browser can (and by default will!) send the cookie when
making a direct request for the image.

--
Toby A Inkster BSc (Hons) ARCS
[Geek of HTML/SQL/Perl/PHP/Python/Apache/Linux]
[OS: Linux 2.6.17.14-mm-desktop-9mdvsmp, up 4 days, 21:24.]

Sharing Music with Apple iTunes
http://tobyinkster.co.uk/blog/2007/11/28/itunes-sharing/

 

[Sig]

You overlooked what I said about the session variable. Perhaps I should
have mentioned that the session variable is set under password control
on a previous page.

No, I did not. The session variable is simply a cookie as far as my
browser is concerned.

If I've acquired this cookie -- and we can assume that I have, given that
I've seen the image via an <img> tag (that's the entire premise of this
thread) -- then my browser can (and by default will!) send the cookie when
making a direct request for the image.[/QUOTE]

OK, I now see that our disagreement is philosophical rather than technical. If
we hold the world constant (including session variables) you are correct. If we
want a way to hide an image from unauthorized viewers, then I am correct.

I don't say I solved the OP's problem, he did say

To put
it another way, is there a method to allow an HTML script in the document
root to see and image (or file or whatever) and still prevent access to
that resource?

I think my approach does that. He said nothing about holding the world
constant, and I assumed it was unauthorized viewers he wanted to prevent.