Interpolique：SQLインジェクションとbase64エンコーディングを使用したXSSを透過的に防止するとどうなりますか？

Question

The Next HOPEでの基調講演の数年前に、Dan Kaminskyが Interpolique を発表しました（話は本当に楽しいです）。彼が提起した問題は、SQLインジェクション、クロスサイトスクリプティング（XSS）、およびその他のインジェクションの脆弱性を含む、インジェクション攻撃からどのように防御するかでした。たとえば、Unicodeはエスケープ文字を役に立たなくし、準備されたステートメントはPITAです。

彼の修正は、転送中に文字列をbase64に変換することでした。たとえば、SQLでは、decode64 eval（）でSQL呼び出しを単純に埋め込むことができます。準備されたステートメントよりもはるかに簡単で、DBのパフォーマンスへの影響は（あるとしても）少なく、DBのユーザーには透過的です。ネイティブ言語の実装により、プログラマーは透過的に使用でき、サーバーのパフォーマンスに関してほぼ同じ速度で実行できます。同様の手法を適用して、XSSを防御できます。しかし、その時に書かれたいくつかのブログ記事以外では、どこにもそれについての言及はありません。

どうした？

D.W. · Accepted Answer

まとめ。Interpoliqueはいくつかの理由で成功しなかったと思います。重要な理由の1つは、おそらくInterpoliqueが正確に正しい問題を解決していなかったためであり、同様のまたはより優れた特性を持つ他の多くの同様のアプローチが宇宙に存在していることです。別の考えられる理由は、最適な方法で販売されていなかった可能性があることです。また、市場の需要と収益化の難しさが大きな役割を果たしたのではないかと思います。

背景。Interpoliqueは、インジェクション攻撃を防御するための一般的なアイデアです。インジェクション攻撃は幅広い種類の脆弱性です。最も身近な例は、SQLインジェクションとXSSです。

カミンスキーのスライドは、ほとんどの時間をSQLインジェクションについて語っていますが、InterpoliqueがSQLインジェクションに関するものであるか、主にSQLインジェクションに関するものであると仮定するのは間違いだと思います。 Kaminskyは、SQLインジェクション防御のコンテキストでInterpoliqueを説明することから始めます。ただし、（SQLインジェクションのコンテキストで）基本的なアイデアを紹介した後、彼はそれがXSSおよびその他のインジェクション攻撃にどのように適用されるかを説明します。おそらく彼はこの方法で議論を教育的なデバイスとして組み立てたのではないかと推測します。SQLインジェクションなどの単純な設定でアイデアを説明する方が、一般化する方法を説明する前に説明する方が簡単だからです。

また、Interpoliqueがインジェクション攻撃からの防御に関する一連の作業の1つのステップであることを知ることも役立ちます。これの前にBEEP（ひどく壊れていた）があり、次にブループリント（Interpoliqueと多くの類似点を共有し、多くの長所と短所があります）が続きます。

正しい問題を正確に解決していません。最も一般的なレベルで、Interpoliqueは安全な文字列補間問題を解決しようとしています。これはが解決する正しい問題です。文字列補間のセキュリティ問題は、さまざまなインジェクションの脆弱性の原因です。しかし、Interpoliqueの目新しさは、間違いなく最も重要な部分ではない部分にあります。

安全な文字列補間の問題に対処するには、対処する必要のある多くの問題があります。信頼できないデータをどのようにエスケープまたはエンコードして、制限されているはずのコンテキストから抜け出せないのでしょうか。信頼できないデータが挿入されているコンテキストを確認するにはどうすればよいですか？そのコンテキストで使用する適切なエスケープ/エンコード関数を知るにはどうすればよいですか？ソリューションをWebアプリケーションフレームワークにどのように統合しますか？それを使用する方法について開発者をどのように教育しますか？

