安全版本5.5.42“禁用cookie值的所有序列化/反序列化”-https://laravel-news.com/laravel-5-6-30 但是我仍然将我的值序列化，只是未序列化。当我这样做
Cookie::get('key')
我得到类似
"s:5:"value";"
在App \ Http \ Middleware \ EncryptCookies中设置protected static $serialize = true;会有所帮助，
unserialize(Cookie::get('key'))
但是，据我所知，unserialize（）本身是此安全发行版问题的根源，而不是我稍后对未序列化的值所进行的处理，因此，这超出了更新的目的。 为什么我的Cookie在这里被序列化以及如何解决？
答案 0 :(得分：0)
这实际上是一个值得回答的问题，因为问题本身很有趣。
从Laravel的角度来看，这不是cookie问题，而是结合序列化/反序列化的vulnerabilities inherent to PHP object serialization / unserialization配置密钥问题。
文档中的相关报价：
但是，如果您的应用程序的加密密钥在 恶意方，该方可以使用 PHP对象固有的加密密钥和利用漏洞 序列化/反序列化，例如调用任意类 应用程序中的方法。
相关的部分是这个Warning
Do not pass untrusted user input to unserialize()。
通常，explot的形式是对象注入（至少最常见）。
OWASP有一个很好的例子here。
即使php.net也有红色警告for it's unserliaze function。
class Example1
{
public $cache_file;
function __construct()
{
// some PHP code...
}
function __destruct()
{
$file = "/var/www/cache/tmp/{$this->cache_file}";
if (file_exists($file)) @unlink($file);
}
}
// some PHP code...
$user_data = unserialize($_GET['data']);
// some PHP code...
Cookie来自用户，并且用户不受信任。
因为有一个示例，我也将OWASP放在这里：
http://testsite.com/vuln.php?data=O:8:"Example1":1:{s:10:"cache_file";s:15:"../../index.php";}
在此示例中，攻击者可能能够通过路径Traversal attack删除任意文件，例如请求以下网址：
{{1}}
话虽如此，我强烈建议（甚至简要地）阅读有关序列化/非序列化漏洞的信息。
如果您使用的是适当的框架，通常，如果您不竭力引入一些漏洞并遵守框架的标准，那么大多数安全事项都将得到照顾。
答案 1 :(得分：0)
效率较低，但对于结构化数据，我将序列化/反序列化替换为 json_encode/json_decode。