Сериализация (не) cookie в Laravel 5.5.42 - PullRequest
0 голосов
/ 24 августа 2018

Релиз безопасности 5.5.42 «отключает всю сериализацию / десериализацию значений cookie» - https://laravel -news.com / laravel-5-6-30 Но у меня все еще сериализуются мои значения, только несериализации.В то время как я

Cookie::get('key')

я получаю что-то вроде

"s:5:"value";"

Настройка protected static $serialize = true; в App \ Http \ Middleware \ EncryptCookies помогает, и так же

unserialize(Cookie::get('key'))

Но, как я понимаю, сама проблема unserialize () является источником проблемы с этим выпуском безопасности, а не тем, что я делаю с несериализованным значением позже, так что это своего рода превосходит цель обновления.Почему мои файлы cookie сериализуются здесь и как это исправить?

1 Ответ

0 голосов
/ 24 августа 2018

На самом деле стоит ответа, так как сам вопрос довольно интересен.

С точки зрения 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";}

С учетом вышесказанного, я настоятельно рекомендую прочитать (даже кратко) об уязвимостях сериализации / неназначения.

Если вы используете надлежащий фреймворк, обычно большинство забот о безопасности будут заботиться о вас, если вы не сделаете все возможное, чтобы внедрить какую-то уязвимость, и вы будете придерживаться стандартов фреймворка.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...