Home >Backend Development >PHP Tutorial >PHP $_REQUEST array security risks_PHP tutorial

PHP $_REQUEST array security risks_PHP tutorial

WBOY
WBOYOriginal
2016-07-13 17:10:351341browse

Everyone knows that using $_REQUEST can directly eliminate the need to judge posts and get some codes, making it easier to use. However, if we want to think about it in detail, we will feel that $_REQUEST is too scary. See the analysis below.

We all know that to process form data, you can use PHP's two super-global variables $_GET and $_POST, which one is specified by the method when the form is submitted. In addition, PHP also provides us with the $_REQUEST array. But it not only contains all the data elements of $_GET and $_POST, but also contains all the data elements of the super-global array $_COOKIE.
But have you ever thought about it, if the keys in these three arrays are the same, then which array value do I get using $_REQUEST? Will there be any problems?
I use the following code to demonstrate for everyone. Because I just want to explain the problem, $_COOKIE is not set here. Please handle it yourself:

The code is as follows
 代码如下 复制代码
var_dump($_GET['a'],$_POST['a'],$_REQUEST['a']);
?>

demo

       

               
               
       


Copy code

      var_dump($_GET['a'],$_POST['a'],$_REQUEST['a']);

?>


demo

 代码如下 复制代码

; This directive describes the order in which PHP registers GET, POST, Cookie,
; Environment and Built-in variables (G, P, C, E & S respectively, often
; referred to as EGPCS or GPC).  Registration is done from left to right, newer
; values override older values.
variables_order = "EGPCS"

           

                                                                                                                                                                                                                                                                   

                                                                                                                                                                                                                                                              

                         


When I submit the form, the page content I get is:

string(3) "xxx" string(3) "yyy" string(3) "yyy"With the same content, in $_REQUEST, the POST value overwrites the GET value. What is going on? In fact, this is set in the PHP configuration file. Let’s take a look at the php.ini configuration file. There is the following content around line 466:
The code is as follows Copy code
; This directive describes the order in which PHP registers GET, POST, Cookie, ; Environment and Built-in variables (G, P, C, E & S respectively, often ; referred to as EGPCS or GPC). Registration is done from left to right, newer ; values ​​override older values. variables_order = "EGPCS"
This EGPCS illustrates the priority of using the $_REQUEST array to obtain content. The meanings of its letters are: E represents $_ENV, G represents $_GET, P represents $_POST, C represents $_COOKIE, and S represents $_SESSION. The data appearing later will overwrite the data written earlier. The default data writing method is EGPCS, so the data contained in POST will overwrite the data using the same keyword in GET. $_REQUEST[] has the functions of $_POST[] $_GET[], but $_REQUEST[] is slower. All data submitted through the post and get methods can be obtained through the $_REQUEST array http://www.bkjia.com/PHPjc/629664.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/629664.htmlTechArticleEveryone knows that using $_REQUEST can directly eliminate the need to judge the post and get some code, which is simpler to use, but If we want to think about it in detail, we will feel that $_REQUEST is too terrible. Check out the scores below...
Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn