Security Holes

Adding database interaction to an XHR exposes security holes that can allow malicious hackers to make requests to our server side. All they would need to know is the URL of the file in which to make the request. With the new debugging tools that are available, such as the ones that were covered in Chapter 8, "Debugging," we can actually spy on requests and see the exact URL they are requesting along with the parameters that are passed. This is great for debugging, but provides anyone with the ability to easily understand the interactions that you are making with Ajax to the server by exposing your requests. This, of course, is a huge threat if you are connected to files that interact with a database or contain other important data that you do not want to share with the public.

Throughout the rest of this chapter, we will focus on creating a process for password-protecting our XHRs and verifying them on the server side. The object that will create and verify these passwords is called the PasswordManager and can be seen in Listing 23.1.

Listing 23.1. Creating and Verifying XHRs (PasswordManager.class.php)

< ?php class PasswordManager {     private function PasswordManager() {}     public static function getInstance()     {         static $instance;         if (!is_object($instance))         {             $instance = new PasswordManager();         }         return $instance;     }     public function getPassword($arr)     {         $max = count($arr);         $index = rand(0, $max);         $seed = $arr[$index];         return md5($seed) .":". $index;     } public function verfiyPassword($arr, $password) {         $uid = split(":", $password);         $seed = $arr[$uid[1]];         return md5($seed) .":". $uid[1] == $password; } } ?>

Let's take a look at how to create this object and use it to protect the requests that we make during runtime.