この記事は機械翻訳されました。
CSRF(クロスサイトリクエストフォージェリ)は、認証されたユーザーを騙して、本物のユーザーのアカウントを通じて悪意のあるアクターにアクセスを許可させます。
クロスサイトリクエストフォージェリ(CSRF)攻撃では、ハッカーが被害者の認証の下で何かを行います。それはちょっと手品のようなものです。 ユーザーが Web サイトにログインし、どういうわけか、その人のログインは、その人が進んで行うことは決してないあらゆる種類のことを行います。
CSRF攻撃がわかりにくいとしたら、それは設計によるものです。 これらは、コーディングのノウハウ、トリック、信頼、運に依存する攻撃です。CSRF攻撃は Web ITと同じくらい古いと言う人もいます。 あるサイトが別のサイトにリクエストを送信し始めるとすぐに、CSRF攻撃が生まれました。
しかし、古くて巧妙な攻撃ベクトルであっても、発見し、打ち負かすことはできます。これらの攻撃がどのように機能するか、そしてCSRF保護計画をまとめる際に何をすべきか(そして何を避けるべきか)については、以下をお読みください。
CSRF攻撃の仕組みは?
技術的には、CSRF攻撃とは、ハッカーがユーザーのアイデンティティと権利を乗っ取り、望ましくない機能を実行するために彼らを働かせる攻撃です。 平たく言えば、CSRF攻撃には、誰かがあなたをだましたり、IDを盗んだり、ログインの下で銀行アカウントからお金を送金したりするなどのオンライン操作が含まれます。
CSRF 攻撃は、ホスト サーバー上の何かを変更することに焦点を当てています。ハッカーは、ユーザー名を変更したり、お金を盗んだり、一般的な配送先住所を変更したりする可能性があります。ハッカーはすべてのアソシエイト通知を受け取るため、サイトは何か問題があることを通知しません。
CSRF攻撃を 順を追って見ていきましょう。
- 通常のログイン: 被害者は既知のユーザー名とパスワードを盗聴します。
- 標準セットアップ: このサイトはセッションCookieを作成し、被害者のブラウザに保存します。
- 接近： 被害者が攻撃者と対話するのは初めてです。彼らはフィッシング E メールで会うかもしれませんし、被害者が漏洩/侵害 Web サイトを読み込むかもしれません。
- 間違い： 被害者は攻撃者の餌と対話します。
- 攻撃： ハッカーのコードは、ユーザーがログインしているサイトにリクエストを送信します。ブラウザが応答し、そのメモに、被害者が保存した認証情報がIT部門に含まれます。
- 結果： サーバーは要求をチェックし、IT が正当であるように思われるため、IT はコードを実行します。
CSRF攻撃には、これらのステップのそれぞれが必要であり、順番に実行する必要があります。そのうちの1つでもスキップすると、攻撃は失敗します。
あなたのサイトはCSRF攻撃に対して脆弱ですか?
ハッカーは、特定の条件セットなしでCSRF攻撃を実行することはできません。
特に3つの要素が必要です。
- Cookie: ターゲット サイトでは、ログインしているユーザーのセッションを検証するために、単純な 1 回限りの Cookie を使用する場合があります。
- 簡単なプログラミング: 予測可能で単純なパラメーターのセットが要求を定義します。ハッカーは次に何が起こるかを知っています。
- ターゲットアクション:ハッカーは、努力を価値あるものにするために、何か重要なこと(送金など)を行うことができなければなりません。
過去の被害者を調査して、CSRF攻撃に伴うリスクを理解します。次のような大規模なWebサイトが攻撃を受けています。
- INGダイレクト。脆弱性により、ハッカーは新しいアカウントを作成し、ある場所から別の場所に送金することができました。
- ユーチューブ。ハッカーは、ユーザーを友人やお気に入りとして追加し、被害者のログイン情報に基づいてメモを送信することができました。
- ニューヨークタイムズ。ハッカーは、ユーザーのE メール アドレスを見つけることができました。
注: 会社概要 では、これらの脆弱性をすべて修正しています。
個人もハッキングされる可能性があります。セキュリティの専門家は、E メールの脆弱性をよく引き合いに出す。 ハッカーは、あなたの認証情報を盗み、何千もの脅迫的なEメールメッセージを政府関係者に送信する可能性があります。 彼らはハッカーが関与していることを知らないので、あなたの逮捕を要求するためにあなたの家に来るかもしれません。
CSRF 攻撃の作成と配信の説明
CSRF攻撃は、一般的なブラウザ機能に依存しています。リクエストを行うたびに、次のような盗用可能なデータが IT 部門にエンコードされます。
- ユーザー名
- セッションクッキー
- IPアドレス
- 資格情報
ハッカーは、このデータを取得する能力を持っていなければなりません。また、ハッカーはHTMLコーディングを使用して、サーバーをだまして目的の機能を実行させる必要があります。残念ながら、このような攻撃を行うソフトウェアはオンラインで簡単に入手できます。(また、ハッキング行為を奨励するのは好きではないので、ここではITにリンクしません!
ターゲットサイトを選択し、コードをビルドすると、ハッカーは商品を配送する必要があります。これには、次のようなものが含まれる場合があります。
- E メール.全人口の約半数は、自分に送信されたものをクリックします。ユーザーがすでにログインしているまさにその瞬間にハッカーがメモを送信した場合、攻撃はすでに進行中です。
- 偽造。ハッカーは、被害者がターゲットサイトにログインしている間に見る可能性のあるページ上に、通常に見えるフォームまたはスクリプトを作成します。そのサイトへの多くの訪問者がターゲットサイトにログインしていないかもしれませんが、ハッカーは作業を価値のあるものにするためにたった1人の訪問者を必要とします。
- ソーシャルエンジニアリング。ハッカーは、ソーシャル メディア メッセージング アプリの信頼できるソースから来たように見えるメモを使用して、被害者を偽造サイトに誘導する可能性があります。
被害者が標準ユーザーの場合、ハッカーはパスワードの変更、送金、配送先住所の交換などの一般的なタスクを引き継ぐことができます。しかし、被害者がターゲットサイトの管理者である場合、ハッカーは完全な制御を引き受けることができます。
CSRF保護チェックリスト
漏洩/侵害サイトを運営していて、そこでハッカーが誰かを攻撃した場合、責任はあなたにあります。 IT部門は、安全で保護されたコミュニティを構築するために、できる限りのことをするのが賢明です。
OWASP® Foundationは、これらのCSRF保護手順が機能しないと警告しています。
- シークレットCookie:他のCookieと同様に、セッション識別子として共有される場合があります。
- POSTの制限:ハッカーがこれらの攻撃でPOST機能を標的にするのは一般的です。 しかし、このフォームを制限すると、ハッカーは別の方法を見つけるでしょう。
- 手順の追加: 攻撃者が標準的な順序を理解できる限り、これは保護を提供しません。
- URL の書き換え: ユーザーのセッション ID はまだ公開されているため、この手順は役に立ちません。
ここでは、取るべき4つの保護手順をご紹介します。
- REST: これらの設計原則に従い、さまざまな HTTP 動詞にアクションを割り当てます。ハッカーは、ITが表示に特化しているため、GETリクエストを使用してデータを取得することはできません。
- 偽造防止トークン: サーバーは、後続の要求に対してこのコードを要求する必要があり、IT が存在しない場合、IT はそれらの要求を削除する必要があります。
- SameSite Cookie: この Google 製の CSRF 対策ツールは、第三者からのリクエストとともに送信される Cookie をブロックするのに役立ちます。
- 確認: ユーザーは、機密性の高いアクションを実行する前に、ログインの詳細を確認します。
オンライン生活の不一致に注意するように従業員を訓練します。また、サイトを訪れているときにハッカーに狙われたと顧客が不満を漏らしている場合は、注意が必要です。脆弱性を追跡して IT を停止するまで、コードをロックダウンする必要がある場合があります。
顧客を守るためのさらなる方法をお探しなら、当社にお任せください。Oktaのアイデンティティソリューションの詳細については 、お問い合わせください 。私たちはあなたのサイトへのログインを保護し、停止と移行の両方でデータを保護するお手伝いをします。
参考文献
クロスサイトリクエストフォージェリは死にました。(2017年2月)。スコット・ヘルメ。
シングルページアプリケーション(アプリケーション)でのCSRF攻撃の軽減。 （2020年1月、Medium）
クロスサイトリクエストフォージェリ攻撃に対して脆弱な人気のあるWebサイト。(2008年9月)。いじくり回す自由。
フィッシング対策のトレーニングはこれくらいにして、半数の人は送られてきたものなら何でもクリックします。(2016年8月)。Ars Technica
脅威ウォッチ:クロスサイトリクエストフォージェリ(CSRF)。(2007年12月)。CSO）
クロスサイトリクエストフォージェリ(CSRF)。OWASPです。
CSRF からユーザーを保護します。ハックスプレイニング。
