データベースに悪意のあるコードを格納する - エスケープ時の出力は常に正しい方法ですか？

Question

ここでの考え方を理解し、この問題に対する正しい、受け入れられたアプローチに到達したい。コンテキストの場合、これはWeb環境にあり、データベースへの入力を逃れることについて話しています。

私は、ユーザー入力を受け取り、データベースに格納するときに入力をエスケープしない理由の多くを理解しています。その入力をさまざまな方法（JSONなど、SMSなど）で使用し、その入力を元の形式でユーザーに表示したい場合もあります。

データベースに何かを入れる前に、データベースを保護するSQLインジェクション攻撃がないことを確認します。

しかし、following the principals set out hereとhereは、ユーザー入力をそのまま保存する方法を示しています。このユーザー入力はSQLインジェクション攻撃ではない可能性がありますが、他の悪質なコードである可能性があります。このような場合、JavascriptベースのXSS攻撃をデータベースに保存することはできますか？

私の前提が正しいかどうかだけを知りたいのですが、その悪質なコードがデータベースに直接影響しない限り、悪意のあるコードをデータベースに格納しても問題ありませんか？データベースの問題ではないのですか？悪質なコードの落とし穴を避けるために、この悪質なコードとその出力デバイスを保持することができますか？

また、これらのプリンシパルよりも多くのエスケープを行う必要がありますか？出力上のエスケープの前にセキュリティ上の懸念がありますか？データベースに悪意のあるコードが入らないようにする必要がありますか？とにかく悪意のあるコードを保存したいのはなぜですか？

ウェブクライアント/サーバー環境のコンテキストで悪質なコードをデータベースに保存する正しい方法は何ですか？

[Iは、特にコードはそれらに共有することを可能にする任意のサイトを無視しています。この目的のため、私は、そのような名前、コメントや説明フィールドとして「通常」の入力を考えています。]

Answer 1

定義：Iフィルタまたはエスケープの代わりに「サニタイズ」という用語を使用します.3番目のオプションは無効な入力を拒否するためです。たとえば、「文字titleがタイトルに使用されない可能性がある」というエラーをユーザーに返すと、まったく保管する必要がなくなります。ユーザー入力を保存

であるとして「多層防御」のセキュリティ原則は、あなたが早ければ、多くの場合、可能な限りあらゆる潜在的な悪意のある入力をサニタイズすべきであることを示唆しています。アプリケーションに役立つ値と文字列のみをホワイトリストに登録します。しかし、そうしても、これらの値をエンコード/エスケープする必要があります。

どうして私たちは悪質なコードを保存したいのですか？

パラノイアよりも正確さが重要な時があります。たとえば、ユーザーのフィードバックに潜在的な破壊的なコードを含める必要があります。私は、「あなたがwikiのタイトルの一部としてタイプ%00を使用するたびに、アプリケーションがクラッシュする」というユーザのフィードバックを書くことを想像することができます。 wikiのタイトルに%00文字が必要ない場合でも、コメントはそれらを正確に伝える必要があります。これをコメントで許可しないと、事業者は深刻な問題について学ぶことができません。参照：Null Byte Injection

出力デバイスまでの悪意あるコード

の落とし穴を避けるために、あなたが任意のデータを格納する必要がある場合は、任意の他の符号化タイプに切り替えると、正しいアプローチは脱出することです。デコード（エスケープ解除）してエンコード（エスケープ）する必要があります。バイナリでも少なくともBig-EndianまたはSmall-Endianであっても、エンコードされていないデータはありません。ほとんどの人は、言語の組み込みの文字列を「最もデコードされた」形式として使用しますが、UnicodeとASCIIを比較するときにはそれが不安定になることさえあります。 Webアプリケーションのユーザー入力は、URLエンコード、HTTPエンコード、または「Content-Type」ヘッダーに従ってエンコードされます。参照：http://www.ietf.org/rfc/rfc2616.txt

ほとんどのシステムでは、これがテンプレートやパラメータ化されたクエリの一部として実行されます。たとえば、Query("INSERT INTO table VALUES (?)", name)のようなパラメータ化されたクエリ関数を使用すると、単一引用符などの名前をエスケープする必要がなくなります。このような利便性がない場合は、のように、NewHTMLString(string)やDecode()のようなコンストラクタを使用して、エンコードタイプごとにデータを追跡するオブジェクトを作成すると便利です。

悪意のあるコードがデータベースに入力されないようにするべきでしょうか？

データベースは今後のすべてのエンコードを決定することができないため、すべての潜在的なインジェクションに対してサニタイズすることは不可能です。例えば、SQLとHTMLはバッククッキーを気にしないかもしれませんが、JavaScriptとbashは気にしません。

Answer 2

このユーザー入力はSQLインジェクション攻撃ではないかもしれませんが、 他の悪質なコードである可能性があります。このような場合、データベースにXSS攻撃に基づいた ベースのJavaScriptを保存することはできますか？

それは、ははあなたのユースケースによってはOKである可能性があります。理論的には、データベースは、それが格納するデータの使用法には無関心でなければならない。その結果、生データをデータベースに保存し、使用される出力メディアに応じて出力中にエスケープすることは合理的です。

私はちょうどここに私の仮定が正しければ、我々は長い間その 悪意のあるコードが直接データベースには影響を与えないように、データベースに悪質なコードを格納して、すべての 細かい知りたいですか？ データベースの問題ではありませんが、悪意のあるコード の落とし穴を避けるために、この悪意のあるコード とその出力デバイスを保持できますか？

データが「悪意のある」かどうかは、コンテキストとその使用方法に大きく依存します。たとえば、<script>...</script>というデータをHTML Webページにレンダリングすると、深刻な問題を引き起こす可能性があります。しかし、印刷された文書/レポートに表示される絶対に正当なペイロードと見なされる可能性があります。これは、データを生の形式で保存し、出力媒体に応じてエスケープする一般的な提案の背景にある理論的根拠です。あなたの質問に真っ直ぐに答えるには、すべての可能なメディアのためにすべてのエスケープ・メカニズムが整備されている限り、このデータをデータベースに格納することは絶対にOKです。

それとも我々はより多くのこれらの プリンシパルによって提案よりも、入力にエスケープやるべきこと - セキュリティ上の懸念が出力にエスケープ のアイデアの前に来るのでしょうか？私たちは悪意のあるコード がデータベースに入っていないというアプローチを取るべきでしょうか？とにかく悪意のあるコードを保存したいのはなぜですか？

サニタイズとエスケープの間には小さな違いがあります。前者は、無効なデータを格納する前にフィルタリングするプロセスを指し、後者は、選択された媒体に表示する前にデータを適切なフォーマットに変換することを指す。防御の原則に従えば、データを受け取ったときに、可能であれば、墨塗りの追加ステップを実行することができます。しかし、これを達成するためには、必要なデータの性質を知る必要があります。たとえば、電話番号が必要な場合は、<script>を含むデータを無効なデータとしてユーザーにフラグを立てることが理にかなっています。これは、レポートをプログラミング課題として期待した場合には必ずしも当てはまりません。だから、すべては文脈に依存している。