PHP security issues

PHP syntax structure is very similar to C and Prel. developers can directly edit PHP Command code in any text editor without any special development environment. On the Web page, all PHP code is placed in "<? Php "and"?>" . PHP has its own unique security problems.
1) uninitialized global variables
Global variables in PHP do not need to be declared in advance. They will be automatically created for the first time, and PHP will automatically determine the type of the variables according to the context. This is quite convenient for programmers. As long as a variable is created, it can be used anywhere in the program ., However, during the compilation of PHP programs, programmers seldom initialize variables and usually use the default null value to create them directly. This allows attackers to spoof code and execute malicious purposes by assigning values to global variables.
By accepting user input (such as forms, cookies, or variable values), PHP programmers process user data and return the results to the client browser.

 
<Form method = "get" action = "test. php">
<Input type = "text" name = "test">
<Input type = "submit">
</Form>
In this example, the PHP programmer will display a submit button in the client browser. When you click the submit button, test. php processes your input. During his run, the "$ test" variable contains the user's input data. However, the user may directly enter the variable value in the URL of the browser address bar, such
Http: // test/test. php? Test = justtest
In this case, the value of the test variable is directly set to justtest. Attackers can skip the authentication mechanism using this method.
Let's take a look at this PHP code:

<! --? Php
If ($ pwd = "password "){
$ Pass = 1;
}
If ($ pass = 1)
Echo "you are a vaild user ";
? -->
This program is designed to verify that the user has the permissions to use the service by verifying the password entered by the user. However, attackers can
Http: // test/test. php: pass = 1
Set $ pass (pass variable) to 1, skip the verification mechanism, and directly use the service.
Theoretically, to protect the security of PHP programs, all variables should be verified before use. However, when there are many variables in the PHP program, this requires a huge workload. One of the most common protection methods is to check the user's submitted data.
PHP uses four different array variables to process user input. A secure PHP program should check the four arrays separately, including:
1. HTTP_GET_VARS: process data submitted in GET mode.
2. HTTP_POST_VARS: process data submitted in POST mode.
3. HTTP_COOKIE_VARS: process data submitted in COOKIE mode.
4. HTTP_POST_FILES (PHP 4.10 and later versions) to process File Upload variables.
2) File Upload
PHP automatically supports file upload. Take the following example:

<Form method = "post" enctype = "multipart/form-data">
<Input type = "file" name = "hello">
<Input type = "hidden" name = "max_file_size" value = "10240">
<Input type = "submit">
</Form>
This Code allows you to select a file from the local machine. When you click the submit button, the file will be uploaded to the server. This is obviously a very useful function, but the PHP program's response method makes this function insecure.
When the PHP program receives such a request for the first time, it will first accept files from remote users before it starts parsing the called PHP code, check whether the file length exceeds the value defined by the $ MAX_FILE_SIZE variable. If the test succeeds, the file will be stored in a local temporary directory.
Therefore, attackers can send arbitrary files to the host. When the PHP program has not decided whether to receive file uploads, the files have been stored on the server. When the file is temporarily stored on the server (the storage location is specified in the configuration file, usually/tmp), the extension is generally random, similar to the phpxXuoXG format. The PHP program uses four global variables to describe the uploaded file. In the preceding example, the PHP program can use the global variables $ hello, $ hello_size, $ hello_name, and $ hello_type to describe the uploaded file.
$ Hello = Name of the file on the Local Computer (for example, "/tmp/phpxXuoXG ")
$ Hello_size = File Size in bytes (for example, 1024)
$ Hello_name = original file name of the uploaded file on the remote computer (for example, c: \ temp \ hello.txt)
$ Hello_type = the Mine Type of the uploaded file (for example, "text/plain ")
Then the PHP program starts to process the file specified by $ hello.
The problem is that $ hello is not necessarily a variable set in PHP, and can be specified by any remote user. If you use the following method:
Http://www.2cto.com/vuln. php? Hello =/etc/passwd & hello_size = 1024 & hello_type = text/plain&hello_name=hello.txt
The following PHP global variable assignment occurs:
$ Hello = "etc/passwd"
$ Hello_size = 1024
$ Hello_type = "text/plain"
$ Hello_name = "hello.txt"
The four data items meet the expected variables of the PHP program. However, PHP does not process uploaded files, but/etc/passwd. This attack can be used to expose the content of any sensitive file.
To solve this problem, the new version of PHP uses HTTP_POST_FILES [] to process uploaded files. It also provides many new functions to make up for the defects of this process, for example, a special function is used to determine whether a file is actually uploaded. They solve this problem well, however, many PHP programs still use the method of the old global variable description file, so they still receive such attacks with the content.
3) database file reference
Initially, when people developed and released PHP programs, to differentiate the code library from the main program code, they set an extension. inc for the code library file. But they soon discovered that this was an error. When PHP is used as an Apache module, the PHP interpreter determines whether to parse the PHP code based on the file extension. The extension is specified by the site administrator. php ,. php3 and. php4, files with other extensions cannot be correctly parsed as PHP code by the PHP interpreter. If you directly request such files on the server, the source code of the file will be obtained, this will cause serious source code leakage.
The simplest solution is to specify a PHP file extension for each file. However, because each file is specified as a PHP file extension, you can directly request this file, the code that should have been run in a specific context may run independently.
The following is an obvious example.
Code in main. php:

<! --? Php
$ LibDir = "/libdir ";
$ LangDir = "$ libdir/languages"
...
Include ("$ libdir/loadlanguage. php ");
? -->
Code in libdir/loadlanguage. php:

...
Include ("$ langDir/$ userLang ");
It is safe to call libdir/loadlanguage. php by main. php. However, because the libdir/loadlanguage extension is the. PHP file that can be correctly parsed by the php interpreter, remote attackers can directly request the file to run and specify the values of $ langDir and $ userLang. This will bring security risks.
PHP configuration is flexible, and you can configure options to defend against some of these attacks.
(1) do not create global variables for users. Set the register_globals option to OFF. The PHP program automatically creates global variables for user input. That is to say, if the user submits the form variable hello, PHP will not create $ hello, but will only create HTTP_GET/POST_VARS ['Hello]. This is an extremely important option in PHP.
(2) set the security mode. Set the safe_model option to ON. This limits executable commands, available functions, and file access permissions. Set the allow_url_fopen option to OFF. Disable PHP programs from opening remote files through URL.
(3) Do Not Display error messages. Set the display_error option to OFF and the log_errors option to ON. Do not display the error information ON the webpage, but record it in the server log file. This effectively prevents attackers from detecting the functions and other sensitive information used in the target script.