最大のRunetポータルにおける複数のCSRF脆弱性

Securitylabスタイルの見出しを許してくれますが、事実は変わりません。



最初に、最大のRunetポータルの1つで発見したCSRFの脆弱性について書くつもりでした。 しかし、このポータルだけでなく、最大のリソースのほとんどがこれらの脆弱性の影響を受けることが判明しました。 1ヶ月半前に問題をそれぞれの会社に報告しました。 今、私は再び時間があり、すでに閉じていたものを見ました。 1か月半で、たった1つの脆弱性がクローズされたことが判明しました。



なぜなら 脆弱性はまだ機能しているので、見つけた場所とその使用方法についてのみ説明します。 学生と主婦が活用できるように、1週間でダミーの実例を作成することを約束します。 隠れなかったのは私のせいではありません。



陰謀：私は、Yandex、Rambler、Mail.ru、Vkontakte、LJ、およびその他の一般的なリソースの脆弱性を探していました。 見つけた脆弱性の場所とその種類を見つけるのが待ちきれない場合は、「脆弱性リスト」セクションに進んでください。



必要な脆弱性を理解するには、少なくともCSRFとは何かに関する基本的な知識が必要です。 彼らがそこにいなければ-がっかりしないでください、以下ではアクセス可能な方法でそれを説明しようとしました（私の意見では、うまくいきませんでした）。 すでにそれが何であるか、またはその逆を理解していない場合は、表面的な監査の結果に進んで進んでください。



まず第一に、 ウィキペディアを読むことは理にかなっています 。 あなたが英語で怠lazを読んだ場合（ウィキペディアのトピックにはほとんど何もありません、トピックはHabréで非常に貧弱にカバーされます）、何かを知りたい場合は、この脆弱性を説明する以前のシリーズの要約です。



UPD：主な開発Liveinternet.ruはCSRFの存在を信じていません。 約束の週の前に彼の脆弱性を明らかにします。 以下に使用例を示します。 LiRuのアカウントを持っている場合は注意してください。



UPD 2：脆弱性が実証されており、例はこれまで削除されました。



UPD 3：週が過ぎました。 作業/作業例を広げます。 時間は短いので、まだ何が機能していて何が機能していないかを確認していません。 このことについてコメントで書いていただければ幸いです。 すべての質問、希望、提案は、 このコメントへの回答にあります。

ランブラー 、 Mail.Ru 、 Liveinternet 、 Yandex

CSRFとは何ですか？

Webアプリケーションでアクションを実行するには、ユーザーはHTTP要求を送信します。 どのユーザーに代わってアクションが実行されるかを判断するために、通常、データがCookieに保存されているセッションが使用されます。 サーバーはリクエストを受信し、Cookieを調べ、Cookieデータに関連付けられたセッションが存在することを確認し、このセッションに関連付けられたユーザーに代わってアクションを実行します。 ユーザーがお気に入りのリソースにログインしたままにするために、ブラウザはそれらをインストールしたサーバーに自動的にクッキーを送信します。 したがって、ユーザーのブラウザーから要求が送信されると、Cookieも一緒に送信されます。 そして、サーバーは、リソースのログインユーザーを処理していると考え、ユーザーに代わってアクションを実行します。 また、ブラウザにサードパーティのページからリクエストを送信させることができます。 サーバーがそのようなリクエストをそのページからのリクエストと同じ方法で処理する場合-これが脆弱性です。

使い方は？

もちろん少しわかりにくいので、簡単な例です。 全体の説明から、彼だけを読むことが可能です。



人気のソーシャルネットワークからプロファイルを削除するには、Vasyaが[プロファイルの削除]リンクをクリックする必要があります。これにより、http：//vulnerable.site/delete_profile.php？sure = yesページが表示されます。 Petyaは、このアドレスにアップロードする写真を自分のページに配置します（このアドレスに写真がないことは明らかですが、ブラウザは事前にこれを知りません）。 VasyaがPetyaのページにアクセスすると、Vasyaのブラウザはこの写真をダウンロードしようとします。 彼は写真を見つけられず、落ち着きます。 しかし、人気のソーシャルネットワークは、Vasyaに代わってプロファイルを削除するコマンドを受け取りました。 そして、Vasyaのプロファイルは安全に削除されました。 おそらくあなたはまだ理解していない-VasyaとPetyaをAliceとBobと交換してもう一度読んでください。 これらのVasyaとPetyaからは常に大きな混乱があります。



