Home > Article > Backend Development > focus magic php xfocus anti-injection information
There is no deep technical content here, I just talked about it briefly. (If there are no specific instructions, the following operations are all based on the situation of PHP+MySQL+Apache) When various hackers are rampant now, how to realize the security of your own PHP code and ensure the security of the program and server is a very important issue. I I casually looked at the information about PHP security, and there is not a lot, at least much less than ASP, haha, so I wanted to write something to prevent these possible situations. There is no deep technical content here, I just talked about it briefly. (If there are no specific instructions, the following operations are based on PHP+MySQL+Apache)
Let’s talk about security issues first. Let’s first take a look at two articles:
http://www.xfocus.net/articles/200107 /227.html
http://www.xfocus.net/articles/200107/228.html
The above article is an article about PHP security in Security Focus. It basically introduces some security issues about PHP in a comprehensive manner.
When coding in PHP, if you consider some basic security issues, first of all:
1. Initialize your variables
Why do you say that? Let's look at the following code:
if ($admin)
{
echo 'Login successful! ';
include('admin.php');
}
else
{
echo 'You are not an administrator and cannot manage! ';
}
Okay, let's see that the above code seems to be running normally and there is no problem. Then let me submit an illegal parameter to it. What will be the effect? For example, our page is http://www.traget.com/login.php, then we submit: http://www.target.com/login.php?admin=1, haha, think about it, we are Either you are an administrator directly, you manage it directly.
Of course, maybe we won’t make such a simple mistake, and some very secret errors may also cause this problem. For example, there is a vulnerability in the phpwind 1.3.6 forum that was recently exposed, which allows us to directly obtain administrator rights. Because there is a $skin variable that is not initialized, it leads to a series of problems later.
So how do we avoid the above problems? First, start with php.ini and set register_global = off in php.ini. This means that not all registered variables are global, so this can be avoided. However, we are not server administrators and can only improve it from the code. So how do we improve the above code? We rewrite it as follows:
$admin = 0; // Initialize variables
if ($_POST['admin_user'] && $_POST['admin_pass'])
{
// Determine whether the submitted administrator username and password are correct The corresponding processing code
//...
$admin = 1;
}
else
{
$admin = 0;
}
if ($admin)
{
echo 'Login successful! ';
include('admin.php');
}
else
{
echo 'You are not an administrator and cannot manage! ';
}
Then it won’t work if you submit http://www.target.com/login.php?admin=1 at this time, because we initialized the variable to $admin = 0 at the beginning. Then you cannot gain administrator privileges through this vulnerability.
2. Prevent SQL Injection (sql injection)
SQL injection should be the most harmful program at present, including the earliest from asp to php, which are basically popular technologies in the country in the past two years. The basic principle is to pass the inaccuracy of submitted variables. Filtering forms an injection point and then allows malicious users to submit some SQL query statements, resulting in important data being stolen, data lost or damaged, or being invaded into the backend management.
I won’t go into the basic principles. Let’s take a look at the following two articles to understand:
http://www.4ngel.net/article/36.htm
http://www.4ngel.net/article/ 30.htm
So now that we understand the basic injection intrusion methods, how can we prevent it? We should start with the code.
We know that there are two ways to submit data on the Web, one is get and the other is post, so many common sql injections start from the get method, and the injection statements must contain some sql statements, because there are no SQL statement, how to proceed? There are four major sentences in SQL statement: select, update, delete, insert. So if we filter the data we submit, can we avoid these problems?
So we use regular expressions to construct the following function:
/*
Function name: inject_check()
Function function: Detect whether the submitted value contains SQL injection characters, prevent injection, and protect server security
Parameters: $sql_str: Submit Variable Return Value: Return to test results, ture or false
Function Author: heiyeluren
*/
Function inject_check ($ SQL_STR) {
Return EREGI ('Select | UPDATE | DELETEE | '|/*|* |../|./|union|into|load_file|outfile', $sql_str); // Filter
}
In our function, select, insert, update, delete, union, into, load_file, outfile /*, ./ , ../ , ' and other dangerous parameter strings are all filtered out, then the submitted parameters can be controlled. The program can be constructed like this:
if (inject_check($_GET['id']))
{
exit('The data you submitted is illegal, please check and resubmit!');
}
else
{
$id = $_GET['id'];
echo 'The data submitted is legal, please continue! ';
}
?>
Suppose we submit the URL as: http://www.target.com/a.php?id=1, then it will prompt:
"The submitted data is legal, please continue!"
If we submit http://www.target.com/a.php?id=1' select * from tb_name
a prompt will appear: "The data you submitted is illegal, please check and resubmit!"
Then we have achieved Our requirement.
However, the problem has not been solved yet. If we submit http://www.target.com/a.php?id=1asdfasdfasdf, ours complies with the above rules, but it does not meet the requirements. , so we build a function to check for other situations:
/*
Function name: verify_id()
Function function: Verify whether the submitted ID class value is legal
Parameters: $id: submitted ID value
Return value: Return the processed ID
Function author: heiyeluren
*/
function verify_id($id=null)
{
if (!$id) { exit('No parameters submitted!'); } // Determination of whether it is empty
elseif (inject_check($id)) { exit('The submitted parameters are illegal!'); } // Determination of injection
elseif (!is_numeric($id)) { exit('The submitted parameters are illegal ! '); } // Numerical judgment
$id = intval($id); // Integerization
return $id;
}
Haha, then we can verify it, so our program code above is It becomes the following:
if (inject_check($_GET['id']))
{
exit('The data you submitted is illegal, please check and resubmit!');
}
else
{
$id = verify_id($_GET['id']); // Our filter function is quoted here to filter $id
echo 'The submitted data is legal, please continue! ';
}
?>
Okay, the problem seems to be solved here, but have we considered the data submitted by post, the large batch of data?
For example, some characters may cause harm to the database, such as ' _ ', ' % '. These characters have special meanings, so what if we control them? Another point is that when magic_quotes_gpc = off in our php.ini, the submitted data that does not comply with the database rules will not automatically add ' ' in front. Then we need to control these problems, so we build it as follows Function:
/*
Function name: str_check()
Function function: Filter the submitted string
Parameters: $var: The string to be processed
Return value: Return the filtered string
Function author: heiyeluren
*/
function str_check( $str )
{
if (!get_magic_quotes_gpc()) // Determine whether magic_quotes_gpc is open
{
$str = addslashes($str); // Filter
}
$str = str_replace ("_", "_", $str); // Filter out '_'
$str = str_replace("%", "%", $str); // Filter out '%'
return $ str;
}
OK, we once again avoided the danger of the server being compromised.
Finally, consider submitting some large batches of data, such as posting, or writing articles or news. We need some functions to help us filter and convert. Based on the above function, we build the following function:
/*
Function name: post_check()
Function function: Process the submitted editing content
Parameters: $post: Content to be submitted
Return value: $post: Return filtered content
Function author: heiyeluren
*/
function post_check($post)
{
if (!get_magic_quotes_gpc()) // Determine whether magic_quotes_gpc is open
{
$post = addslashes($post); // Filter the submitted data if magic_quotes_gpc is not open
}
$post = str_replace("_", "_", $post); // Filter out '_'
$post = str_replace("%", "%", $post); // Filter out ' % 'Filter out
$post = nl2br($post); // Enter conversion
$post= htmlspecialchars($post); // HTML tag conversion
return $post;
}
Haha, basically here, we put some I have explained the situation once, but I actually feel that I have said very little. At least I have only talked about two aspects, and there is very little content in the entire security. I will consider talking about more next time, including PHP security configuration, Apache Safety, etc., let our safety be a whole and be the safest.
Finally, let me tell you what I expressed above: 1. Initialize your variables 2. Remember to filter your variables
The above introduces focus magic php xfocus anti-injection information, including focus magic content. I hope it will be helpful to friends who are interested in PHP tutorials.