The DEDECMS global variable coverage vulnerability was first announced by the wolf security team in. The official support has not completed the vulnerability so far, and now it basically covers all decms versions. I guess it is a backdoor intentionally left by the official team. The following is a little popular with this vulnerability, and you can ignore it completely:
1. Understand PHP super global variables
The following is the Super global variable of PHP. You can understand a feature, which is an array.
$ GLOBALS, all global variable arrays $ _ SERVER, SERVER environment variable arrays $ _ GET, passed to the variable array $ _ POST of the script through the GET method, the variable array $ _ COOKIE and cookie variable array $ _ REQUEST passed to the script through the POST method. All input variable arrays, including $ _ GET, $ _ POST and $ _ input content contained in cookies $ _ FILES, array of variables related to file upload $ _ ENV, array of environment variables $ _ SESSION, and array of SESSION Variables
2. Understand the $ _ GET variableYou can write a PHP file to see it: <? Php
Var_dump ($ _ GET );
?> Accessing http://www.bkjia.com/test. php? Key = value
GET array (1) {["key"] => string (5) "value"} OK. here we can see that $ _ GET is an array, we can use the GET method to upload an array. Access http://www.bkjia.com/test. php again? Key [arr1] = value to get array (1) {["key"] => array (1) {["arr1"] => string (5) "value"} we passed in a nested array through the GET method. The problem has actually come out. Many PHP security documents have not mentioned this feature of passing nested arrays through GET. Occasionally, several exploit pages show --!
Iii. In-depth follow-up on the DEDECMS global variable Registration VulnerabilityReally understand the $ _ GET variable, we come to follow up the real cause of this vulnerability, simulate the whole process of the vulnerability: Submit a nested array: http://www.bkjia.com/test. php? _ POST [GLOBALS] [pai_dbname] = X array (1) {["_ POST"] => array (1) {["GLOBALS"] => array (1) {["pai_dbname"] => string (1) "X" }}if the data is passed into the DEDECMS program, filter the data at the first layer, DEDECMS checks whether there are any global variable keywords in $ _ REQUEST, but our KEY is _ POST and an array, so it is easy to bypass. Foreach ($ _ REQUEST as $ _ k => $ _ v)
{
If (strlen ($ _ k)> 0 & eregi ('^ (cfg _ | GLOBALS)', $ _ k ))
{
Exit ('request var not allow! ');
}
} Then go to the real variable registration process. the variables are first registered from $ _ GET in order, and our KEY is (_ POST ), the first round of traversal $ _ GET successfully registers the variable $ _ POST, and the second round of traversal $ _ POST successfully registers the variable $ GLOBALS! Foreach (Array ('_ get',' _ Post', '_ COOKIE') as $ _ request)
{
Foreach ($ _ request as $ _ k = >$ _ v) $ {$ _ k} = _ RunMagicQuotes ($ _ v );
} Here the cause of the vulnerability is clear. The program registers $ _ POST through $ _ GET, and registers $ GLOBALS through $ _ POST!
4. fix vulnerabilities after understanding themAfter you fully understand this vulnerability, you will know how to fix it. 1. You can see how DISCUZ is done. If the first character of the KEY exists _, the variable is not registered. Foreach (array ('_ cookies',' _ Post', '_ get') as $ _ request ){
Foreach ($ _ request as $ _ key => $ _ value ){
$ _ Key {0 }! = '_' & $ _ Key = daddslashes ($ _ value );
}
} 2. You can use the following method to temporarily fix DEDECMS. When you traverse $ _ POST to register a variable and find that the variable name exists in GLOBALS, the registration of the variable will be blocked.
Foreach (Array ('_ get',' _ Post', '_ COOKIE') as $ _ request)
{
Foreach ($ _ request as $ _ k => $ _ v ){
If (strlen ($ _ k)> 0 & eregi ('^ (cfg _ | GLOBALS)', $ _ k )){
Exit ('request var not allow! ');
}
$ {$ _ K} = _ RunMagicQuotes ($ _ v );
}
}
PS: security is the foundation and must be understood.