そのため、使用するには、ユーザーを自分で作成したページ（または、XSSを介してコードが投稿されているXSSのあるページに誘導する必要があります-ただし、この記事に違いはありません）。 このページには、リクエストを送信するものがあるはずです。 最も簡単な方法は、写真を配置することです。



<img src="http://vulnerable.site/delete_profile.php?sure=yes"/>







人気のブログをハックして、そこに非表示のiframeを投稿することができます-結果は驚くべきものになります。

そして、私のアプリケーションでは、すべてのアクションはPOSTリクエストを介して実行されます

何らかの理由で、多くの開発者は、POSTリクエストの送信を必要とするCSRFの脆弱性を悪用することは不可能であると確信しています。 通常、JSを介して別のドメインにPOST要求を送信することができないという事実によって、彼らはこれを動機付けます。 これは事実です（少なくとも通常の条件下では）。 しかし、何らかの理由で、彼らは常に世界の邪悪な iframeタグのルートを忘れています。 第一に、非表示（表示：なし）でもブート可能です。 次に、どこからでも（サーバーを含む）ダウンロードできます。 そして第三に、method = "POST"およびaction = "http://vulnerable.site/delete_profile.php"のフォームを含めることができ、このフォームでsubmitを呼び出すことができます。 以下にリストされた脆弱性を示すために、私はまさにそのような方法を使用しました。

私はユーザーです-どうすれば自分を守ることができますか？

ここで私はあなたを混乱させる必要があります。 自分を守る唯一の方法は、インターネットを使用しないことです。 または、少なくともどこかでログインする必要がある部分（ソーシャルネットワーク、Twitter、電子メール、フォーラムなど）。 いいえ。もちろん、リソースを使用した直後にセッションを開いたままにせず、常に終了ボタンを押すことはできません。 ログインしている間-あなたは脆弱です。 通常のユーザーは、開発者のプロ意識と、ユーザーの面倒を見るという事実にのみ頼ることができます。 そして、希望はほとんどありません。



UPD： FFにはアドオンがあります-RequestPolicy 、 Vanavに感謝

私は開発者です-ユーザーの世話をする方法は？

ユーザーの世話をすることです-CSRFサーバーを使用しても無効にならず、SSHはアクセスを許可しません。 ユーザーに代わっていくつかのアクションが実行されます。 まあ、ユーザー自身がそれらを満たすことができます。 したがって、一部の開発者はこれを脆弱性とは見なしていません。 そして、私はこの態度を露骨な非プロフェッショナリズムであり、自分のユーザーに吐き出していると考えています。 職業から抜け出す。 さらに、この脆弱性は決して新しいものではありません。



保護方法について詳しくはおそらく説明しません-方法をリストし、小さなコメントを付けるだけです-なぜなら あなたが開発者であれば、あなた自身がこれを すでに理解できます。



私はすぐに英語版ウィキペディアからメソッドを取得したと言わなければならず、私の意見では、それらの多くは保護されていません。

1. 各アクションのワンタイムトークンが最も信頼性の高い方法です。個人的に選択します
2. 各リクエストでは、ユーザー名とパスワードの要求も信頼できますが、HTTPSを使用しない場合は、スニファーを使用してリクエストからパスワードを盗むことができます
3. セッションの存続期間を制限する- 何に対しても保護せず、悪用される可能性のある時間を単に短縮する
4. Refererヘッダーを確認するのは悪くありませんが、このヘッダーは常に設定されているわけではありません。最初の方法をお勧めします
5. clientaccesspolicy.xmlおよびcrossdomain.xml（それぞれSilverlightおよびFlashの場合）が未検証のソースからのリクエストを許可しないことを確認してください- これは最初にドアからロックを解除し、誰でも歩いてから保護するためにそれを掛ける方法です
6. X-Requested-Withを確認します-AJAXリクエストに役立ちますが、それでも常にではありません

練習する