インターポリクの最も斬新な側面は、信頼できないデータをエンコードしてそのコンテキストから抜け出せない方法です。 Interpoliqueのアプローチには、base64エンコーディングが含まれます。base64エンコーディングは、データをエンコードするという問題に対するエレガントで堅牢なソリューションであるため、コンテキストから逃れることができません。ただし、その問題は解決するべき最も重要な問題ではありません。その問題を解決する標準的な方法は、エスケープすることです。そして、実際には、信頼できないデータが挿入されているコンテキストに対して適切なエスケープ関数を使用している限り、エスケープは十分に機能するようです。たとえば、HTMLに入るテキストの場合はencodeForHTML、次の場合はencodeForURL URLコンテキストに入るデータなど。エスケープ関数は標準化されており、かなり信頼できるようです。

したがって、Interpoliqueが競合するアプローチよりもはるかに優れていることは明らかではありません。その目新しさは、間違いなく、問題のそれほど重要ではない側面の1つに焦点を当てています。 Interpoliqueの特別なソース（base64エンコード部分）が他の可能なアプローチよりもユーザーに多くの利点を提供することは明らかではありません。

取り組むべき最も重要な課題は、フレームワークの統合とアウトリーチであるように思われます。これを開発者が使用するWebアプリケーションフレームワークに統合し、その使用方法を開発者に教えることです。状況依存自動エスケープのテクノロジーはかなりよく理解されており、最も難しい課題は、それを広く使用されているフレームワークに組み込むことです。

残念ながら、それは私がInterpoliqueプロジェクトから多くの努力を見たものではありません。これには多くのエルボーグリースが必要です。各フレームワークを保守する人々とのコミュニケーション、利点の明確化、アイデアをフレームワークに統合するためのコード/パッチの作成、彼らと協力して受け入れ可能なソリューションを考案するなど。 Interpoliqueプロジェクトが本当にそれを非常に強く推進したかどうかはわかりません。

マーケティング。Interpoliqueが、通常のWebアプリケーション開発者がその利点を理解できる方法で販売されたかどうかはわかりません。その利点は、セキュリティの研究者には明らかですが、Webアプリケーションを構築する人々、またはWebフレームワークを維持する人々はどうでしょうか。はっきりしない。

カミンスキーのスライドは、SQLインジェクションに重点を置いています。これは教育学的観点からは理にかなっているかもしれませんが、振り返ってみると、それはコミュニケーションの観点からの戦術的なエラーだったのではないかと思います。 SQLインジェクションにはすでに「十分な」ソリューションがあります。 SQLインジェクションに焦点を合わせたことで、「SQLインジェクションがかなりうまく制御されていると感じているのに、なぜこれが必要なのか？」潜在的な採用者が利点を認識しない場合、彼らはおそらく技術をあまり受け入れないでしょう。

限られた市場需要。さらに、ほとんどの開発者にとって、セキュリティは二次的な考慮事項です。セキュリティが主な目的ではない場合、セキュリティの小さな部分に対応するポイントスキームを販売することはそれほど簡単ではありません。おそらく、潜在的なセキュリティ問題をすべて解決する包括的なスイートを販売できれば、開発者はもっと興味を持つようになるかもしれませんが、それはInterpoliqueがそうであったことではありません。

セキュリティが大した問題ではないというこの認識に寄与しているのは、多くのアプリケーション開発者が問題があるとは考えておらず、解決策の必要性を認識していないということです（その多くはおそらく自分自身をだましているかもしれませんが、そうなります）。そして、XSSを知っているの開発者の多くは、注意するだけでそれを回避できると考えています（これは疑わしい命題ですが、もし彼らがスキーム、彼らはそれを買うつもりはない）。

いずれにせよ、Interpoliqueのようなものからどのようにお金を稼ぐかは明確ではありません。通常のカテゴリには分類されません。ツールではありません。サービスではありません。これはセキュリティに対する包括的なソリューションではありません。むしろ、さまざまなWebフレームワークを改善する方法のアイデアです。 Interpoliqueを顧客の手に渡すには、それをそれらのフレームワークに統合する必要があります。ただし、これらのフレームワークは通常無料です。だからあなたはどうやってそれからお金を稼ぐのかわかりません。ライブラリまたはアイデアをどのように収益化しますか？ビジネスモデルはどこですか？おそらく、Interpoliqueの人々はお金を稼ぐ方法を持っていましたが、Interpoliqueの成功の欠如の一部は、アイデアからお金を稼ぐ明確な方法がなかったためだと思います。

