Безопасно ли сериализовать и unserialize массив $ _POST?

Question

TLDR: Безопасно ли сериализовать массив $ _POST в файл, а затем прочитать его обратно в переменную $ _POST с другим запросом или другим скриптом?

Я понимаю, что это необычно. Для этого есть причина, и для того, чтобы объяснить, почему я рассматриваю возможность делать это в специальном случае, по крайней мере, в то же время потребуется десяток страниц текста.

сводились процесс:

file_put_contents('sample.post', serialize($_POST)); 

$_POST = unserialize(file_get_contents('sample.post')); 

У меня уже есть обширные фильтрации в месте для фактического содержания переменной пост. Мой вопрос заключается в том, приводит ли процесс сериализации и нессериализации всего массива $ _POST, позволяя злоумышленнику использовать метод атаки.

В документе PHP говорится: «Предупреждение. Не пропускайте недоверенный ввод пользователя в unserialize(). Несериализация может привести к загрузке и выполнению кода из-за создания экземпляра объекта и автоматической загрузки, и злоумышленник может использовать это».

Я нашел эти статьи, описывающие этот метод атаки. Но они, похоже, зависят от того, что пользователь может указать строку для несериализации напрямую, IE unserialize ($ _ POST ['value']).

https://www.notsosecure.com/remote-code-execution-via-php-unserialize/ https://heine.familiedeelstra.com/security/unserialize

Я правильно, что до тех пор, как я сериализации и десериализации, объекты не могут быть созданы в процессе десериализации, не так ли?

У меня создается впечатление, что массив $ _POST будет содержать только строки (хотя я не мог найти это явно упомянутое в документах PHP).

Как я понимаю, даже если кто-то поставляет строку, соответствующую формату сериализованного объекта, он будет «храниться» как строка во время сериализации с явной длиной (длина байта). Таким образом, он будет просто назначен как строка при несериализации. Кажется, что, поскольку длины строк хранятся вместе с ними во время сериализации, вы не можете сломать структуру сериализованной строки из ввода, как вы могли бы с SQL-инъекцией. Я попытался обмануть его некоторыми недопустимыми многобайтовыми символами, но не повезло. Однако я не могу этого сделать, и опытные хакеры, способные это сделать, - это две разные вещи.

Я не нашел ничего другого о других методах атаки.

Пожалуйста, дайте мне знать, если я что-то упустил! Я просто прочитал несколько комментариев, говоря: «Вы никогда не должны этого делать», поэтому я нервничаю, что что-то не понимаю.

Answer 1

Я думаю, что без дальнейших атак можно отправить что-то как переменную POST, чтобы использовать вызов unserialize() позже в вашем сценарии, но у других, возможно, есть идея. Это может быть проблемой, если $ _POST имеет что-то unserializable, но я думаю, что это может не произойти. Все, что было в $ _POST, это было уже в памяти один раз, так что при условии serialize() и unserialize() работу правильно, он должен быть безопасным, чтобы сделать что-то вроде

$serialized = serialize($userinput); 
unserialize($serialized); 

Однако вы сохраняете эти данные на диск между ними. После использования другого недостатка и доступа к вашим файлам (или имеющего доступ «по дизайну», например, персонал ИТ-отдела), злоумышленник может модифицировать сохраненные сериализованные данные и может вводить туда свою атаку. Таким образом, это, очевидно, было бы уязвимым.

Так что это действительно риск, хотя, может быть, и не очень высокий. Имейте в виду, что безопасность этого решения во многом зависит от безопасности сохраненного сериализованного контента.