How to improve a file access permission/deny function?

Question

I've quickly made a function to deny or allow access to files that are only used thru Ajax Calls.

Key Generator

/**
 * Generate a key for file access permission
 * 
 * Function that returns a key to grant access to a PHP file
 * that will be consulted by an ajax call.
 * 
 * @param str $salt Any given string to append to the session ID
 * 
 * @return str Access Key
 */
public function file_access_key_generator($salt) {

    return sha1(session_id() . $salt);

}

Key Validation

/**
 * Match file access permission key
 * 
 * Function to match the given key with the one generated.
 * 
 * @param str $salt Any given string to append to the session ID
 * @param str $key  Key to match
 * 
 * @return bollean
 */
public function file_access_key_check($salt, $key) {

    return ($this->file_access_key_generator($salt) == $key) ? true : false;

} 

The goal, as mentioned, is to prevent direct access to files that should only be accessed thru an Ajax Call within the application.

The methodology implemented is as follows:

// Generate the key to pass with the Ajax Post variables
$check = $this->my_class->file_access_key_generator(basename(__FILE__, '.php'));


// Validating the key
if (isset($_POST['check']) && 
    $my_class->file_access_key_check(basename(__FILE__, '.php'), $_POST['check'])) {
     // do stuff...
} else {
     // friendly user message stating that the access to the file isn't autorized
}

Essentially, what is being done is to generate a key combining the file name and the session ID. Both must match otherwise the access isn't allowed.

Question:

Does this secures the access to the file or some considerations are to be made in order to actually secure the file that receives Ajax calls, thus preventing a direct browser access or the file being included within another one?

Answer 1

Short version:

1. You may trust your own PHP code, if you write it well.
2. You should not trust data received by cookies, $_GET or $_POST.
3. Attempting to distinguish data sent from your JavaScript application from malicious input relies on methods that are both hard and easily bypassed.

Long version:

First of all, do you really need the ? true : false? The == operator already returns a boolean.

Forbidding direct access is a complex (impossible?) task. The user might just watch the web traffic you send your own Ajax application, and then imitate the output your app would send.

Even if you could prevent that, it'd probably still be pointless - the user could just edit the JavaScript code in many ways (so many in fact that it's probably worthless to try to detect them) so the application would be manipulated into doing what the "attacker" wants.

If you are not concerned about the current application user but rather protecting your user against third parties, then using HTTPS might be the best option. Why re-implement what's already available and designed by people who are - let's face it - smarter than both of us combined (and with the added advantage that it's been around for some time, so its flaws have already had more time to be detected and fixed!)

At some point you are using __FILE__ to detect if the code is authorized? Does this mean the attacker can directly execute PHP code on your server? If not, then your __FILE__ check is worthless. If so, then your __FILE__ check is still worthless, as the attacker can just directly call the file functions bypassing your whole security system.

Remember this:

1. Users can manipulate all sent data. Cookies, $_GET and $_POST data can all be manipulated by the user.
2. All data you send your client-side application can be inspected by the user. See Firebug for a good example. If you send some_hash to the client, the user has ways to find that out.
3. You may, however, protect your user against third parties.
4. Code that is executed in the client-side can be manipulated. HTML, CSS and JavaScript can all be edited.
5. Fortunately, those edits are local. Meaning that an user can change the JavaScript that's executed on his computer, but fortunately not the JavaScript that's executed in someone else's computer - provided the server is well implemented.

Ajax code is typically executed client-side (I'm going to bet it's also true in your case), so all your JavaScript can be modified. Your "receive token" function can just be modified to include an alert function.

function receive_token() {
    var key = ajax_request_token();
    //Code injected by the user
    alert(key);
    //End code injected by the user
    return key;
}

The user could then proceed to use your key token to pretend he's the application.

Not sure what you mean by "the file being included within another one".