SitePoint Sponsor

User Tag List

Results 1 to 16 of 16
  1. #1
    SitePoint Guru
    Join Date
    Jan 2010
    Posts
    635
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    Are There Any Files That Can Not Be Accessed By Browsers?

    Sitepoint Members,
    You know how browsers can easily be, and usually are, locked out of a website's folders? Are there any file types that can not be accessed from a browser or can't be accessed from a browser if a certain permission (e.g 444) is used? If not, how about if you make up a file typ, like .xyz?

    Thanks,

    Chris

  2. #2
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    A browser does not dictate what can and cannot be accessed. That is the web server itself.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  3. #3
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,276
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    In Unix you can use whatever extension name you want. Usually the server offers a file with a MIME type, and for example on Linux many programs will attempt to choose who can best open that file based on MIME type. I haven't figured out how to do it yet but you can also assign a file an "incorrect" MIME type... so in this case, if you wanted, you could assign a MIME type you know browsers do not know how to deal with. However I remember someone saying a UA will try to default to text/plain (or maybe that was the server?) in an act of desperation, so your file had better not have text or something will be readable :)

    For example I was on a site where they gave images (jpegs) a text/html MIME type. My browsers defaulted to text/plain when I tried to open it, showing me random bits of EXIF data (with the words Photoshop in it) and those gobbley characters you see when you open binaries in text editors. I assume they did this to prevent copying? But it was easily viewed because browsers think they know what text/html was, so they showed the image just fine : )

    (of course now that I'm looking for it, I can't find it)

  4. #4
    SitePoint Guru
    Join Date
    Jan 2010
    Posts
    635
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I wish there file types that operate like folders as far as access.

  5. #5
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,810
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    It is more a matter of what file types that the browser understands. If the browser understands the file type either natively or via a plugin then it can display the file in the browser. If the browser doesn't understand the file type then it offers the file for download (eg. XHTML files in IE8 or PDFs where an appropriate plugin is not installed).

    To actually prevent access to the files from the browser completely the file has to be outside of the web accessible area on the server or in a password protected folder within that area but where there are no valid passwords defined.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  6. #6
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,798
    Mentioned
    34 Post(s)
    Tagged
    2 Thread(s)
    Actually the issue is the URL.

    If you have a URL to a specific file ( regardless of type) the browser will load it into memory. I say load .. because the browser will attempt to open and render it. Depending on the file type, what plug in you have, your preferences, the browser may actually just D/L. What I am saying is, if you have a URL the browser will point to it , EVEN if you secure a directory.

    so... http://mySite.com/secureFolder .. may give you an access forbidden error if you set that folders preference
    http://mySite.com/secureFolder/incriminating.jpg, or http://mySite.com/secureFolder/incriminating.php will open on the browser
    http://mySite.com/secureFolder/incriminating.zip will (ask to) download


    if your file is RENDERABLE (opened on the browser) dynamic: http://mySite.com/secureFolder/incriminating.php you could have it check something to see if the user has privileges... so dynamic files can in that sense be protected.

  7. #7
    SitePoint Guru
    Join Date
    Jan 2010
    Posts
    635
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Felgall,
    When you say
    " outside of the web accessible area on the server or in a password protected folder within that area but where there are no valid passwords defined. "
    If you have that line option indexes in your htaccess does that help matters - I really didn't think folders were accessible to a browser, regardless of password protection.

    Dresden_phoenix,
    It doesn't look like a dynamic file will help me, because the view source will probably show its contents.

    I was hoping to find a way to keep the location of an image file unknown by sticking it in an inaccessible php or other file type file. I gues it won't work.

    Thanks to both of you for the help.

  8. #8
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,798
    Mentioned
    34 Post(s)
    Tagged
    2 Thread(s)
    It doesn't look like a dynamic file will help me, because the view source will probably show its contents.
    #1 a dynamic file is a file that is used by a server to generate the file that is sent to the browser.. it is NEVER directly viewable by the user
    #2 view source only shows the HTML of an html document.
    #3 view source never shows:
    * stuff that's generated via .js ( tho it may show the .js or at least the link to the .js)
    * the source of the stuff that's generated server side ( via PHP, ASP, NET, etc.). So what i was saying is if your file is dynamic in this way you could have it redirect somewhere else if certain credentials aren't met , for example if a session variable doesn't confirm.. redirect to some other page that says "bad hacker! no cookie!".


    I was hoping to find a way to keep the location of an image file unknown by sticking it in an inaccessible php or other file type file.
    there in lies the problem.. its the URL you are trying to hide... not the file and it's the url that has unrestricted access. You cant have have your cake and eat it. If you want someone to see the file , they WILL be able to see the location. Heck even if you could the data itself is temporarily stored in the browser cache; that is someone an just root through their own system after they have viewed the image, find their UA's Cache and root through that and find the image they just saw... all of them! If you don't want the location seen you cant show them the image. It's kinda evil to want it both ways.


    If you are worried about copyright. A simple solution ... Watermark your image.


    OK, in my typical manner now that I have expressed my objection I can also suggest this, but it will be RESOURCE INTENSIVE FOR YOUR SERVER!!

    create a "cache" folder.
    create a function ( because we like DRY code ) that you call any time you are about to output an image
    this function would create a random string , append the same suffix as the image.
    it now makes a copy of the image , renamed with that string I just mentioned, and puts it in the cache folder.
    the src/link points to that cached image.
    after the page has been served, another function empties the cache folder

    In short image URIs are temporary, for one serve only


    Other reasons why this is horrible:
    You will be asking your server work on creating, renaming and hiding images per page, per serve !!!
    Your visitors will have to re download images each page load ( since the URI will always be different the browser will assume is a different image)
    but if its that important that no one hotlinks, then I guess it's THAT important

  9. #9
    SitePoint Guru
    Join Date
    Jan 2010
    Posts
    635
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Thanks Dresden!

  10. #10
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,276
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Would just telling your server
    "requests for files ending in XXXX-extension, return 403"
    work?

    There are the usual server-side checks for referrers to prevent hotlinking (if the referrer isn't your own domain, image 403). I was going to point to the Sitepoint how-to, but it seems to have been removed.

  11. #11
    SitePoint Guru
    Join Date
    Jan 2010
    Posts
    635
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Stomme Poes,
    That's an idea. I'll have to look into that. I have lines in my htaccess to keep google and others off certain pages, I could do it for all to stay out of certian jpg files and other files I only want accessed internally (to create the site).

    <Files .htaccess>
    deny from all
    </Files>
    <Files xyz.html|thanks.html>
    Order Deny,Allow
    Allow from all
    Deny from msnbot msnbot-media googlebot
    </Files>

    But if I remember, deny from all will block robots and non robot visitors. There are three types of users of a file, robots, regular visotrs and the server. Deny from all I think will stop the server from serving the file. There doesn't seem to be a way to stop a visitor withoiut also blocking the server - I think that's the heart of the problem.

    Thanks,

    Chris

  12. #12
    Non-Member
    Join Date
    Sep 2012
    Location
    Sweden
    Posts
    35
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    On *nix systems if you just change permission to file/folder to 000 in Public Permissions, that won't be available to access. Any folder located upper then public_html also not accessible by browser (on a shared cPanel hosting).

  13. #13
    SitePoint Guru
    Join Date
    Jan 2010
    Posts
    635
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I put
    <files .jpg>
    deny from all
    </files>
    in my htaccess to see what would happen and nothing happened at all. I saw Fellgal writing for Bluehost using an asterik before the dot in .jpg and that blocked all access to my jpgs, so does <files .jpg> (no asterik) do anything, especially siince I have in my htacess

    <files .htaccess>
    deny from all
    </files>

    thinking it's making my htacess more secure.

  14. #14
    SitePoint Guru
    Join Date
    Jan 2010
    Posts
    635
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    "and nothing happened at all." meanns I could view .jpg files directlt with a browser.

  15. #15
    Non-Member
    Join Date
    Sep 2012
    Location
    Sweden
    Posts
    35
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    if you'd have file named just ".jpg" , your rule could block accessing that, just like as with .htaccess , but if you want to block for example MyImage.jpg , you've to use
    <files MyImage.jpg>
    deny from all
    </files>

    or to block all jpg files :

    <files *.jpg>
    deny from all
    </files>

  16. #16
    SitePoint Guru
    Join Date
    Jan 2010
    Posts
    635
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I see now.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •