PHP code review details

This article provides a detailed analysis of PHP code review. For more information, see

This article provides a detailed analysis of PHP code review. For more information, see

Overview
Code review is a systematic check of the application source code. It aims to find and fix some vulnerabilities or program logic errors in the application development stage, so as to prevent the illegal exploitation of program vulnerabilities from bringing unnecessary risks to the Enterprise.
Code review is not a simple code check. The reason for reviewing the Code is to ensure that the code can be securely protected by sufficient information and resources, therefore, it is very important to be familiar with the business process of the entire application to control potential risks.
Reviewers can use questions similar to the following to interview developers to collect application information.

What types of sensitive information does an application contain and how does the application protect it?
Does an application provide internal services or external services? Who will use it? Are they all trusted users?
Where is the application deployed?
What is the importance of applications for enterprises?

The best way is to make a checklist for developers to fill in. Checklist can intuitively reflect application information and coding Security done by developers. It should cover modules that may have severe vulnerabilities, such: data verification, identity authentication, session management, authorization, encryption, error processing, logs, security configuration, and network architecture.

Input verification and output display
Most vulnerabilities are caused by the absence of security verification on the input data or the absence of security processing on the output data. The strict data verification method is: precise data matching.
Accept data from the whitelist
Reject blacklist data
Encode the data that matches the blacklist

In PHP, the list of variables that users can enter is as follows:
$ _ SERVER
$ _ GET
$ _ POST
$ _ COOKIE
$ _ REQUEST
$ _ FILES
$ _ ENV
$ _ HTTP_COOKIE_VARS
$ _ HTTP_ENV_VARS
$ _ HTTP_GET_VARS
$ _ HTTP_POST_FILES
$ _ HTTP_POST_VARS
$ _ HTTP_SERVER_VARS
We should check these input variables

Command Injection
Security threats
Command injection attacks modify the dynamically generated content of a webpage by inputting HTML code into an input mechanism (for example, a table domain that lacks valid Verification restrictions, this may cause malicious commands to control users' computers and their networks. The following functions can be used to execute system commands in PHP: system, exec, passthru, '', shell_exec, popen, proc_open, and pcntl_exec. We can search for these functions in all program files, determine whether the function parameters are changed due to external submissions and check whether these parameters have been safely processed.
Sample Code
Example 1:

The Code is as follows:

// Ex1.php
$ Dir = $ _ GET ["dir"];
If (isset ($ dir ))
{
Echo"

";
system("ls -al".$dir);
echo "

";
}
?>

We submit

The Code is as follows:

Localhost/ex1.php? Dir = | cat/etc/passwd

After submission, the command becomes

The Code is as follows:

System ("ls-al | cat/etc/passwd ");

Defense methods
1. Try not to execute External commands
2. Use a user-defined function or function library to replace the functions of External commands
3. Use the escapeshellarg function to process Command Parameters
4. Use safe_mode_exec_dir to specify the path of the executable file
The esacpeshellarg function will escape any character that causes the parameter or command end. Replace the single quotation mark (') with "\", double quotation mark ("") with "\" ", replace Semicolon ";" with "\;", and use safe_mode_exec_dir to specify the path of the executable file. You can put the commands you want to use into this path in advance.

The Code is as follows:

Safe_mode = On
Safe_mode_exec_di r =/usr/local/php/bin/

Cross Site Scripting)
Security threats
Cross Site Script (XSS), a Cross-Site scripting threat. Attackers can use the application's dynamic data display function to embed malicious code into html pages. When a user browses this page, the malicious code embedded in html will be
Attackers can control the user's browser for special purposes. Output functions are often used: echo, print, printf, vprintf, <% = $ test %>

There are three types of XSS attacks:
(1) reflected cross-site scripting attacks
Through social engineering, attackers can send a URL Connection to the user to open the page. When the user opens the page, the browser will execute malicious scripts embedded in the page.
(2) Storage-type XSS attacks
Attackers can use the data entry or modification function provided by web applications to store data to servers or user cookies. When other users browse the pages that display the data, the Browser executes malicious scripts embedded in the page. All viewers will be attacked.
(3) DOM cross-site attack

Because a piece of JavaScript code is defined in the html page, an html code is displayed based on the user input. Attackers can insert a malicious script during the input and execute the malicious script during the display. The difference between DOM cross-site attack and the above two cross-site attacks is that DOM cross-site is the output of pure page scripts. Only JAVASCRIPT can be used for defense.

Malicious attackers can use cross-site scripting:
(1) steal user cookies and forge user identities to log on.
(2) the browser is forced to perform a page operation and initiate a request to the server as a user to attack the server.
(3) download the virus Trojan to the viewer's computer based on browser vulnerabilities.
(4) derivative URL jump vulnerability.
(5) publish a phishing page to the official website.
(6) worm attacks
Sample Code
"User controllable data" is displayed directly on the html page, which directly leads to cross-site scripting threats.

The Code is as follows:

Echo "$ newsname ";
Echo "$ gifname ";
Echo"";
Echo "". htmlentities ($ context )."";
?>

These display methods may cause the user's browser to regard "User controllable data" as JS/VBS script execution, or the page element to be controlled by the HTML code of the page inserted by "User controllable data, this can cause attacks.
Solution
A) before "User controllable data" is displayed in HTML, htmlescape should be escaped.

The Code is as follows:

Htmlspecialchars ($ outputString, ENT_QUOTES );

Html Escape should be escaped according to the following list:

The Code is as follows:

& --> &
<--> <
> -->
"-->"
'-->'

B) javascript escape is required for "User controllable data" output in javascript.
Escape characters include:

The Code is as follows: