PHPのunserialize関数に外部由来の値を処理させると脆弱性の原因になる

既にいくつかの記事で指摘がありますが、PHPのunserialize関数に外部由来の値を処理させると脆弱性の原因になります。 しかし、ブログ記事等を見ていると、外部由来の値をunserialize関数に処理させているケースが多くあります。 ユースケースの一例としては、「複数の値をクッキーにセットする方法」として用いる場合です。 PHP クッキーに複数の値を一括登録する方法という記事では、以下の方法で複数の値をクッキーにセットしています。 $status = array( "height" => 167, "weight" => 50, "sight" => 1.2 ); setcookie("status", serialize($status)); クッキーの受け取り側は以下のコードです。 print_r(unserialize($_COOKIE['status'])); 出力結果は以下

[PowerEdge]

なーんか不安だったから最近はjson_encode/json_decodeを使うようになってたわ

[todesking]

便利

[rgfx]

うわーまためんどくさい所に脆弱性が。他の環境でも処理系揃ってるjsonが安定すな。

[k-holy]

サーバ側キャッシュ用途くらいでしか使わないけど、cookieでの使用例が結構あるのね…JSONと違ってそのままバリデーションするのが難しいから厄介だと

[Kenji_s]

「一見大丈夫と思える箇所であっても、脆弱性の発生原因箇所に対して局所的に脆弱性を解消しておくことで、アプリケーション全体の安全性を高めることができます」

[Dai_Kamijo]

こちらで説明した脆弱性そのままだった / “Welcart 1.9.4 をリリースしました【脆弱性の修正】” https://t.co/JRANkcfbo7 — 徳丸 浩 (@ockeghem) September 18, 2017 from Twitter https://twitter.com/Dai_Kamijo September 19, 2017 at 09:23AM via IFTTT

[shinbash]

PHPのunserialize関数に関する脆弱性。関数の内部処理まで意識しないといけないとか、無理ゲーでしょ…。他に関数に変えてもイタチごっこになるんだろうな。

[Haaaa_N]

HaskellのreadもunsafePerformIOや無限再帰があるので人事ではないな

[deep_one]

「信頼できないデータは無害解する」→「無害化する」／めんどくさいのでunserializeを使うという発想がなかった（笑）

[t-tanaka]

なんか，JavaのRMIとかでも攻撃が成立しそうな気がする・・・

[kuracom]

「serialize/unserializeの代わりに、implode/explodeやjson_encode/json_decodeを用いる」

[hundret]

徳丸浩の日記: PHPのunserialize関数に外部由来の値を処理させると脆弱性の原因になる