基本的に、CSRFを見つけることは非常に簡単な作業です。 関心のあるリソースにアカウントを設定し、Firebug / Chrome Developer Toolsをオンにして、通常のユーザーが行うことすべてを行います-メールボックスの設定、読み取り、書き込み、手紙の削除、ブログへの書き込みなど。 同時に、送信されたリクエストを確認することを忘れないでください。 要求に生成されたデータ（さまざまなワンタイムトークン）が潜在的な脆弱性である方法が不可解に含まれていない場合。 ローカルページからこのリクエストを繰り返し、結果を確認します。 アクションが発生した場合、脆弱性が発見されました。 フォームを使用してページを作成し、サーバーにアップロードして、このページを他のページから非表示のiframeに読み込みます-作業を実演するために（または工業用に）。 あなたはまだあなたの友人の何人かを見せて、彼らをチェックすることができます。 脆弱性と友人との関係を冷静に評価するだけで、アカウントから30万ドルが送金された場合にクラスメートのPetyaが満足することはほとんどありません。



一部のリクエストは、FirebugまたはChrome Developer Toolsのいずれでも追跡できませんでした。最初にAJAXリクエストが送信され、JSを使用してレスポンスを受信すると、次のページが開きます。 この場合、関心のあるリクエストは数秒間しか表示されません。 しかし、だれもWiresharkから隠すことはできません。



UPD：コメントの賢い人は、FireBugには「クリアしない」ボタンがあり、Chrome開発者ツールには「ナビゲーション時にログを保存する」があることを示唆しています



脆弱性を検索する場合、追加のサービス（Yandexカレンダーなど）とモバイルバージョンを忘れてはなりません。

脆弱性のリスト

特定のポータルですべてのCSRF可視性を見つけるタスクを自分で設定しませんでした。 各リソースは2時間以内に割り当てられました。 私はロシアのポータルのみをチェックしました-Google.ru、Facebook.comなどは、まだ残っています。 一部のポータルでは、割り当てられた期間、何も見つかりませんでしたが、保護方法に関する一般的なレビューを残すためにリストに追加しました。 リストの一部のポータルでは、Runetで最大のものを検討していませんが、使用した評価を考えています。

Liveinternet.ru

CSRFに対する保護はまったくありません。 プライベートメッセージの送信、ブログへの投稿、コメントの作成、アカウントの再構成など、一般的にはリソースで許可されていることなら何でもできます。 したがって、脆弱性のリストをコンパイルしませんでした。 このリソースは、私が最後に到達したものであり、最大のものの1つとは考えていません。 彼の後、私の手は落ちました-すべてがすでに明らかになりました。

Rambler.ru

方法1に基づくCSRF保護-ワンタイムトークン。 CSRFは存在しないように思われます。 しかし、第一に、この保護はどこにもありません。 そして、第二に、トークンはチェックされません-任意のトークン（および空のトークンも）を送信でき、とにかくアクションを実行する必要があります。 フォームの1つに追加の保護として、現在のページのアドレスを持つ非表示フィールド「リファラー」を見つけました。 私も少し泣きました。

Ramblerの開発者は、ある日、そのようなCSRFの脆弱性があり、それに対して保護するには、リクエストごとに一意のトークンを送信する必要があると言われたという印象を受けます。 しかし、彼らはそれもチェックする必要があると言うのを忘れていました。



できること

1. Rambler。Friends（誰がそれらを使用しますか？）では、任意の名前で友人のグループを作成したり、任意の友人を追加または削除したり、友人の行動に関する通知の設定を変更したり、友人に追加したりできます
2. アカウント設定では、ユーザーをブラックリストに追加または削除したり、署名を変更したり、場所を変更したり、興味のあるリストを変更したり、友達リストと名前の表示を有効/無効にしたりできます
3. メールでは、ユーザーに代わって任意の文字を送信し、任意の電子メールへの無条件転送を有効にし（保存せず）、メール設定を変更し（サードパーティサーバーからの画像の表示を有効にすることが特に重要です）、フォルダーからすべての文字を削除します（実際、それらはゴミ箱に移動します） ）バスケットを空にします
4. また、メールで手紙を削除し、手紙に既読のマークを付け、任意のメールボックスに手紙を転送できます。 確かに、このためには、レターのIDと、レターが保存されているフォルダーの名前を知る必要があります。 「Inbox」と「Sent」の2つのフォルダーが知られています。 letter id-現在のフォルダー内の文字番号。だから誰もブルートフォースをキャンセルしませんでした

一般的に、メールによるスパムと詐欺の巨大な範囲。 潜在的なユースケースについても考えていませんでした-ユーザーの知らないうちにできないことを言う方が簡単です。



