コーダーがセキュリティを征服:Share & Learn シリーズ-安全でないデシリアライゼーション

アプリケーションによっては、シリアル化のプロセスが常に行われることがあります。これは、データ構造やオブジェクトの状態が、保存や通信として送信できる形式に変換されるたびに使われる用語です。逆シリアル化はこのプロセスの逆で、構造化されたデータを格納前のオブジェクトまたはデータ文字列に戻します。
アプリケーションが逆シリアル化中のデータを信頼できるものとして扱うと、安全でない逆シリアル化が発生する可能性があります。ユーザーが新しく再構築されたデータを変更できれば、コードインジェクション、DoS 攻撃、あるいは単にデータを変更してオブジェクトの価格を下げたり、権限を昇格させたりするなど、あらゆる種類の悪意のあるアクティビティを実行する可能性があります。
このエピソードでは次のことを学びます。
- 攻撃者が安全でない逆シリアル化を悪用する方法
- 安全でない逆シリアル化が危険な理由
- この脆弱性を修正できるテクニック。
攻撃者は安全でない逆シリアル化をどのように悪用するか?
最近では、データをシリアル化するための最も一般的なデータ形式は JSON ですが、XML がそれに次ぐ形式です。かなりの数のプログラミング言語が独自の方法でデータをシリアル化していますが、その方法には JSON や XML よりも多くの機能が含まれていることがよくあります。いずれにしても、この連載の他のブログの古いモットーである「ユーザーの入力を絶対に信用してはいけない!」に従うのではなく、デシリアライズされたデータを信頼できる入力として扱うように開発者がアプリをプログラミングすると、問題が発生する可能性があります。
ユーザーがこれらの文字列にコードを挿入すると、受信サーバーで誤って実行されてしまう可能性があるため、ユーザー入力は決して信頼できません。また、デシリアライズされた未加工のデータにもアクセスされて悪用されることがあるため、これも信頼できないカテゴリに分類する必要があります。
たとえば、フォーラムアプリケーションが PHP オブジェクトのシリアル化を使用してユーザーの識別情報とロールを含む Cookie を保存する場合、それを操作できます。悪意のあるユーザーが、「ユーザー」の役割を「admin」に変更する可能性があります。あるいは、データ文字列の開口部を利用してコードを挿入することもできますが、サーバーが「信頼できる」データを処理する際に、そのコードを誤って解釈して実行してしまう可能性があります。
安全でない逆シリアル化はなぜ危険なのですか?
確かに、この種の攻撃にはハッカー側にある程度のスキルが必要であり、攻撃者が操作および逆シリアル化されたデータからサーバーがどのようなコードやエクスプロイトを受け入れるかを攻撃者が学習する間、試行錯誤が必要になることもあります。とはいえ、この脆弱性は悪用されがちです。というのも、この脆弱性を悪用できるほど熟練したハッカーに潜在的に威力を与える可能性があるからです。
逆シリアル化されたデータの使用方法によっては、以前のブログで取り上げた攻撃を含め、いくつでも攻撃を仕掛けることができます。安全でない逆シリアル化は、リモートクロスコードインジェクション、クロスサイトスクリプティング、サービス拒否、アクセス制御ハイジャック、そしてもちろん SQL や XML インジェクション攻撃への入り口となる可能性があります。これは基本的に、デシリアライズされるすべてのデータを信頼できるものとして宣言し、攻撃者が悪用を試みるきっかけとなります。
安全でない逆シリアル化の排除
安全でない逆シリアル化を防ぐために組織ができる最も安全なことは、アプリケーションが逆シリアル化されたデータを受け入れることを制限することです。ただし、このような攻撃を防ぐ方法は他にもあるため、これは不可能であるか、現実的ではないかもしれませんが、心配はいりません。
可能であれば、データを数値のようなものにサニタイズできます。これによって悪用が完全に阻止されるわけではありませんが、コードインジェクションは防げます。さらに良いのは、デジタル署名などの逆シリアル化されたデータに対して何らかの形式の整合性チェックを行うだけで、データ文字列が操作されていないことを確認できることです。また、デシリアライズ処理はすべて分離し、権限の低い環境で実行する必要があります。
これらの保護策を講じたら、失敗したすべての逆シリアル化試行と、データを逆シリアル化するコンテナまたはサーバーからのネットワークアクティビティを必ずログに記録してください。ユーザーがログでシリアル化解除エラーを 2 回以上発生させた場合は、そのユーザーが悪意のある内部関係者であるか、認証情報がハッキングされたり盗まれたりした可能性があると考えられます。逆シリアル化エラーを頻繁に引き起こすユーザーの自動ロックアウトのようなことを検討するかもしれません。
安全でない逆シリアル化に対処するためにこれらのツールのどれを使用するにしても、核となるのはユーザーによって触れたり操作されたりする可能性のあるデータであることを忘れないでください。決して信用しないでください。
既知の脆弱性を持つコンポーネントの使用に関する詳細情報
さらに読み進めるには、OWASPが何を言っているか見てみましょう 安全でない逆シリアル化について。また、新しく身につけた防御知識を、次の方法で試すこともできます 無料ショーケース サイバーセキュリティチームが究極のサイバー戦士になるためのトレーニングを行うSecure Code Warriorプラットフォームの。この脆弱性を打ち負かす方法や、その他の脅威を集めた不正行為のギャラリーについて詳しくは、 セキュア・コード・ウォリアーのブログ。
Govern AI-driven development before it ships
Measure AI-assisted risk, enforce secure coding policy at commit, and accelerate secure delivery across your SDLC.
Explore more blogs
これは、オーラが射手と鼻の穴を広げることによって、腸管を熱的に発芽させ、臭いを帯びていることを防ぐためのものです。
%252520%252520(3).avif)
Supercharged Security Awareness: How Tournaments are Inspiring Developers at Erste Group
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Security as culture: How Blue Prism cultivates world-class secure developers
Learn how Blue Prism, the global leader in intelligent automation for the enterprise, used Secure Code Warrior's agile learning platform to create a security-first culture with their developers, achieve their business goals, and ship secure code at speed

One Culture of Security: How Sage built their security champions program with agile secure code learning
Discover how Sage enhanced security with a flexible, relationship-focused approach, creating 200+ security champions and achieving measurable risk reduction.
Secure AI-driven development before it ships
See developer risk, enforce policy, and prevent vulnerabilities across your software development lifecycle.


