SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 54
  1. #26
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,809
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    The referring domain is a user enterable field so anyone wanting to directly access the file directly will just set the referrer to the value that you expect before they make the call.

    Setting a session within your page is the only way to ensure that a file is only accessible from that page since only that page has the right session set.
    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="^$">

  2. #27
    SitePoint Enthusiast
    Join Date
    Nov 2007
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Of course, the referring domain check could just be one of the several checks. It would at least keep 99% of users who don't know how to enter that variable from accessing it directly or from external links.

    However, it doesn't matter anyway if one person could change this variable on their single browser. This person would have to intentionally do this. But what more would they gain since they could just access it through the site anyway? So actually being able to change the referrer variable on the browser is irrelevant in this case. They can only do it for "their" browser, which does not affect anybody else. And again, they'd gain nothing by changing this variable.
    My website: www.sitehatchery.com

    Recent Article: Dynamic CSS

  3. #28
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sitehatchery View Post
    ...However, it doesn't matter anyway if one person could change this variable on their single browser. This person would have to intentionally do this...
    A lot of security software like Norton or Mcafee either strip away HTTP Referer or replace it. That requires zero user intervention. Using HTTP Referer is not going to work. Even proxy servers a lot of users use to hide there true identity and history mess with the HTTP Referer header.

    A blank HTTP Referer header must also be accepted because if the user directly enters the address or uses a bookmark there is no HTTP Referer header sent. And again a lot of software strips it away. Second why is the user blocked because they came to your site from another like Google? That just seems insane.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  4. #29
    SitePoint Enthusiast
    Join Date
    Nov 2007
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmm... first time I've heard about Norton and Mcaffe doing this. Sounds like something a virus would do. That's also the first I've heard that obscuring the identity changes the HTTP Referer header. Do you have any references or have you done any tests? I'm not being facetious - I'm really interested in knowing the research on this.
    My website: www.sitehatchery.com

    Recent Article: Dynamic CSS

  5. #30
    SitePoint Enthusiast
    Join Date
    Nov 2007
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    When I clear my history, it doesn't affect the referrer at all.
    My website: www.sitehatchery.com

    Recent Article: Dynamic CSS

  6. #31
    SitePoint Wizard TheRedDevil's Avatar
    Join Date
    Sep 2004
    Location
    Norway
    Posts
    1,196
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sitehatchery View Post
    Hmm... first time I've heard about Norton and Mcaffe doing this. Sounds like something a virus would do. That's also the first I've heard that obscuring the identity changes the HTTP Referer header. Do you have any references or have you done any tests? I'm not being facetious - I'm really interested in knowing the research on this.
    Check Google, for more information. This is a well known fact and if you ask a professional programmer that work with webpages about the Refer header, they will say the same.

    You can also read up on the HTTP header specs for more information.

  7. #32
    SitePoint Enthusiast
    Join Date
    Nov 2007
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So in other words, you don't personally know - you just heard it somewhere.
    My website: www.sitehatchery.com

    Recent Article: Dynamic CSS

  8. #33
    SitePoint Enthusiast
    Join Date
    Nov 2007
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I apologize for that last remark. Yes, you can disable referrers and Norton will as well unless you change the security settings.
    My website: www.sitehatchery.com

    Recent Article: Dynamic CSS

  9. #34
    SitePoint Enthusiast
    Join Date
    Nov 2007
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmm... sessions. That brings me to another thought. You can disable cookies too which in this case would render the exact behavior as if you were testing for referrers and they were disabled.
    My website: www.sitehatchery.com

    Recent Article: Dynamic CSS

  10. #35
    SitePoint Enthusiast
    Join Date
    Nov 2007
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Alright, I hate to submit 4 in a row, but this is a challenge for me. The only thing I don't know what to do with is the case where they have both cookies and referrers disabled. Maybe in that case, I could compare database logs of ip addresses and times. That would get big fast, so there would have to be some sort of automatic cleanup. But here's what I came up with so far:

    Code:
    session_start();
    
    function check_referrer(){
            $referring=parse_url($_SERVER['HTTP_REFERER']);
    	
            //either directly typed or refererrs disabled
    	if(!$referring['host']){
    		//Referring host doesn't exist, so check for existing session
    		if($_COOKIE['lala']==sha1('$LL...//')){
    			//means they've been on this site recently even though the referrer isn't present
    			return "all is well";
    		} else {
    			//means they haven't been on the site, or they have both refererrs and cookies disabled
    			return "How do I get around this?";
    		}
    	} else if($referring['host']==$_SERVER['HTTP_HOST']){
    	
    	   return "all is well";
    	
    	} else{ 
    		
    	   return "all is not well";
    	}
    }
    
    echo check_referrer();
    My website: www.sitehatchery.com

    Recent Article: Dynamic CSS

  11. #36
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Or you can just forget about trying to protect from direct access... As long as the browser can download the file it will be possible to get the file. Unless you actually have a big problem of users taking all your files and reposting them or whatever. I wouldn't bother worrying about a non issue until it becomes and issue.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  12. #37
    SitePoint Enthusiast
    Join Date
    Aug 2008
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OK this discussion took a lively turn. The more I think about it, I find myself in the "I know anything on the net can be downloaded, but let's not make it simple for those who want to steal my content". So, with that said, here's what I'm thinking:

    1. caller.php loaded with request for song1.php
    2. caller.php sets session variable encrypted with known $key with value=song1.mp3 filename
    3. caller.php immediately calls get.php (without any parameters)
    4. get.php decrypts session variable with known $key and obtains filename song1.mp3
    5. get.php DELETES session variable and streams song1.mp3

    This should work in most cases:
    1. Direct call to get.php will result in no file since session not set
    2. Call to get.php after it is called by caller.php will result in no file since get.php deleted the session variable when called the first time
    3. mp3 files are stored above webroot so figuring out their location is still not publicly accessible

    This breaks if:
    1. caller.php is loaded and for some reason get.php is not called. In this scenario, session variable is set, and a direct call to get.php (from browser address bar) will start streaming file. I can get around this by forcing an autostart on the flash player so that get.php is called as soon as caller.php gets loaded.

    Now I just need to make this work with playlists...i.e., after song1 is played, get.php needs to play song2.mp3 but it won't since get.php deleted the session after the first song was played.

    Still trying to figure it out....does the algorithm above make sense?

  13. #38
    SitePoint Wizard
    Join Date
    Mar 2008
    Posts
    1,149
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Don't use the referrer. A lot of internet security packages block the sending of referrers the instant you install the software.

    Making the player autostart won't make it much harder. In my case, I just right click a tab in Firefox and disable plugins for that tab. Then I view the page's source and download the file. In fact, I did that just a week ago on one particular site, and it was very obvious that the link failed after one request. You can say that this requires too much technical knowledge for the casual user, but viewing the source code of a page is already fairly too advanced.

    However, there is one thing that you can do to make it a bit harder. You can pass a string or two to your Flash music player, and in the player, a new string will be generated that would be passed to get.php to get the file. Doing that will force the user to invoke the Flash player. (Although decompiling a Flash movie is very easy. There are also still ways to get the file while still invoking the Flash player.)

  14. #39
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,809
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by sitehatchery View Post
    Hmm... first time I've heard about Norton and Mcaffe doing this. Sounds like something a virus would do. That's also the first I've heard that obscuring the identity changes the HTTP Referer header. Do you have any references or have you done any tests? I'm not being facetious - I'm really interested in knowing the research on this.
    All decent security software blanks out the referrer header - it is one of the ways that the security software protects the PRIVACY of the software's owner. It is the exact opposite of something a virus would do since viruses attack the software owner while blanking out the header protects them.

    That blanking out the header stuffs up the security on your web site is irrelevant because their security software is working for them and not for you and you're trying to detect where they came from is the suspect activity that the software is protecting against.
    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="^$">

  15. #40
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,809
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by sitehatchery View Post
    Hmm... sessions. That brings me to another thought. You can disable cookies too which in this case would render the exact behavior as if you were testing for referrers and they were disabled.
    Sessions don't have to rely on cookies being enabled. The sessionid can be passed in other ways.
    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="^$">

  16. #41
    SitePoint Enthusiast
    Join Date
    Aug 2008
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sk89q View Post
    Is this what you mean? (No cookies needed.)

    caller.php
    PHP Code:
    <?php
    $file_only 
    basename($_GET['param']);
    $file_only str_replace(" ""_"$file_only);
    // These don't really matter since you're just reading from one folder and you don't check extensions or anything, but I like to do it in case
    $file_only str_replace("\0"""$file_only); // Poison null byte
    $file_only str_replace(":"""$file_only); // NTFS ADS
    // Key
    $shared_key "something";
    $timestamp time();
    $hash hash_func_hmac($file_only"$timestamp-$shared_key");
    $url printf("get.php?param=%s&t=%d&key=%s"urlencode($file_only), $timestamp$hash);
    ?>
    <embed
    src="mediaplayer.swf"
    width="640"
    height="480"
    allowscriptaccess="always"
    allowfullscreen="true"
    autostart="true"
    flashvars="file=<?php echo htmlspecialchars(urlencode($url)) ?>&amp;showstop=true&amp;autostart=true&amp;bufferlength=3"
    />
    get.php
    PHP Code:
    <?php
    $file_only 
    $_GET['param'];
    $shared_key "something";
    $in_hash $_GET['key'];
    $in_timestamp intval($_GET['t']);
    $in_hash $_GET['key'];
    $expected_hash hash_func_hmac($file_only"$in_timestamp-$shared_key");
    if (
    $expected_hash != $in_hash || $in_timestamp time() - 60 15) { // You could do the timestamp check before computing the hash
        
    header("HTTP/1.1 404 Not Found");
        exit;
    }
    // I would still do a security check again
    // And then load the file
    //
    After thinking this through some more, I think sk89q's solution is the best compromise. It ensures calls to get.php will work only if first called from caller.php; even if get.php is called directly it will only work for a set time limit and given anyone can get the file if they really wanted, it's the best balance between coding effort and dissuading the casual visitor.

    Quick question: Even if someone views the caller.php source code and decides to use it on their own evilsite.com, the links will really just work for the time limit in the original code right? Since the source code won't show the hash being used, stealing the "view source" code on caller.php will be useless...?

    Thanks again for the help.

  17. #42
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    They will see the hash, but the point is the hash will only be valid for a short period of time. Without knowing the secret salt key, they won't be able to generate thier own valid hash(very advanced user might be able to crack it given enough time and samples).

    They can still screen scrape the hash though. But, they would need to fetch a new hash every so often because each hash is only valid for a finite time.

  18. #43
    SitePoint Enthusiast
    Join Date
    Aug 2008
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hmmm, doesn't this present another problem...

    What about evilsite.com that has a link to "Song 1" pointing to mysite.com/caller.php?param=song1.mp3? Won't that just open up caller.php, have it do all the hash and key work to pass to get.php which will just stream the song?

    Will a simple hyperlink from another site to mysite.com/caller.php break this whole "protection"?

  19. #44
    SitePoint Wizard
    Join Date
    Mar 2008
    Posts
    1,149
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If the other person puts your website in a frame, then the song would play. Frame busting code could be used to prevent that. They cannot use a direct link to get.php, however, unless they have the hash. To get that hash, they would have to load caller.php on *their* server, because you can't just read the content of another page via JavaScript.

  20. #45
    SitePoint Enthusiast
    Join Date
    Aug 2008
    Posts
    31
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What if evilsite.com has the following link pointing to mysite.com/caller.php?

    Code:
    <A HREF="javascript:void(0)"
    onclick="window.open('http://mysite.com/caller.php?song1.mp3','evilsite player')">Listen to SONG 1 here</A>
    They will be able to have links to songs on their site calling my caller.php directly and playing songs...?

  21. #46
    SitePoint Wizard
    Join Date
    Mar 2008
    Posts
    1,149
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes?

    I could just tell my friend verbally the URL, and s/he could just listen to it as well?

  22. #47
    SitePoint Guru
    Join Date
    Oct 2006
    Location
    Queensland, Australia
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Does the original poster even know what they're trying to prevent exactly? What is the end goal of this? Is it to prevent people from stealing your bandwidth by direct linking, or what?

  23. #48
    SitePoint Addict
    Join Date
    Nov 2005
    Location
    Moss, Norway.
    Posts
    283
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A class with private / protected properties and setter / getter methods immediately come to my mind.

    Only the public methods are visible outside the class (hierarchy).

    What privileges do the folder have: http://catcode.com/teachmod/

    May be you have to change file permissions with a FTP program like http://www.smartftp.com/ .

    Then you can use a class method to access the file from where you want.

  24. #49
    SitePoint Addict
    Join Date
    Nov 2005
    Location
    Moss, Norway.
    Posts
    283
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    And:

    If you can use PHP note that the chmod function can only be used if you have the permission to do it in that folder.

  25. #50
    SitePoint Zealot jimmy85's Avatar
    Join Date
    Aug 2009
    Posts
    174
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A pretty interesting discussion here. Yeah I believe once you've posted it on the net, anyone determined to take something can and will do it.

    Maybe the OP doesn't want anyone directly linking or others sites consuming his own bandwidth, or perhaps crawlers?

    Yeah put in everything, sessions, hashes with time limit. Just to make it harder. Thought of using captchas too? So it can't be botted easily.


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
  •