* ライアン・ナレインは休暇中です。 ゲスト編集者: Nate McFetersホリデー シーズンが近づいており、寄付の精神がとても高まっているので、 共同研究者のビリーと一緒に発見した、セキュリティ問題の原因となる主な機能のリストをまとめてみようと思いました。 リオス。
* ライアン・ナレインは休暇中です。
ゲスト編集者: ネイト・マクフェターズ
ホリデー シーズンが近づいており、寄付の精神も高まっているので、共同研究者の Billy Rios と一緒に発見したセキュリティ問題につながる主な機能のリストをまとめてみようと思いました。
新年が近づいているので、これは開発者たちにいくつかのアイデアを思いつく機会を与えるはずです。 コンピュータという荒々しい世界で 1 年間過ごした教訓についての新年の抱負 安全。
Picasa のボタン インポート機能と内蔵 Web ブラウザ/サーバー
Google の Picasa には、URI からアクセスできるボタン インポート機能が含まれています。 この機能は実際には非常に便利です。 これにより、ユーザーはリンクをクリックしてボタンの XML 記述を Picasa にインポートでき、クリックすると画像が Tabblo または Flickr アルバムに投稿されます。 これは、アップロード前にユーザーの操作を必要とする Java アプレットを使用して行われます。
残念ながら、攻撃者はクロスサイト スクリプティング (XSS) を通じて URI にアクセスすることもできます。 攻撃者は、Picasa ユーザーを XSS し、DNS ピンニングを行わない Flash を読み込むことができます (これはリストに載っていないだけです)。 その後 対話や確認なしにユーザーの画像を盗む.
私は Picasa を使用して写真を修正していますが、Picasa に組み込まれている Web ブラウザと Web サーバーが気になって仕方ありません。 確かに、サーバーはローカル ループバックにバインドされていますが、前述したように、Picasa の内蔵ブラウザにロードされた Flash を通じてアクセスできます。 内蔵ブラウザにロードした Flash を使用して内蔵サーバーも攻撃する可能性があり、さらなる脆弱性が発生する可能性があります。
ローカル ループバックで Web サーバーを起動するのは、Google デスクトップと同様に Google の設計パターンのようです。 機能の観点から見ると、これはアプリケーションを拡張するための豊富な環境を提供する可能性があります。 目の前のタスクを考慮することが重要です。写真編集に使用されているアプリケーションの場合、サービスを実行する正当な理由を見つけるのは困難です。
Googleドキュメント
ここで Google を取り上げるわけではありません (実際、Google には優れたセキュリティ チームがいます) が、Google ドキュメントの概念については彼らと話し合ったことがなかったはずです。 セキュリティリスクが大きくない場合 Googleが所有権を取得 あなたの文書で、ビリーと私はいくつかの穴を発見しました。 攻撃者があらゆる文書を盗むことを許可する の「doc_id」は推測できますが、これは実際には予測可能な値です。
人々に優れた機能を提供する機能豊富なアプリケーションは素晴らしいですが、プライバシーへの影響は 機密性の高い文書を何百万人もの人がアクセスできる Web アプリケーションの手に渡すことは、 記念碑的な。 おそらく、より良い解決策は、オフライン編集を行ってドキュメントをローカルに保存するオプションをユーザーに提供することだったでしょう。
「firefoxurl」URI と「-chrome」引数
firefoxurl URI は基本的に Firefox を開き、URL を指します。 これは、攻撃者が同じ URI を介して XSS 攻撃ベクトルを通じて firefox.exe のインスタンスを起動し、コマンド ラインに値を渡すことができることを意味します。 これらの値はサニタイズされていないため、攻撃者は現在の引数を二重引用符で区切って追加のコマンド ライン引数を挿入する可能性があります。
これだけでは大きな懸念にはならなかったかもしれません。 ただし、Firefox は -chrome 引数も受け入れます。これにより、任意の chrome JavaScript コードを Firefox に渡すことができます。 これにより、任意のコマンドを実行できるようになります.
これらの機能は通常のユーザーには必要ないようです。 これが必要な機能である場合、ユーザーが指定した入力を渡す前に、ある程度のサニタイズが行われるべきでした。
トリリアンの「目的」URI
"持続する。 ini 引数 書きます 指定したファイルに?!」 それは、数か月前の IM セッションでビリーが私に尋ねたことです。 「はい、ファイルの書き込み先を制御できます」と私は答えました。 「コンテンツを書き込んでもいいですか？」 ビリーは尋ねた。 "いいえ！ それはクレイジーだ」と私は答えた。
間違っている！ スタートアップフォルダーへのバッチスクリプトとしてなど、任意のコンテンツを任意のファイルに書き込むことができました。 一見無害に見えるこの オプションにより XSS を介したコマンド インジェクションが発生しました. この機能はアプリケーションにハードコーディングされるべきでした。 同じURIであることが判明しました スタックオーバーフローに対して脆弱 ユーザーが URI から指定した入力は境界チェックされなかったためです。
さて、今年私たちはどんな教訓を学んだでしょうか？ そうですね、機能の数は攻撃対象領域の量に直接比例します。 URIの悪用、XSS を通じて悪用される可能性があるため、さらに悪いことになります。 これらの欠陥の一部はセキュア SDLC プロセス中に発見されるべきでしたが、これらを実行していない企業が増えているのは驚くべきことです。
XSS により、内部マシンのスキャンや攻撃、メモリ破損の問題やコマンド インジェクションの悪用、データ盗難が可能になることを考えると、無視することはできません。 XSS は問題ではないと主張することは、地球温暖化が問題ではないと信じることに似ています。
すべてのアプリケーションが安全な設計レビューを通過するまでには長い道のりがあります。 セキュリティが機能よりも勝つ日はさらに遠いです。
* Nate McFeters は、Ernst & Young の Advanced Security Center のシニア セキュリティ アドバイザーです。 彼は、フォーチュン 500 企業のいくつかのクライアントに対して、Web アプリケーション、ディープ ソース コード、インターネット、イントラネット、ワイヤレス、ダイヤルアップ、およびソーシャル エンジニアリング業務を実行してきました。