Interpoliqueの貢献：XSS。Interpoliqueのメリットに戻りましょう。個人的には、その主な貢献はXSS（おそらく他のインジェクション攻撃も同様ですが、最も顕著なのはXSS）に対する防御に役立つと思います。これはかなり賢い手法ですが、開発者はそれを適切に使用する方法を理解し、信頼されていないデータをHTMLに挿入するすべての場所でInterpoliqueを使用することを覚えておく必要があります。自動的に行われ、開発者の注意を必要とせず、開発者がエスケープ関数の呼び出しを忘れた場合のエラーの影響を受けにくい状況依存自動エスケープと比較してください。

カミンスキー氏の講演では、SQLインジェクションを防ぐためにInterpoliqueを使用する方法について説明していますが、これは主に教育的なデバイスだと思います。 Interpoliqueはインジェクション攻撃に対する一般的な防御策であり、SQLインジェクションとXSSはその2つの例です。 SQLインジェクションはXSSよりも理解しやすく、理解も簡単なので、SQLインジェクションのコンテキストでInterpoliqueの背後にあるアイデアを説明するのは、XSSよりもおそらく簡単だったでしょう。

インターポリクとSQLインジェクション。他の人が言ったように、準備されたステートメントは実用的なSQLインジェクションの「十分な」ソリューションです（実際にいくつかのケースがあります）これらは準備されたステートメントでは処理されませんが、エスケープ/検証と注意深いコード監査によって処理される可能性があるため）、Interpoliqueが最も役立つ場所ではありません。

準備されたステートメントにはいくつかの制限があることに気づきました。 Dan Kaminskyがよく説明している制限の1つは、複数の動的な値を長いテンプレートに補間する場合、構文が理想的とは言えないことです。どのパラメーターがどこに行くかを追跡するのは困難です。ただし、実際には、これは見事なものではないようです。開発者が対応しているようです。準備されたステートメントのもう1つの制限は、動的なORDER BYまたはLIMITステートメントなど、適用できないまれなケースがあることです。ただし、これらの制限はどちらも実際には準備されたステートメントでは深刻な問題とは思われないため、Interpoliqueが準備されたステートメントよりもはるかに優れているとは思いません。また、準備されたステートメントには、シンプルで、ほぼすべてのフレームワークでサポートされ、開発者に十分に伝道できるという利点があります。

カミンスキーが脱出を批判したのはなぜですか？これが起こっていることです。信頼できないデータを文字列に挿入する前にエスケープする場合は、文字列の受信者がデータをどのように解釈するかを知って、エスケープする必要のある文字を決定する必要があります。受信者がそれをASCIIとして解釈すると思っても、実際には受信者がそれをUTF-8として処理する場合、問題が発生します。おそらく、必要なすべてをエスケープすることはできないでしょう。

この種のことにより、過去にPHP/MySQL Webアプリケーションに脆弱性が導入されました（ここでは別の例）、信頼できないデータをエスケープしてからSQLクエリに挿入しようとしたときに、データベースが予想とは異なる文字エンコーディングを使用していたことに気付かない。 PHPアプリとMySQLデータベースの間に統合がないため、これは特にPHP/MySQL Webアプリケーションに関連します。PHPの簡単な方法はありません。 MySQLデータベースがこの接続で使用する文字エンコーディングを通知するコードなので、使用する必要のあるエスケープ関数を簡単に通知する方法はありません。

開発者は時々間違ったエスケープ関数を使用するため、手動でエスケープするとエラーが発生しやすくなり、セキュリティホールが発生します。