これは完全なリストではありません。なぜなら、 保護はありません（むしろ保護されていますが、機能しません。これは同等です）。

Mail.ru

メールでは、方法2によるCSRFに対する保護-パスワード入力。 つまり これは最初はCSRF保護ではありませんが、パスワードの入力が必要な場合、CSRFも機能しません。 他のサービスには通常の保護があります。



だから、CISの最も人気のある郵便サービスに見られる強迫観念は何ですか

1. ユーザーに代わって、メールボックスにテキストと件名を付けて手紙を送信します。 攻撃者のメールボックスに一意のコードが記載された手紙を送信すると、訪問者の電子メールアドレスが認識されます。 AJAXを介したこの電子メールは、ユーザーが既に存在するページに到達します-これは、脆弱性No. 2、No。7を悪用するのに役立ちます
2. レターのコピーを任意のアドレスに送信します（レターは送信されたアドレスに保存されないため、ユーザーはこれについて知ることができません）。 この脆弱性を悪用するには、メッセージID（20桁）を知る必要がありました。最初の10はタイムスタンプで、2番目の10はこの2番目にサーバーによって処理されたメッセージの数です（これはもちろん個人的な仮定です）。 私の観察によれば、この数は1000を超えません。サーバーに一度に1000文字を送信するように要求すると、pro.mail.ruインターフェース（つまり、この脆弱性はそこにあります）がメールボックスに実際に持っている文字を送信します3文字以上を同時に転送することは不可能であること。 ブルートフォースを使用できます-10秒で受信した文字を送信し、毎回1000個ずつ転送を要求します。 詐欺には1日あたり2.5 GBの発信トラフィックが必要ですが、パスワードで手紙を盗むのにこれは必要ありません-パスワードはユーザーのメールボックスのサードパーティリソースに復元され（1番から既にわかっている可能性があります）、メッセージの到着時刻はすでにほぼわかっています 脆弱性3と併用できます
3. 手紙の削除-再びIDによる。 再び総当たり。 パスワードの回復を開始し、パスワード付きのメールを盗み、削除します
4. SMS通知の接続と切断-ここではすべてが簡単です。 一部のメールボックス設定は、パスワードを入力せずに変更できます。 通知をオフにすることも、携帯電話で通知をオンにすることもできます（段落7で結ばれています）
5. 送信された電子メールの保存を無効にし、メールページでWebメールエージェントを有効にします-これらのチェックボックスは設定の同じページにあり、以前の脆弱性が状態を変更するためにパスワードを必要としなかったように。 送信された保存を無効にするのは理解できる理由です。 また、CSRFもある場合は、Webメールエージェントを有効にすることは理にかなっています
6. メールボックスのサイズ制限のアプローチに関する通知をオフにします-本質は前の2と同じです。 通知をオフにして、大きな文字でボックスを埋めます
7. 電話番号をバインド/削除する-これで、すべてがもう少し面白いです。 すべてのアクションには、ユーザーの電子メール（またはユーザー名とドメイン）が必要です。これは、ポイント番号1から取得できます。 また、電話番号を指定する必要があるため、ユーザー自身の電話番号を削除しても機能しません（少なくとも事前に知らない場合-たとえば、メールエージェントの許可された連絡先に表示されます-ログイン方法は別の質問です）。 電話番号をバインドするには、リクエストを送信する必要があります。 その後、コード付きのSMSが電話に届きます。 この段階では、SMSからコードを取得してAJAXリクエストでレポートするソフトウェアが必要になります。 このコードを受け取ったページのJSは、電話番号のバインドを確認する別のiframeを作成します。 同じ方法でこの電話番号を削除できます。 本当に一つの機能があります-電話番号が唯一のものである場合、それは15日後にのみ削除され、すぐには削除されません。 SMSのコードを知っている場合にのみ、すぐに削除できます（バインドの場合と同じです）

ヤンデックス

CSRFに対する保護は。 しかし、以来 Yandexは検索やメールだけでなく、保護はどこでも異なります。 そしてどこかに、何かが欠けています。 3日以内にYandexが私の手紙に回答し、情報を確認することを約束しました。 そして、少なくとも1つの脆弱性を修正したのは彼らだけです。



できること

