あたり カットの下には、CSRFについてのとんでもない単純な記事の翻訳と、それに対する新しい方法があります。
古代の蛇
脆弱性CSRFまたはXSRF（これらは同義語です）は常に存在しているようです。 そのルートは、あるサイトから別のサイトにリクエストを送信する有名な機能です。 私のサイトでそのようなフォームを作成するとします。
<form action="https://bankingsite.com/transfer" method="POST" id="stealMoney"> <input type="hidden" name="to" value="John Doe"> <input type="hidden" name="account" value="12416234"> <input type="hidden" name="amount" value="$1,000">
あなたのブラウザは私のサイトをロードし、それに応じて私のフォームをロードします。 簡単なjavascriptを使用してすぐに送信できます。
document.getElementById("stealMoney").submit();
したがって、このような攻撃は、文字通りクロスサイトリクエストフォージェリの略です。 私は私のサイトとあなたの銀行の間で送信されるリクエストを偽造しています。 実際、問題はリクエストを送信することではなく、ブラウザがリクエストとともにクッキーを送信することです。 これは、リクエストにすべての権利が含まれることを意味するため、現在銀行のウェブサイトにログインしている場合は、私に1,000ドルを寄付しただけです。 ダンケ・ショーン！ ログインしていない場合、お金はまだ残っています。 このような悪意のある攻撃から保護するには、いくつかの方法があります。
CSRFの保護方法
インターネットにはそれらに関する情報がたくさんあるため、保護方法については詳しく説明しませんが、主要な実装について簡単に説明します。
ソースチェック
アプリケーションでリクエストを受け入れることで、2つのヘッダーを見ることで、リクエストの発信元を潜在的に見つけることができます。 それらはオリジンおよびリファラーと呼ばれます。 そのため、一方または両方の値をチェックして、リクエストがアプリケーションから送信されたのか、それとも別の場所から送信されたのかを確認できます。 リクエストソースがあなたのサイトではない場合、エラーで単純に答えることができます。 これらのヘッダーを確認することで保護できますが、問題はヘッダーが常に存在するとは限らないことです。
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 accept-encoding: gzip, deflate, br cache-control: max-age=0 content-length: 166 content-type: application/x-www-form-urlencoded dnt: 1 origin: https://example.com referer: https://example.com /login upgrade-insecure-requests: 1 user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
セキュリティトークン
固有の保護トークンを使用する方法は2つありますが、それらの使用原理は同じです。 ユーザーが銀行のページなどのページにアクセスすると、固有のトークンを持つ非表示フィールドが送金フォームに挿入されます。 ユーザーが実際に銀行のウェブサイトにいる場合は、リクエストとともにこのトークンを送信します。これにより、フォームに貼り付けたものと一致するかどうかを確認できます。 CSRF攻撃を試みる場合、攻撃者はこの値を取得できません。 ページへのリクエストの場合でも、Same Origin Policy（SOP）は、このトークンがあるページの読み取りを許可しません。 この方法は十分に証明されていますが、フォームにトークンを挿入し、着信要求でトークンの信頼性を検証するためのロジックアプリケーションが必要です。 別の同様の方法は、同じトークンをフォームに挿入し、同じ値を含むCookieを転送することです。 実際のユーザーがフォームを送信すると、Cookieのトークン値がフォームの値で検証されます。 それらが一致しない場合、そのような要求はサーバーによって受け入れられません。
<form action="https://report-uri.io/login/auth" method="POST"> <input type="hidden" name="csrf_token" value="d82c90fc4a14b01224gde6ddebc23bf0"> <input type="email" id="email" name="email"> <input type="password" id="password" name="password"> <button type="submit" class="btn btn-primary">Login</button> </form>
それで問題は何ですか？
上記の保護方法により、かなり長い間、CSRFに対するかなり信頼できる保護が提供されています。 もちろん、オリジンヘッダーとリファラーヘッダーのチェックは100％信頼できるものではないため、ほとんどのサイトは一意のトークンを使用した戦術に依存しています。 問題は、両方の保護方法でサイトがソリューションを実装およびサポートする必要があることです。 あなたはそれがまったく難しくないと言うでしょう。 同意する！ 問題はなかった。 しかし、それはugいです 。 本質的に、私たちは注意深い方法でブラウザの動作から身を守っています。 しかし、ブラウザに、望まないことをやめるように指示することはできますか？..
同じサイトのCookie
基本的に、Same-Site CookieはCSRF攻撃を無効にすることができます。 死ぬまで。 少しいっぱい。 Adyos、CSRF！ セキュリティ問題の解決に効果的かつ迅速に役立ちます。 さらに、適用は非常に簡単です。 たとえば、いくつかのクッキーを取ります。
Set-Cookie: sess=smth123; path=/
次に、SameSite属性を追加します
Set-Cookie: sess=smth123; path=/; SameSite
すべて完了しました。 本当にない！ この属性を使用して、ある程度の保護を備えたCookieを提供するようブラウザーに指示します。 そのような保護には2つのモードがあります。あなたがどれほど深刻かによって、厳格または緩いです。 モード表示なしのSame-Site属性は、標準バージョンで機能します。 厳しい 次のようにモードを設定できます。
SameSite=Strict SameSite=Lax
厳しい
このモードはより適切で安全ですが、アプリケーションに適さない場合があります。 このモードは、アプリケーションが別のリソースからのリクエストにクッキーを送信しないことを意味します。 もちろん、この場合、CSRFはルートでは不可能です。 ただし、ここでは、高レベルのナビゲーション中（つまり、リンクをクリックした場合でも）にCookieが送信されないという問題が発生する場合があります。 たとえば、今Vkontakteへのリンクを投稿し、FacebookがVkontakte Cookieを使用している場合、以前にログインしていたかどうかに関係なく、リンクをクリックするとログアウトされます。 もちろん、この動作はユーザーを満足させないかもしれませんが、安全性は確信できます。
これで何ができますか？ アマゾンのようにできます。 2つのCookieを使用して、一種の二重認証を実装しました。 最初のCookieにより、Amazonはあなたが誰であるかを知り、あなたの名前を表示します。 SameSiteは使用しません。 2番目のCookieを使用すると、購入したり、アカウント内の何かを変更したりできます。 そのため、SameSiteを合理的に使用します。 このソリューションにより、ユーザーに利便性を提供すると同時に、アプリケーションの安全性を維持できます。
緩い
Laxモードは、上記のロギングの問題を解決しますが、同時に適切なレベルの保護を維持します。 基本的に、「安全な」HTTPメソッドを使用する高レベルのナビゲーション中にCookieが送信されると、例外をスローします。 RFCによると 、GET、HEAD、OPTIONS、およびTRACEは安全な方法と見なされています。
最初の攻撃の例に戻りましょう。
<form action="https://bankingsite.com/transfer" method="POST" id="stealMoney"> <input type="hidden" name="to" value="John Doe"> <input type="hidden" name="account" value="12416234"> <input type="hidden" name="amount" value="$1,000">
このような攻撃はLaxモードでは機能しません。これは、POST要求から自分自身を保護しているためです。 もちろん、攻撃者はGETメソッドを使用できます。
<form action="https://bankingsite.com/transfer" method="GET" id="stealMoney"> <input type="hidden" name="to" value="John Doe"> <input type="hidden" name="account" value="12416234"> <input type="hidden" name="amount" value="$1,000">
したがって、Laxモードは、セキュリティとユーザーの利便性の間の妥協点と呼ぶことができます。
SameSite CookieはCSRF攻撃から保護しますが、他のタイプの脆弱性を忘れてはなりません。 たとえば、時間通りのXSSまたはブラウザベースの攻撃。
翻訳者から：残念ながら、SameSite Cookieは、ChromeとOpera、およびAndroid用ブラウザーのみをサポートしています。 証明