SitePoint Sponsor

User Tag List

Results 1 to 16 of 16

Hybrid View

  1. #1
    SitePoint Enthusiast jaked409's Avatar
    Join Date
    Jan 2007
    Posts
    61
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Reliable ways of checking referrers?

    In order to prevent people from submitting data to our forms from some other site, we'd like to check the referrer and see if the request came from our site or not.

    Unfortunately, I understand that $_SERVER['HTTP_REFERER'] is not reliable; it can be modified easily by any user who knows what they're doing. Therefore, I was wondering if there's a more reliable method for this? And if not, is there a well-known method of achieving the same results (preventing people from submitting data from their own pages and decoying them as one of ours)?
    jakeboxer.com (my portfolio)

  2. #2
    SitePoint Zealot
    Join Date
    Jun 2007
    Location
    Regina, SK, Canada
    Posts
    129
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  3. #3
    SitePoint Enthusiast jaked409's Avatar
    Join Date
    Jan 2007
    Posts
    61
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Right, I'm aware of the problem. I'm asking if there's a good solution.
    jakeboxer.com (my portfolio)

  4. #4
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    The better way is to use a session. Creating a session and passing a session variable between pages allows you to confirm that the person has preformed prior actions on the same web site (rather than somewhere else or not at all).
    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="^$">

  5. #5
    SitePoint Enthusiast jaked409's Avatar
    Join Date
    Jan 2007
    Posts
    61
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Sounds okay. However, what prevents someone from logging in (so they have a session) and THEN using a page they created to submit data?
    jakeboxer.com (my portfolio)

  6. #6
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    People don't need to log in to get a session - they need to be on a page of your site where the session is accessible. If they go to some page not on your site then they will not have access to the session until they return to a page on your site.

    Sessions are similar to cookies except that the data that they track is stored on your site instead of in a cookie. The session id itself is stored in a cookie except when cookies are disabled in which case it may be saved in the querystring on the end of the address in the address bar. Since cookies set from your site are only available from your site the session will only be accessible from pages on your site. When it is passed in the address the session is lost as soon as a page is reached that is not on the same site with the session defined in the page.
    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="^$">

  7. #7
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    Plano
    Posts
    643
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    you can track referrers in this way using sessions (tho it's not really "referrers" as much as it is "last page visited"):

    when you load a page, set a session variable (let's say current_page) to the current page. on the next page load (whichever it may be), check the current_page value in the session and move it to a another session variable (let's say referrer), and once again change the current_page variable to the current page.

    this way you always know the last page they visited. also you can track the very last page the visited before they left your site, so you can see what pages people are leaving your site at.

    lemme know if there's some confusion, i can provide a short excerpt of code.

  8. #8
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Using session values will work most of the time, you can use a unique token that is generated and only good for a certain length of time.

    Captcha systems are also effective at preventing automatic submissions. People don't like them, but they work. If you don't want an image captcha there are ASCII art based captcha systems that are about as effective as you can get.

    There are quite a few things that can be simulated (like hidden fields), if someone wants to put together a bot to hit your form. There are unfortunately no really good solutions.

  9. #9
    SitePoint Enthusiast jaked409's Avatar
    Join Date
    Jan 2007
    Posts
    61
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm experienced with PHP, but I have very little with sessions. If someone could explain one of these methods in a bit more detail, it would be really helpful to me.

    The way I understand it, a set of session variables are stored on the server for each user (who has had a session set for them). A cookie is set on the users computer that the server looks at to determine which set of session variables to use (the whole valet ticket metaphor). The various suggestions I've heard all involve checking session variables.

    How could setting certain session variables prevent someone from submitting data from a page they created as if they were submitting it from one of my pages? I assume it's fairly easy to spoof the web server into thinking that the request came from a browser with the right cookie for the session, so I'm confused as to how it could prevent such a decoy.
    jakeboxer.com (my portfolio)

  10. #10
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The session id doesn't last past a certain time or past the closure of the browser window by the user. Your application generates a unique token, when the form is requested, which is stored in both a hidden field in the form and in the session. If the tokens match upon submission, then you allow it, if they don't then reject it. It isn't foolproof in fact nothing is, but it is one measure to take in combination with others such as captcha images. IP banning is another thing to try.

    It would be nice to be able to rely on the referrer for these things, but you really can't trust anything from the outside and unfortunately information about where someone has been on the web is and can be used to violate their privacy or for questionable marketing purposes. Just take the best measures you can find, but don't worry too much about it.

  11. #11
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Cookies are site specific. If your site sets a cookie then only pages on your site can access it at all. Sessions are therefore limited to being accessed from pages that are on the same site. Unless you provide a way for someone to upload a page containing a form onto your site then there is no way that that form can set the necessary session variable to be read by the form processor as if the page is not on your site it does not have access to the session.
    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="^$">

  12. #12
    SitePoint Enthusiast jaked409's Avatar
    Join Date
    Jan 2007
    Posts
    61
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    Cookies are site specific. If your site sets a cookie then only pages on your site can access it at all. Sessions are therefore limited to being accessed from pages that are on the same site. Unless you provide a way for someone to upload a page containing a form onto your site then there is no way that that form can set the necessary session variable to be read by the form processor as if the page is not on your site it does not have access to the session.
    The key part for me here is, "If your site sets a cookie, then only pages on your site can access it at all." Is this reliable, or is it fairly easy to spoof if the person knows their PHP? If it's reliable, then I understand; you can set a session variable, and not worry about off-site pages being able to access it. If all it takes is some header or browser magic (similar to screwing with the referrer), then it's back to square one. Can anyone answer this for me?
    jakeboxer.com (my portfolio)

  13. #13
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by jaked409 View Post
    The key part for me here is, "If your site sets a cookie, then only pages on your site can access it at all." Is this reliable, or is it fairly easy to spoof if the person knows their PHP? If it's reliable, then I understand; you can set a session variable, and not worry about off-site pages being able to access it. If all it takes is some header or browser magic (similar to screwing with the referrer), then it's back to square one. Can anyone answer this for me?

    Cookies are domain specific. If there were any way at all for other domains to access cookies not set by them then the security hole created would be so large that the internet would become unusable.
    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="^$">

  14. #14
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Cookies are not completely secure. Cookie data is transmitted via HTTP, so yes the traffic can be sniffed. An XSS attack or other javascript related attack can steal cookie data.

    A session can be highjacked if the session id/cookie can be sniffed or captured in some other way. If the session data is stored in a common directory on shared hosting, such as "tmp" then an attacker can access it if they have an account on the same machine as this directory is world writable. Take security measures that are appropriate for what you have to protect.

  15. #15
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,875
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    To protect their privacy many web users have the referrer header turned off either in their browser or firewall so that you get a blank value instead of whatever page they came from even if it was from your site. Using a session can provide the same information internally to your site without the user having the ability to change it and allows you to easily distinguish links from elsewhere as they will not have the 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="^$">

  16. #16
    SitePoint Addict
    Join Date
    Aug 2007
    Location
    GR
    Posts
    352
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    For e-mail forms you can limit only one submit by logging the IP.
    Other way would be with mod_rewrite, but I'm not sure if this can be forged too.


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
  •