Understanding PHP and its security issues

Sometimes, your business may involve the security of PHP applications. When you encounter an audit task, do you know how to perform the search? This series will take you to PHP and help you understand it in a certain program, so that you know what to look for during security audit. Part 1 describes register
Sometimes, your business may involve the security of PHP applications. When you encounter an audit task, do you know how to perform the search? This series will take you to PHP and help you understand it in a certain program, so that you know what to look for during security audit. Section 1st describes register_globals settings.
　　
　　 Getting started
　　
I would like to assume that you have a general understanding of PHP syntax and can at least write programs like "Hello World. If you do not have the basic knowledge, first learn the PHP manual and some basic PHP tutorials (see references ). Many publishers have good books on PHP. It is recommended that beginners first look at entry books or recipes.
　　
Perform audits on accurate copies of the production environment. You do not need to copy the hardware, but make sure that the software version is as accurate as possible. The PHP configuration must be exactly matched. this is specified in the php. ini file, in the Apache command 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 interrupt the security of the site, which is avoided in active applications.
　　
The first step is to change the PHP error_reporting settings to E_ALL. After the settings are changed, PHP reports a warning message whenever uninitialized variables are used for incorrect file access and other (most) harmless errors occur, but there is also the possibility that this is a potential attack vector. These errors generally indicate that programming is hasty, so if this is your code, you can clear them.
　　
　　 This setting is as follows:
　　
Error_reporting = E_ALL
　　
If you do not know where the php. ini file is located, you can use the. php script that contains the following text to search for it:
　　
　　 　　
Phpinfo ();
　　
The above line of output lists the PHP search position for php. ini:
　　
Figure 1. PHP search for the location of php. ini
[[The No.1 Picture.]
The value may change, but/usr/local/lib/php. ini is the majority of UNIX? Public location on the system. C: \ php. ini or C: \ WINDOWS \ php. ini is the majority of Microsoft? Windows? Public location on the system. If the file does not exist, create one and type the preceding error_reporting line in the file. After modifying the php. ini file, you must restart the Web server to enable the new settings in PHP.
　　
If you have not created a phpinfo () page before, 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 PHP. This part includes three columns: set name, local value, and xmaster value. The main value is the value set globally for all php scripts on your machine using the PHP. ini command. The local value is valid for the current script. It may be affected by:. htaccess settings, httpd. conf Or The settings in section and the ini_set call in the PHP script. At runtime, only some settings can be changed. See the PHP manual in reference for details.
　　
The other two settings that need to be customized are display_errors and log_errors. You must enable either or both of the two settings. Log_errors notifies PHP to record the attention, warning, or error in the file. display_errors displays the recorded attention, warnings, and errors on the screen. They are not mutually exclusive. At least one of them can be enabled to effectively detect programming errors that may lead to security vulnerabilities.
　　
　　 What types of security questions should I find?
　　
Fortunately, many programming errors that cause security vulnerabilities cannot exist in PHP. Stack and buffer overflow are two common problems in the C and C ++ environments. Because PHP can manage memory for you, PHP code will not cause stack and buffer overflow.
　　
However, PHP itself is also written in C language, and sometimes the memory problems reach the core of PHP. Therefore, you must always pay attention to security bulletins and updates. PHP publishes a new PHP version on its Web site (see references) and describes whether security patches are included.
　　
Most problems in PHP applications are related to the use of user-supplied data, which has not been pre-verified and disinfected before being used and operated on. You may have heard of a cross-site scripting (XSS) vulnerability. XSS uses the input that is not expected by the provider, and then uses the program to attack the rogue input processing method. Writing good programs can avoid these assumptions. For airport security, the PHP program is used to check passengers' luggage.
　　
Other problems are subtle logical errors. For example, check a series of parameters to see if a user is allowed to access a certain resource, and whether the arc is misplaced so that some users enter a place where they were not supposed. We want your applications to be well organized and have such centralized logic.
　　
　　 Recognize user input
　　
The most tricky thing is how to differentiate untrusted input from external sources (such as a user, another Web site, or some other resources) and verified data. Some people have come up with the idea of "don't trust everything", that is, all functions need to verify their data no matter where they come from. This approach involves the following: first, verification means different things in different contexts; second, quick verification at all levels of the application is boring and error-prone; third, you are auditing the application rather than re-writing it from scratch. You need to use existing code to track user input, instead of using verification functions to wrap every variable you see.
　　
　　 Unexpected user input
　　
Where does user input come from? The first source is GET, POST, and COOKIE data. Generally referred to as GPC data. The identifiable program for this data depends on a controversial php. ini setting: register_globals. After PHP V4.3.0, register_globals is set to Off by default. But a few years ago, in PHP, the default value of register_globals was opened, so there were 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? Because if register_globals is enabled, all the variables that create GET, POST, and COOKIE are passed to the PHP script in the global namespace and $ _ GET, $ _ POST, or $ _ COOKIE array.
　　
The following is an example of the working method and its importance:
　　
Listing 1. COOKIE security
　　
1 2
3 // See 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 ();
10 foreach ($ releases as $ release ){
11
12 // Some releases are restricted. Only show them to people who can
13 // see secrets.
14 if ($ release ['secret']) {
15 if (! $ Authorized ){
16 continue;
17}
18}
19
20 // We must be allowed to see it.
21 showRelease ($ release );
22}
　　
You should pay attention to several things. First, it is not a good idea to rely on cookies to determine whether a user has passed identity verification-because people can easily set their own cookie values. This is described in another article. In any case, the disadvantage of this script is that it is not secure if register_globals is enabled.
　　
The following describes the script named press. php. Generally, when a user accesses the press release script, the browser displays http://www.example.com/company/press.php.
　　
Now note when users change it to http://www.example.com/company/press.php without authorization? What will happen when authorized = 1?
　　
Look at the previous code: set $ authorized only when the user uses cookies. It will never be set as false. Later, register_globals was introduced -- it replaced the $ _ GET ['authorized'] just used, and a variable $ authorized with a value of 1 exists in the global range. Therefore, even if the user does not pass the cookie check, $ authorized will still be verified as true when it is referenced in the foreach loop later.
　　
You can fix this vulnerability in two ways. First, disable register_globals. It is a good idea to disable it without affecting your production site. You need to test the application to make sure it is not interrupted.
　　
Another method is a bit like defensive programming ". We only need to change the cookie check to the following format:
　　
List 2. use cookies to improve security
　　
1 2
3 // See if the user has the secret cookie.
4 $ authorized = false;
5 if (! Empty ($ _ COOKIE ['secret']) {
6 $ authorized = true;
7}
　　
...
　　
Then, when the user? When authorized = 1 is added to the script URL, the $ authorized variable is still set to 1 -- but it will be overwritten by $ authorized = false, only users with secret cookies can view restricted press releases. They can still design their own cookies.
　　
Lessons learned from the audit code: try to disable register_globals. If you do not open the register_globals application, you cannot run it, and you cannot modify it, or you cannot control the PHP configuration where the application must run, you need to find all global variable settings in the condition block, or use some function calls to enter the global range. If register_globals is enabled, both cases are caused by setting the variable to any value.
　　
A good way to find these variables is to set php. ini sets error_reporting to E_ALL, and uses log_errors or display_errors. in this way, all PHP warnings and errors are recorded in the file or displayed on the screen. Every time you use an uninitialized variable (assuming it has a value), you will get an E_NOTICE. This is like C and Java? In the language, it is still different from asking PHP to declare variables. As a result, when we run the script of the first version, the error message is:
　　
Notice: Undefined variable: authorized in C: \ var \ www \ articles \ press. php
On line 15