Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > HTML > Confusion on HTML visibility

Reply
Thread Tools

Confusion on HTML visibility

 
 
jw88574@hooya.com
Guest
Posts: n/a
 
      12-18-2007
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
 
Reply With Quote
 
 
 
 
Bone Ur
Guest
Posts: n/a
 
      12-19-2007
Well bust mah britches and call me cheeky, on Tue, 18 Dec 2007 16:33:55
GMT http://www.velocityreviews.com/forums/(E-Mail 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?

--
Bone Ur
Cavemen have formidable pheromones.
 
Reply With Quote
 
 
 
 
Toby A Inkster
Guest
Posts: n/a
 
      12-20-2007
(E-Mail Removed) wrote:

> 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/1...tunes-sharing/
 
Reply With Quote
 
Sig
Guest
Posts: n/a
 
      12-31-2007
On Thu, 20 Dec 2007 12:28:31 +0000 Toby A Inkster said
> (E-Mail Removed) wrote:
>
> > 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.
>
>


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.

--
Sig
http://koiclubsandiego.org/comment/?r=8
 
Reply With Quote
 
Toby A Inkster
Guest
Posts: n/a
 
      01-03-2008
Sig wrote:
> Toby A Inkster said:
>
>> Any image that can be seen using <img> can be seen by accessing the
>> image's URL directly.

>
> 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...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/1...tunes-sharing/
 
Reply With Quote
 
Andy Dingley
Guest
Posts: n/a
 
      01-03-2008
On 3 Jan, 10:05, Toby A Inkster <(E-Mail Removed)>
wrote:
> Sig wrote:
> > Toby A Inkster said:

>
> >> Any image that can be seen using <img> can be seen by accessing the
> >> image's URL directly.

>
> > That's not always correct.

>
> 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).
 
Reply With Quote
 
Toby A Inkster
Guest
Posts: n/a
 
      01-03-2008
Andy Dingley wrote:

> 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/1...tunes-sharing/
 
Reply With Quote
 
Sig
Guest
Posts: n/a
 
      01-04-2008
On Thu, 3 Jan 2008 10:05:58 +0000 Toby A Inkster said
> Sig wrote:
> > Toby A Inkster said:
> >
> >> Any image that can be seen using <img> can be seen by accessing the
> >> image's URL directly.

> >
> > 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...blackler/1.jpg
>
> If I enter that into my browser's address bar directly, it will display
> the image.
>
>


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.
--
http://koiclubsandiego.org/comment/?r=8
 
Reply With Quote
 
Toby A Inkster
Guest
Posts: n/a
 
      01-04-2008
Sig wrote:

> 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/1...tunes-sharing/
 
Reply With Quote
 
Sig
Guest
Posts: n/a
 
      01-05-2008
On Fri, 4 Jan 2008 10:14:25 +0000 Toby A Inkster said
> Sig wrote:
>
> > 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.


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.

--
http://koiclubsandiego.org/comment/?r=8
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Confusion about control name visibility in code Lloyd Sheen ASP .Net 0 02-13-2008 08:04 PM
HTML parsing confusion Alnilam Python 15 01-23-2008 09:14 PM
Single quote confusion in javascript generated HTML Al Henderson Javascript 3 01-23-2008 12:59 PM
confusion trying to get IMG tags from html page pkellner Ruby 6 07-30-2005 12:29 PM
Visibility on postback of dynamically-created HTML controls Marcus ASP .Net 1 07-20-2005 11:09 PM



Advertisments