Understand the basics of PHP and its security issues

Security | issues

Sometimes, your business may involve the security of your PHP application. When you encounter an audit task, do you know how to perform a lookup? This series will take you into PHP and help you understand it in a certain program so that you know what to look for when conducting a security audit. The 1th section introduces you to the Register_globals settings.

Getting Started

I hereby assume that you have a general understanding of the syntax of PHP, at least to write "Hello World" programs. If you don't have the basics, first learn about the PHP manual and some basic PHP tutorials (see Resources). Many publishers have good books about PHP. It is recommended that beginners first look at books in the form of introductory books or recipes. The

performs an audit on an accurate copy of the production environment. You do not need to replicate the hardware, but you need to ensure that the software version is as realistic as possible. The PHP configuration must match exactly, which is already specified in the php.ini file, in the Apache directive of the. htaccess file, or in httpd.conf. You need to prepare a separate environment because you will display and record errors that may contain sensitive passwords and other information. In addition, you will try to break the security of the site, which you are trying to avoid in the active application.

The first step is to change the PHP error_reporting setting to E_all. When a change is set, PHP reports a warning message whenever an uninitialized variable is used, an error file is accessed, and other (most) harmless errors occur, but there is also the possibility that this is a potential attack vector. These errors are generally only indicative of sloppy programming, so if this is your code, you can clear them out.

This setting looks like this:

error_reporting = E_all

If you don't know where the php.ini file is, you can find it by creating a. php script that contains the following text:
<?php

Phpinfo ();

The top section of the output has a row listing the location of the PHP lookup php.ini:


Figure 1. PHP finds the location of the php.ini

[[The No.1 picture.]]

