What's the best method to validate the Referer header and make sure header isn't being manipulated?

Would this work or will that still leaving me open?

$safeHOST = array('dev.abc123.com', 'prod.abc123.com');
$getHOST = $_SERVER['HTTP_HOST'];
$checkHOST = (!in_array($getHOST, $safeHOST)) ? false : true;

if(isset($checkHOST) && $checkHOST == false){
  echo 'bad header request';
}
else{
  echo 'good header request';
}

I appreciate any feedback. Thanks.

    $checkHOST = (!in_array($getHOST, $safeHOST)) ? false : true;

    You could just write

    $checkHOST = in_array($getHOST, $safeHOST);
    jeepin81 wrote:

    What's the best method to validate the Referer header and make sure header isn't being manipulated?

    That header is user-supplied data and as such it's just as trustworthy as any other user-supplied data. They may decline to send it at all.

    Incidentally, if you are going to check the referrer header, it would probably be a good idea to check the HTTP_REFERER header instead of the HTTP_HOST header.

    jeepin81 wrote:

    Would this work or will that still leaving me open?

    The question is meaningless if you don't say what you're worried it's leaving you open to.

      I am little confused myself asking the question. We had a 3rd party company do a pen. test on a new site and on their report they had this line in regard to our login page:

      Risk:
      • It may be possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user
      Causes:
      • Insufficient authentication method was used by the application
      Fix:
      Validate the value of the "Referer" header, and use a one-time-nonce for each submitted form
      Difference:
      Header manipulated from: https://dev.abc123.com/login.php to: http://bogus.referer.ibm.com

      I added nonce to the login app but I wasn't 100% on the referer. Maybe a reference to CSFR attack. The company that produced this report is closed for the holidays.. so I am just trying to move forward with what they wrote.

        5 days later

        Probably they're asking you to attempt to ensure that any POST input to your login handles actually comes from your login form. So HTTP_REFERER should contain the URL of your login form, and if it doesn't, you could tell the user to come back when they have a browser that is ready to play nice....

          Weedpacket;11052947 wrote:

          That header is user-supplied data and as such it's just as trustworthy as any other user-supplied data. They may decline to send it at all.

          What weedpacket means to suggest is that this value is (optionally) supplied by the user themselves as part of their page request -- it comes directly from the user! They could supply anything they want including nothing at all. In my opinion, checking it will provide little real security, but it may have the practical effect of introducing one more hurdle to bad guys who are screwing around.

          dalecosp wrote:

          So HTTP_REFERER should contain the URL of your login form, and if it doesn't, you could tell the user to come back when they have a browser that is ready to play nice....

          Dalecosp indirectly points out that a user's browser may not "play nice." I think most reputable browsers will take care to supply a correct HTTP_REFERRER value, but there's always a chance some clown will have some weird or ancient browser that fails to play nice.

          As for the recommendations:

          Risk:
          • It may be possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate user, allowing the hacker to view or alter user records, and to perform transactions as that user
          Causes:
          • Insufficient authentication method was used by the application
          Fix:
          Validate the value of the "Referer" header, and use a one-time-nonce for each submitted form
          Difference:
          Header manipulated from: https://dev.abc123.com/login.php to: http://bogus.referer.ibm.com

          This does seem like a pragmatic recommendation. They suggest that you:
          Prevent CSRF attacks by displaying a nonce or some one-time token in the form which is submitted with the form and can only be validated by your server -- this typically involves storing some value in session. The basic idea is that this token is generated by your site and can ONLY be validated by your site to prevent some a-hole spoofing your login page and tricking users into entering their login credentials.
           Check the HTTP_REFERER supplied with the request because most legitimate users should be using a well-behaved, modern browser that will honestly report this HTTP_REFERER value. This should effectively limit the exposure of your users to sneaky hacks.

            Write a Reply...