GET SECURED SERIES 1: PASSING VARIABLES

GET SECURED SERIES: PART 1
 WATCH OUT YOU MAY BE THE NEXT VICTIM

You have just developed your e-payment, e-commerce, e-social network, or any of the e’s or just a simple blog or guestbook application or feedback contact us form and you were excited you could drop your computer and laid down your back to relax, Watch Out..!!!, The bad guys are out there waiting to exploit the your simplest possible mistake or ignorance on your web application.

Just on the start of development of any web application, always have it at the back of your mind the bad guys.  Do everything thing you can to protect your application else, scripts, injections and other tools are planted in your web application to exploit all the security vulnerabilities available. I will be going through a list of the common attacks in this series and the best way prevent them as well as security tips to put at the back of your mind during your application development process.

PASSING VARIABLES

For a highly dynamic and complex application, it is common to pass data around from one page to the other which can either be in form of http’s GET or POST request method using a form, or direct data post functions such as CURL. Although there are also other request methods, that is beyond the scope of this article. You can pass your data either as a session variable or a cookie stored on the user’s computer as well.

Rule 1>
Get your mind totally off PHP “register_globals”

WHY?
Simply because register_globals will inject your scripts with all sorts of variables, like request variables from HTML forms. When register_globals is on, people use variables yet really don't know for sure where they come from and can only assume. Internal variables that are defined in the script itself get mixed up with request data sent by users

<?php // define $authorized = true only if user is authenticated if (authenticated_user()) { $authorized = true; } // Because we didn't first initialize $authorized as false, this might be // defined through register_globals, like from GET http://www.somesite.com/auth.php?authorized=1 // So, anyone can be seen as authenticated! if($authorized) { include "/highly/sensitive/data.php"; } ?>


Ofcourse from the code above, $authorized can be set from the url, even if your variables are stored in sessions and unfortunately you get your highly sensitive data into the wrong hands.

So always call the super global variables to retrieve your users data.
i.e. $_GET[‘user’],$_POST[‘user’],$_SESSION[‘user’], and if you are not sure where its coming from, you can use the $_REQUEST[‘user’].

TIPS
Always make sure you initialize your variables, it’s a good programming practice.

Rule 2>
Always encode any data that will be passed with the URLS.

WHY?
 Because any string you url encode returns a string in which all non-alphanumeric characters except hyphen (-) and underscore (_)  get replaced with a percent (%) sign followed by two hex digits and spaces encoded as plus (+) signs.

Valid URL format means that the URL contains only what is termed "alpha | digit | safe | extra | escape" characters. URL encoding is normally performed to convert data passed via html forms, because such data may contain special character, such as "/", ".", "#", and so on, which could either:
a) have special meanings
b) is not a valid character for an URL
c) could be altered during transfer

Examples of encoded characters are: $ & < > ? ; # : = , " ' ~ + % “space character”

When not encoded using the get method:
When variables are passed using the “get request”, The parameters (i.e the data) are simply attached to the URL sending that page.

E.g 1: ) To pass the name of a user to another page called mypage.php

// IF DECLARED IN YOUR CODE <?php $user = “tayo”; $choice = “buttered bread & tea”; header(“Location:  page.php?name=$user&choice=$choice”); ?> // IF ITS FROM A USER IN FORM OF A FORM, YOU CAN HAVE SOMETHING LIKE THIS <form method="get" action=""> Name: <input type="text" name="user" /><br /> <input type="radio" value="butter bread & tea" name="choice" /> Breakfast<br /> <input type="submit" value="submit" name="submit" /> </form>

Looks something similar to this on the address bar;
http://www.somesite.com/page.php?name=tayo&choice=buttered bread

E.g When encoded:

<?php $user = urlencode(“tayo”);                                          //encoded $choice=urlencode(”buttered bread & tea”);              //encoded header(“Location:  mypage.php?name=$user&choice=$choice”); ?>

Properly encoded url of the above looks something like this:
http://www.somesite.com/page.php?name=tayo&choice=butter+bread+%26+tea

Note:  Don’t forget to decode the variables when you get to the page receiving the variable. i.e here, your page.php

// Page.php <?php $name = urldecode($_GET[‘name’]); $choice = urldecode($_GET[‘choice’]); ?>

Rule 3>
Never trust any variable this is not defined within the context of your application or variable/data passed that is retrieved on another page via a get request or any data supplied by the user.

WHY?
A colleague of mine use to refer to any data supplied by the user as ”Evil Strings”. This is because these fields have become over the years a point of attack for hackers using SQL injection statements, Null Byte injections, XSS attacks and many other ways to steal user data. We will cover these attacks in these series. If such data is not properly escaped or sanitized, you could kiss your database goodbye, get the face of your website defaced or even cause your website to add to the traffic of the hacker’s webpage.

<?php Class Myfilter{ private $userdata = “”; public function filter($var) { $usr_data = “”;   // Strip whitespace (or other characters) from the beginning and end of a string $usr_data = trim($var); //  Calling htmlentities below, '&' turns to '&amp;' // double quotes '"' turns to '&quot;' when ENT_NOQUOTES is not set. // "'" (single quote) becomes '&#039;' only when ENT_QUOTES is set. // '<' (less than) becomes '&lt;' // '>' (greater than) becomes '&gt;' $usr_data  = htmlentities($usr_data); // Removes all php or html tags that could affect your script $user_data = strip_tags($usr_data); // OTHER FILTERING CODES GOES HERE $this->userdata = $usr_data; return $this->userdata; } } //Using the class above, $myfilter = new MyFilter(); $user_variable = $myfilter -> filter($_REQUEST[‘user_variable’]) ; ?>

If you are to echo directly or introduce to other portions of your code that might be involve in sql query statements, kindly make sure you are receiving the data type expecting by converting to the respective data types.

e.g if you are expected an integer, Cast the data received from the url to integer to chop of the irrelevant strings attached.

<?php // CAST DATA TO INTEGER $page_id = (int) $_GET[‘page_id’];  // OR CHECK DATA TYPE e.g if you are expecting an integer if( is_int( $_GET[‘page_id’]) ){ // SELECT CONTENT FROM DATABASE} ?>

CONCLUSION
- Assign default values to your variables immediately they are declared
- Forget about register_globals and access the variables using the full request method
- Sanitize and escape any data received from the user before use in your scripts
- Ensure you are receiving the expected data type from the user, by casting or using regular expressions

RESOURCES
More on Register globals (php.net - Manual)
More on Url Encoding (http://www.permadi.com/tutorial/urlEncoding/)