The value may change somewhat, but/usr/local/lib/php.ini is most UNIX? Public location on the system, C:\php\php.ini or C:\WINDOWS\php.ini is most Microsoft? Windows? The public location on the system. If the file does not exist, create one and type the error_reporting line above in the file. After you modify the php.ini file, you need to restart the Web server before PHP can enable the new settings.
　　
If you have not previously created the Phpinfo () page, you can create it now. The second major part of the label is "configuration," which contains a lot of useful information about how to set up PHP. This section includes three columns: set name, local value, and XMaster value. The primary value is a value that is set globally by the php.ini directive for all PHP scripts on your machine. The local value is the value that is in effect for the current script. The effects on it are:. htaccess settings, httpd.conf settings in the <Location> or <Directory> section, and Ini_set calls in PHP scripts. At run time, only certain settings are available for change. Please refer to the PHP manual in resources for more information.
　　
The other two settings that you need to customize are display_errors and log_errors. You need to have at least one of these two settings enabled, or both. Log_errors notifies PHP to record notes, warnings, or errors in the file, Display_errors displays the notes, warnings, and errors that are recorded on the screen. They are not mutually exclusive. Enabling at least one of them can effectively identify programming errors that can lead to security vulnerabilities.
　　
What kinds of security issues should I look for?
　　
Thankfully, many of the programming errors that lead to security vulnerabilities are not possible in PHP. Stack and buffer overflows are two common problems in the C and C + + environments. Because PHP can manage memory for you, PHP code does not cause stack and buffer overflow.
　　
However, PHP itself is written in C language, and sometimes memory problems deep into the core of PHP. Therefore, you need to always be concerned about security bulletins and updates. PHP publishes the new PHP version in its Web site (see Resources) and explains whether to include security patches.
　　
Most of the problems in the PHP application are related to the use of user-supplied data and have not been validated and disinfected prior to using it and performing operations on it. You may have heard of a vulnerability called Cross-site scripting (XSS). XSS attacks by providing input that the program does not expect, and then using the program to handle rogue input. Writing good programs can avoid these assumptions. In the area of airport security, PHP programs are used to check passengers ' baggage.
　　
Other problems are subtle logic errors. For example, check a series of parameters to see if a user is authorized to access a resource, put parentheses in the wrong place, and some users go where they should not otherwise. We want your application to be well-organized and have this centralized logic.
　　
Identify user input
　　
The trickiest thing is how to differentiate untrusted input from external sources, such as a user, another Web site, or some other resource, and data that has been validated. Someone has put forward the idea of "Don't believe Everything", that is, no matter where it comes from, validate its data for all functions. This approach involves the following things: first, validation means different things in different contexts; second, fast execution of validation at all levels of the application is tedious and error-prone; Third, you are auditing your application instead of rewriting it from scratch. You need to track user input through existing code instead of wrapping each variable you see with a validation function.
　　
Non-expected user input
　　
Where does user input come from? The first source is get, POST, and COOKIE data. Generally called GPC data. The identifiable program for this data relies on a disputed php.ini setting: Register_globals. After the PHP V4.3.0, Register_globals is set to off by default. But a few years ago, in PHP, the default value for Register_globals was open, so there was a lot of code that needed it.
　　
Register_globals itself is not a security risk. However, it makes it more difficult to track user input and ensure application security. Why is that? Because if you turn on register_globals, in the global namespace and in the $_get, $_post, or $_cookie arrays, you will create all the variables that get, POST, and Cookies pass to the PHP script.
　　
The following are examples of how they work and how they are important:
　　
Listing 1. Security of Cookies
　　
1 <?php
2
3//The If the user has the secret cookie.
4 if (!empty ($_cookie[' secret ')) {
5 $authorized = true;
6}
7
8//Now let's go through a list of press releases and show them.
9 $releases = get_press_releases ();
A foreach ($releases as $release) {
11
A//Some releases are restricted. Only show them to people who can
//Secrets.
if ($release [' secret ']) {
if (! $authorized) {
Continue;
17}
18}
19
//We must be allowed to the it.
Showrelease ($release);
22}
　　
You should pay attention to a few things. First, it is not a good idea to rely on cookies to determine whether a user has passed authentication-because people can easily set their own cookie values. We will describe this in another article. However, the disadvantage of this script is that if you turn on register_globals, it is not secure.
　　
The following describes the script named press.php. In general, when a user accesses a script in the press release, its browser displays http://www.example.com/company/press.php.
　　
Now notice what happens when the user changes it to http://www.example.com/company/press.php?authorized=1 without authorization?
　　
Look at the previous code: set $authorized only when the user is using cookies. It will never be set to false. Later introduced register_globals--it replaces the $_get[' authorized ' that was just used, and there is a variable $authorized with a value of 1 in the global scope. Therefore, even if the user does not have a cookie check, $authorized later referenced in the Foreach loop, it is still validated as true.
　　
There are two ways to fix this defect. One, of course, is to close the register_globals. This is a good idea if it doesn't affect your production site. You need to test the application to make sure it doesn't break.
　　
Another way is a bit like "defensive programming". All we need to do is change the cookie check to the following form:
　　
Listing 2. Use cookies to improve security
　　
1 <?php
2
3//The If the user has the secret cookie.
4 $authorized = false;
5 if (!empty ($_cookie[' secret ')) {
6 $authorized = true;
7}
　　
...
　　
At this point, when the user adds a authorized=1 to the script URL, the $authorized variable is still set to 1--but it is overwritten by $authorized = False, and only those users who actually have a secret cookie can see the restricted PR ESS release. They can still design their own cookies.
　　
Audit code Lesson: try to close register_globals. If you cannot run the Register_globals application without opening it, and you cannot modify it, or you cannot control the PHP configuration where the application must run, you need to find all the global variable settings in the conditional block, or enter the global scope through some function calls. If Register_globals is open, both cases are caused by the user setting the variable to any value.
　　
A good way to find these variables is to set the php.ini setting error_reporting to E_all, using either Log_errors or display_errors, so that all PHP warnings and errors are recorded separately in the file or displayed on the screen. Whenever you use an uninitialized variable (assuming you have a value), you get a e_notice. Is this like C and Java? Language, it is still different from declaring variables for PHP requirements. As a result, when our first version of the script runs, the error message that appears is:
　　
notice:undefined variable:authorized in C:\var\www\articles\press.php
On line 15