一方、XSS防止については、Webフレームワークへの十分な統合により、これらの問題に対処できます。フレームワークは、HTMLドキュメントがどの文字エンコーディングであるかを通知でき（Content-Encoding:ヘッダーを送信するため、また、HTMLドキュメント自体を解析できるため）、十分な機能を備えているため、信頼できないコンテンツのHTMLコンテキストを通知できます内挿されています（HTMLタグ内？属性内？URL？など）。その結果、十分にインテリジェントなWebフレームワークが与えられると、フレームワークは使用する必要のあるエスケープ関数を自動的に決定し、自動的に適用できます。これは状況依存自動エスケープの背後にある前提であり、それがカミンスキーの批判に対処する方法です。

この領域の未来。最も取り上げられているこのスペースのセキュリティテクノロジーは、コンテキスト認識自動エスケープです、など、Googleのctemplate に実装されています。これが、将来に向けて最も刺激的で有望な方向だと思います。お金を稼ぐビジネスチャンスはあまりありませんが、Webアプリケーションをより安全にし、開発者が安全な問題を回避するのに役立つ大きな違いができると思います。

状況依存自動エスケープには、開発者による追加の手順や認識なしに、XSS automatically に対する防御のためのフレームワークサポートが含まれます。これは、Interpoliqueが提供するものを超えるステップです。したがって、状況依存の自動エスケープは、開発者にとってInterpoliqueよりも優れています。これは、ほとんどの状況で、開発者による追加の作業が不要なので、エスケープが自動的に行われるためです。セキュリティにも優れています。エスケープはデフォルトで行われるため、デフォルトで安全なシステムになります。

もちろん、Interpoliqueのアイデアを状況依存の自動エスケープと組み合わせることができます（標準的なエスケープの代わりにInterpoliqueのbase64エンコーディングを使用）。そうすることの利点は私には完全には明らかではありません。

次の質問で説明されているInterpoliqueおよび類似のテクノロジーを見つけることができます。 DOM要素をホワイトリストに登録してXSSを無効にする、 JavaScript定数のエスケープ。

結論。Interpoliqueは美しくエレガントなアイデアであり、Webアプリケーション開発の将来に影響を及ぼし続けているのではないかと私は信じています-直接採用されない場合。少なくとも、状況依存の自動エスケープに向けた動きや、開発者が一般的な脆弱性を回避するのに役立つその他の手法のより広い文脈の中で理解できます。

rook · Answer

すごい誰かがすべての脆弱性を防ぐ方法を発見しました。今度はすべてのアプリケーションをゼロから書き直す必要があります...私はそのような主張に警戒します。

これをバラバラにしましょう...

では、実際にはbase64とは何でしょうか？これは、データをバイナリセーフな方法で表現する方法です。 _',",\,0x00_などの制御文字を避けるために、データを制限された文字セットで表現しています。したがって、SQLクエリのように、この文字列がシンク内で使用されるときはいつでもこれを利用するには、エンコードする必要がありますが、すべての文字列をbase64として処理することは意味がありません。ナンセンスで無駄なリソース：if($str==base64encode('start')){...}。では、addslashes()のようなサニタイズ関数を使用しないでください。これは、データをバイナリセーフな方法で表す方法でもあります。 パラメータ化されたクエリがSQLインジェクションの問題を完全に解決するため、これらの関数は両方ともSQLインジェクションへの恐ろしいアプローチです。

では、XSSはどうでしょうか。まあ、ユーザーにメッセージを表示するためにbase64にすることはできません！。したがって、この方法ではXSSを防ぐことはできません。 XSSは出力の問題であり、ユーザー出力がHTML内のどこにあるかに大きく依存するため、単一の関数ですべてのXSSを防ぐことはできません。

そうは言っても、base64は、幅広いシンク関数で使用されるユーザー入力をエンコードするための便利なツールです。ファイル操作、コマンドライン、SQLクエリを含みますが、これらに限定されません。これは、アプリケーションの欠陥にパッチを適用するために人々が定期的に使用する多くのツールの1つです。 XSSを防ぐためにbase64が使用されることはほとんどありません。実際にbase64がこのように使用されるのを見たことはありません。