php xfocus anti-injection information_PHP tutorial-PHP Tutorial-php.cn

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 all 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 on Security Focus. Basically, it is relatively Comprehensive introduction to some security issues about PHP.

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, we 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 mistakes may also cause this problem. For example, the recently exposed phpwind 1.3.6 forum has a vulnerability that allows us to directly obtain administrator rights. , it is because there is a $skin variable that is not initialized, which 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 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 the submission The corresponding processing code is whether the administrator username and password are correct
// ...
$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 initialize the variables at the beginning If $admin = 0, then you will not be able to obtain 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, basically in the past two years in China The basic principle of popular technology is to form an injection point by not filtering submitted variables and then enable 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 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 statement must contain some sql Statement, because there is 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 to prevent injection. Protect server security
Parameters: $sql_str: Submitted variable
Return value: Return the detection result, true or false
Function author: heiyeluren
*/
function inject_check($sql_str)
{
return eregi('select|insert|update|delete|'|/*|*|../|./|union|into|load_file|outfile', $sql_str); // Filter
}

Our function filters out all dangerous parameter strings such as select, insert, update, delete, union, into, load_file, outfile /*, ./, ../, ' etc. , then you can control the submitted parameters. 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 submitted data is legal, please continue! ';
}
?>
Suppose we submit the URL as: http://www.target.com/a.php?id=1, then it will prompt:
"Submitted The 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 you have met our requirements.

However, the problem has not been solved yet. If we submit http://www.target.com/a.php?id=1asdfasdfasdf, ours is in compliance with the above rules, but, it It does not meet the requirements, so we build a function to check for possible other situations:

/*
Function name: verify_id()
Function function: Verify the submitted Is the ID class value legal?
Parameters: $id: Submitted ID value
Return value: Returns the processed ID
Function author: heiyeluren
*/
function verify_id($id =null)
{
if (!$id) { exit('No parameters submitted!'); } // Determine whether it is empty
elseif (inject_check($id)) { exit('Submit The parameter is illegal! '); } // Injection judgment
elseif (!is_numeric($id)) { exit('The submitted parameter is illegal!'); } // Numeric judgment
$id = intval($ id); // Integer

return $id;
}

Haha, then we can perform verification, so our program code above becomes the following of:

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 and 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 the following Function:

/*
Function name: str_check()
Function function: Filter the submitted string
Parameters: $var: The string to be processed
Return Return value: Return the filtered string
Function author: heiyeluren
*/
function str_check( $str )
{
if (!get_magic_quotes_gpc()) // Determine whether magic_quotes_gpc is turned on
{
$str = addslashes($str); // Filter
}
$str = str_replace("_", "_", $str); // Put '_' 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 functions, we construct 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 To open
{
$post = addslashes($post); // Filter the submitted data when magic_quotes_gpc is not opened
}
$post = str_replace("_", "_" , $post); // Filter out '_'
$post = str_replace("%", "%", $post); // Filter out '%'
$post = nl2br($ post); // Enter conversion
$post= htmlspecialchars($post); // HTML tag conversion

return $post;
}

Haha, that’s basically it , we have talked about some situations. In fact, I feel that I have talked about 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 security, etc., let our security be as 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