Confusion on HTML visibility

Discussion in 'HTML' started by jw88574@hooya.com, Dec 18, 2007.

  1. Guest

    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
     
    , Dec 18, 2007
    #1
    1. Advertising

  2. Bone Ur Guest

    Well bust mah britches and call me cheeky, on Tue, 18 Dec 2007 16:33:55
    GMT 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.
     
    Bone Ur, Dec 19, 2007
    #2
    1. Advertising

  3. 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/11/28/itunes-sharing/
     
    Toby A Inkster, Dec 20, 2007
    #3
  4. Sig Guest

    On Thu, 20 Dec 2007 12:28:31 +0000 Toby A Inkster said
    > 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
     
    Sig, Dec 31, 2007
    #4
  5. 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/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/
     
    Toby A Inkster, Jan 3, 2008
    #5
  6. Andy Dingley Guest

    On 3 Jan, 10:05, Toby A Inkster <>
    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).
     
    Andy Dingley, Jan 3, 2008
    #6
  7. 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/11/28/itunes-sharing/
     
    Toby A Inkster, Jan 3, 2008
    #7
  8. Sig Guest

    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/pv/incer3.php?z=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
     
    Sig, Jan 4, 2008
    #8
  9. 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/11/28/itunes-sharing/
     
    Toby A Inkster, Jan 4, 2008
    #9
  10. Sig Guest

    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
     
    Sig, Jan 5, 2008
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marcus
    Replies:
    1
    Views:
    1,182
    Cathal Connolly [C# MVP]
    Jul 21, 2005
  2. Alnilam

    HTML parsing confusion

    Alnilam, Jan 22, 2008, in forum: Python
    Replies:
    15
    Views:
    608
    Gabriel Genellina
    Jan 23, 2008
  3. Lloyd Sheen
    Replies:
    0
    Views:
    319
    Lloyd Sheen
    Feb 13, 2008
  4. pkellner
    Replies:
    6
    Views:
    183
    William James
    Jul 30, 2005
  5. Al Henderson
    Replies:
    3
    Views:
    220
    Al Henderson
    Jan 23, 2008
Loading...

Share This Page