When it comes to security issues, it's important to note that in addition to actual platform and operating system security issues, you also need to ensure that you write secure applications. When writing PHP applications, apply the following seven habits to ensure your application has the best possible security:
• Validate input
• Protect the file system
• Protect the database
•Protect session data
•Protect cross-site scripting (XSS) vulnerabilities
•Verify form post
•Protect against Cross-Site Request Forgeries (CSRF) Protect

Validate input
When it comes to security issues, validating your data is the most important habit you can adopt. And when it comes to input, it's very simple: don't trust the user. Your users may be excellent, and most of them may use the application exactly as expected. But wherever there is an opportunity for input, there is also a high probability of very bad input. As an application developer, you must prevent your application from accepting incorrect input. Careful consideration of the location and correct value of user input will allow you to build a robust, secure application.
Although file system and database interaction will be covered later, Listed below are general validation tips that apply to various validations :
• Use white Values ​​in the list
• Always revalidate limited options
• Use built-in escaping functions
• Validate correct data types (like numbers)
Values ​​in the whitelist (White- listed value) is the correct value, as opposed to the invalid black-listed value (Black-listed value). The difference between the two is that typically when validating, the list or range of possible values ​​is smaller than the list or range of invalid values, many of which may be unknown or unexpected values.
When doing validation, remember that it is often easier to design and validate the values ​​your application allows than to protect against all unknown values. For example, to limit a field value to all numbers, you need to write a routine that ensures that the input is all numbers. Do not write routines that search for non-numeric values ​​and mark them as invalid when they are found.

Securing File Systems
In July 2000, a Web site exposed customer data stored in files on the Web server. A visitor to the Web site used the URL to view a file containing data. Although the file was misplaced, this example highlights the importance of protecting the file system from attackers.
If a PHP application manipulates a file and contains variable data that the user can enter, carefully check the user input to ensure that the user cannot perform any inappropriate actions on the file system. Listing 1 shows an example of a PHP site that downloads an image with a specified name.
List 1. Download file

As you can see, the more dangerous script in Listing 1 will process all files that the web server has read access to, including files in the session directory (see "Securing session data") and even some system files ( For example /etc/passwd). For demonstration purposes, this example uses a text box where the user can type a filename, but the filename can easily be provided in the query string.
Simultaneous configuration of user input and file system access is dangerous, so it is best to design your application to use a database and hide generated filenames to avoid simultaneous configuration. However, this doesn't always work. Listing 2 provides a sample routine for validating file names. It will use regular expressions to ensure that only valid characters are used in file names, and specifically checks for dot characters: ..
Listing 2. Checking for valid filename characters

Protect database
In April 2008, the Bureau of Prisons of a certain state in the United States was querying SQL column names were used in the string, thus exposing confidential data. This breach allowed a malicious user to select which columns to display, submit the page, and obtain the data. This leak shows how users can perform input in ways that application developers could not have anticipated, and demonstrates the need to defend against SQL injection attacks.
Listing 3 shows a sample script that runs a SQL statement. In this case, the SQL statement is a dynamic statement that allows the same attack. The owner of this form may think the form is safe because they have restricted the column names to select lists. However, the code misses one last tip about form cheating — just because the code limits the options to a drop-down box doesn't mean that someone else can't post the form with the required content (including the asterisk [*]).
Listing 3. Execute SQL statement

So, to get into the habit of protecting your database, avoid using dynamic SQL code whenever possible. If you cannot avoid dynamic SQL code, do not use input directly on a column. Listing 4 shows that in addition to using a static column, you can add a simple validation routine to the account number field to ensure that the input value is not a non-numeric value.
Listing 4. Protection via validation and mysql_real_escape_string()