1. 検索を再構成することが可能でした-「検索」サービスで検索クエリと結果の保存を可能にし、検索のフィルタリングレベルを変更します（たとえば、害のために同僚がポルノを検索することを禁止します）。 この不可視性は現在閉鎖されています。
2. ユーザーの場所を変更することができます-彼はサンクトペテルブルクの代わりにヘルソンで検索結果、広告、交通渋滞が表示されます。 そして、あなたはすべての訪問者の場所をいくつかのあまり人気のない場所に変更し、モスクワよりもはるかに低い価格でダイレクトから広告を出すことができます
3. ユーザーのカレンダーに任意の名前でToDoリストを作成し、それに任意のケースを追加できます。 ケースを追加するには、リストIDを知っておく必要がありますが、最初に自宅でリストを作成し、次にユーザーで、次に自宅で再度作成し、2つのリスト間でIDを反復処理できます。 Yandex.Calendarのモバイルバージョンの脆弱性
4. Yandex.Passportから電話を削除できます。 あなたはそのIDを知る必要がありますが、追加のおおよその日付を知っているので、それを拾ってブルートフォースすることができます
5. Yandex.Marketでは、任意の製品を比較リストに追加できます。 またはそこから削除します。
6. Yandex.Marketでは、特定のレベル以下の特定の製品の値下げに関する通知をユーザーにサブスクライブできます。 または、通知からユーザーをサブスクライブ解除します。 たとえば、悪意のあるオンラインストアが灰色のiPhoneのバッチを購入し、それらを販売するアクションを計画しています。 アクションの前に、彼はある種のPRキャンペーンを手配し、8000ルーブル以下の値下げについての通知ですべての訪問者に署名します。 そして、iPhoneは7999ルーブルの価格でYandex.Marketにエクスポートされ、すべてのユーザーはYandexからこのiPhoneを購入するオファーとともにスパムを受け取ります
7. グローバルログアウト。 すべてのコンピューターですべてのユーザーセッションを終了できます。 ペットの汚いトリックとして使用できます。 競合他社はすべてのYandexセッションを終了するiframeをサイトに配置できますが、ユーザーはイライラします。 一般に、そのような問題がない唯一のサイトはVkontakteです。 間違ったトークンでアカウントから抜け出すことさえできません。 これが脆弱性とみなされるかどうかはわかりませんが、Vkontakteは

最も深刻な脆弱性ではありません。 最も可能性が高いのは、Yandexが多数のサービスであり、それぞれに独自の開発チームがあり、保護の構成がどこでも異なるためです。 そしてどこか見落とされていた。

しかし、VkontakteとLJはどうですか？

もちろん、これらのリソースを無視することはできませんでした。 しかし、脆弱性は見つかりませんでしたが、これはそれらが存在しないことを意味しません。 いずれにせよ、CSRFに対してどのように保護されているかを伝える価値はあります。

ヴコンタクテ

ユーザーアクションのトークン。 自動的に追加されるようで、忘れられません。 モバイル版とまったく同じ保護。 1つのサービス、1つの開発チームには、Yandexなどの問題はありません。 私を混乱させるのは1つだけです。特定のアクションのトークンは、特定のユーザーに対して常に同じです。 つまり これは、保護方法1と2の特定の組み合わせです。トークンは使い捨てではなく、ユーザーのみが知っています。 アクションを実行するためのパスワードと見なすことができます-各アクションには独自のパスワードがあります。 私はそのような組織で何かが好きではありませんが、それでも正確に理解していません。

LJ

方法1による保護-ワンタイムトークン。 モバイル版では、保護は少し簡単ですが、まだあります。 以下に例を示します。 このサービスはロシア語ではないことに注意してください。 そのため、彼は競争相手ではありません。

同級生

私は本当にそれらをチェックアウトしたかった。 ただし、このためには、それらを使用できる必要があります。 そして、私は彼らのデザインに神経質なカチカチがあります。 そのため、うまくいきませんでした。 無効な画像でこれを修正するために、ある夜試してみます。

おわりに

一般的に、写真は完全に喜びのないものです。 そのようなモンスターがプロジェクトでそのような間違いを犯した場合、他のすべての開発者はリソースを再度確認する必要があります。 Yandexは、1か月半で脆弱性閉鎖率で1位の脆弱性率で1位になります。 残りのリソースは、名誉ある2位を占めています。