На самом деле стоит ответа, так как сам вопрос довольно интересен.
С точки зрения Laravel это не проблема cookie, а проблема APP_KEY
ключа конфигурации в сочетании с сериализацией / десериализацией.
Соответствующая цитата из документов:
Однако, если ключ шифрования вашего приложения находится в руках
злоумышленник, эта сторона может создать значения cookie, используя
ключ шифрования и эксплойты, свойственные объекту PHP
сериализация / десериализация, например, вызов произвольного класса
методы в вашем приложении.
Соответствующая часть это vulnerabilities inherent to PHP object serialization / unserialization
.
Обычно форма взрыва - Инъекция объектов (по крайней мере, самая распространенная).
У OWASP есть очень хороший пример здесь .
Даже на php.net есть красное предупреждение за функцию unserliaze .
Warning
Do not pass untrusted user input to unserialize()
Cookies приходят от пользователя, и пользователям НЕ ДОЛЖНО доверять.
Поскольку пример в порядке, я просто оставлю здесь также OWASP:
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...
В этом примере злоумышленник может удалить произвольный файл по пути Атака обхода , например, например. запрашивая следующий URL:
http://testsite.com/vuln.php?data=O:8:"Example1":1:{s:10:"cache_file";s:15:"../../index.php";}
С учетом вышесказанного, я настоятельно рекомендую прочитать (даже кратко) об уязвимостях сериализации / неназначения.
Если вы используете надлежащий фреймворк, обычно большинство забот о безопасности будут заботиться о вас, если вы не сделаете все возможное, чтобы внедрить какую-то уязвимость, и вы будете придерживаться стандартов фреймворка.