2018年はもうすぐです。 しかし、ほとんどのひげを生やした脆弱性は、開発中のシステムに存在し続けます。 そして、 OWASP Top-10 2017が登場したという事実にもかかわらず。 そして、特定のものの優先順位は大きく変わりました。 前と同じように、 2010年に関連した状況にぶつかるのを妨げるものは何もありません。
物語は、私の友人が働いている会社の製品に対する平凡な好奇心から始まりました。 製品は面白いです。 彼らはこの製品を非常に思慮深く購入し、6つの標識が付いた値札を購入します。 この会社には公式のバグ報奨金はありません。 しかし、私は何かを見つけたとしても、友人を通してそれを引き裂いて、それを渡すと思いました。
会社の主要製品を見つけることは難しくありませんでした。 デモアプリケーションのある公式サイトがあります。 そこに着いて、そこにあるものを確認し、同時にBurp Suitのプロキシを介してすべてのトラフィックをラップしました。
入力フィールドを見たとき、すぐにそこにxssを貼りたいと思いました。 行き詰まった平凡なベクトル
<script>alert(xss);</script>
そして、あなたは何が起こったと思いますか？ もちろんうまくいきました！
可能な入力フィールドも検索し、XSS攻撃はどこでも実行されました。 しかし、いや、嘘をついている！ 何らかの理由で、1つの場所で機能しませんでした。 しかし、しばらく時間を費やして、別のペイロードベクトルとシールドをバイパスすることでそれを克服することができました。 したがって、手元には少なくとも8つのxssベクトルがあります。 時々この数を増やすことは可能でしたが、システムの機能を回避することに時間を費やすことは非常に面倒でした。 はい。問題が複雑であることは明らかでした。
すでに、この不名誉に責任がある友人を通して、見に行きたかった。 しかし、シールドがすべて非常に悪い場合は、何か他のものがあると考えました。 彼は後で接触の可能性を脇に置き、見に登りました。
ログには、CSRF攻撃を実装する可能性があるアプリケーションを疑うヒントがありました。 つまり、このような攻撃の可能性を防ぐCSRFトークンはありませんでした。 私の恐怖を確認するために、実際の例が必要でした。 そして、できる限り責任を持って私のコメントに対応するために、システムへの最大の損害を示す例が必要でした。
CSRFについて少し説明しますが、グーグルで検索することもできます。
銀行のウェブクライアントにログインしているとします。 そして、ここvkontaktekomで「面白い猫」への参照を送信します。 送金をしたかった親relativeのカード番号を脇に置き、猫を見に行きました。 シールは本当に面白かった。 そしてその後、あなたは親someにいくらかのお金を移すことに決めました。 銀行のウェブクライアントの次のタブに戻って、送金を試みていますが、お金が足りません。 そして、あなたは人生で、子猫の盗賊があなたの銀行口座を囲んでいると推測することはありません。 これらの猫は、親relativeがあなたの口座からキャットフードとバレリアンの売り手にお金を送金している間、おかしなふりをしました。
これは不器用な例です。 そして、もちろん、どの銀行でも何もできません。 ただし、この例はCSRFの脆弱性の深刻さを理解するのに役立ちます。
そして今、シールなしで、詳細があります。
調査したアプリケーションでは、ログアウトする簡単な機会があります。 csrfを介してユーザーのログアウトを確認できます。 あなたは言うでしょう：何がそこにある、これは危険ではありません！ しかし、これは攻撃ベクトルではありません。 これは、アイデアが機能するという理論のテストにすぎません。
これを行うには、サブネットに次のコンテンツを含むテストサイトを作成する必要がありました。
<html> <body> <form action="https://example.com/client/api/logout"> <input type="submit" value="Submit request" /> </form> </body> </html>
次に、別のブラウザからログインします。 このブラウザーとWebサイトの2番目のタブで、アクティブなログインセッションでテスト済みのアプリケーションを開きます。 送信ボタンをクリックしてください。 テストアプリケーションの前のタブに戻ると、ログインしていません。
この例は機能しているため、80％の確率で他の場所でも機能します。 重要な場所の開発者はCSRF攻撃に対する保護手段を使用しているという事実に20％を任せました。 しかし、これはめったに起こりません。 CSRFトークンはどこにでもあるか、まったくありません。
アプリケーションを使用したデモサイトではシステム管理者からのログインが許可されているため、管理者ができること、そして最も重要なこととして、彼がそれをどのように行うかを確認できました。 興味深い発見は、パスワードをシステムユーザーにリセットすることでした。 こんな感じでした
<method="POST"> <input name="Id" value="1" /> <input name="newPassword" value="testerok" /> <input name="confirmPassword" value="testerok" />
また、パスワードを変更するために古いパスワードを入力する必要がないことに恥ずかしくない場合は、ユーザーがID経由で転送されるという事実に間違いなく混乱するはずです。
そして、攻撃シナリオはおよそ次のとおりです。
- システム内のページへのリンクを含むメッセージを管理者に送信します。
- ページにCSRFコードを配置して、ユーザーのパスワードを変更します。
- 管理者はリンクをたどります。
- ユーザーがパスワードを変更しました。 ただし、管理者は何かが発生したことさえ理解しません。
ページコード
<html> <body> <form action="http://example.ru/main/Security/Users/ChangePassword" method="POST"> <input type="hidden" name="Id" value="5" /> <input type="hidden" name="newPassword" value="test3" /> <input type="hidden" name="confirmPassword" value="test3" /> <input type="submit" value="Submit request" /> </form> </body> </html>
残っているのは、管理者が「誤って」新しいパスワードを設定したユーザーとしてログインすることだけです。 同じ例で、ケースはシステムで新しいユーザーを作成することで機能します。 あなたはまだ密かにそれを上げて、スーパーユーザーを作成することができます！ その下でシステムに座って、会社に関する多くの貴重な情報（注文、書類、財務情報）をマージできます。
このストーリー全体で個別に、問題に対する反応を強調したいと思います。 そして、それらの修正の速度。
XSSは報告された問題に迅速に対応しました。 彼らには全く質問はありませんでした。 しかし、CSRFでは、責任者から次の質問や異議を受け取るようになりました。
開発者の発言を見てみましょう。 理論的には、IPセッションがバインドされており、1つのトークンでは十分ではありません（c）テスト部門の責任者
その瞬間、私の目だけがけいれんしましたか？ 管理者が自分のコンピューターからすべてを行う場合、ホワイトリストに登録されたIPを介したどのような保護について説明できます。 これはCSRFチップです。 しかし、さらに。 担当者は次のように述べました。
バグ＃7まだこれを実装する方法がわかりません（c）テスト責任者
これは、システムのすべてのユーザーのパスワードの大幅な変更です。 その後、スクリーンショットを直接入手し、この機会を残してはならない理由を説明する必要がありました。
すべてのIDを一度に繰り返すことができます
まあ、私たちにとって面白くないものにとどまる
そして、実際には、このような明白で有名な脆弱性に関する明確な質問を得ることは悲しかったです。
すべての通信、説明、膨大な時間を費やした後、特別なバグ報奨金の報酬を受け取ることになりました。 さらに、この日までのこの報酬の計算は、私にとっては魔法のようなものです。 私は誰もが数える式を与えられましたが。
1つを除くすべてのXSSは重複としてカウントされ、減少する係数によって合計されました。 異なる係数でのSRF。
その結果、 100ユーロを受け取りました。
しかし、何かを得たのは良いことです！
「おもしろい」ユーザーサポートポリシーにより、ほとんどのお客様はこれらの重要な更新や修正が行われません。
これらの顧客が年間サポートサブスクリプションを持っていないという理由だけで。 そのため、この高価な製品を使用している大企業では、今日まで、クッキーを盗んだり、ユーザーの代わりに猫の写真を滑らせて何かをしたりすることができます。 クライアントのリストは印象的です-銀行、保険、工業所有権...
ある意味で、0dayは判明しました（この脆弱性には修正がありません）。
私の意見では、より合理的で高貴なことをすることは可能だろう。 MicrosoftはまだWindows XPのパッチをリリースしています。
道徳的および倫理的な理由から、会社の名前と会社の顧客を開示しませんでした。
まあ、代表者は評判を心配しています。
タイムライン：
7月19日-レポートが作成されました
8月9日-すべてのレポートが確認され、報酬が発生します
8月28日-XSSフィルタリングの問題を修正
11月14日-サポートサブスクリプションをお持ちのお客様向けにCSRF修正プログラムを実装しました