web-dev-qa-db-ja.com

AJAXを介してCSRFトークンをリクエストする

別のサブドメインのAPIと通信するJavaScript Webアプリケーションがあります。 HTMLとJavascriptはすべてS3でホストされています。

従来のCSRFトークンはHTMLページの本文に挿入され、formによって使用されるか、JavaScriptによって読み取られます。しかし、HTMLが静的にホストされているため、私の場合、これは不可能です。

AJAX requestを使用して、アプリケーションの起動時にサーバーからCSRFトークンをリクエストしても安全ですか？結果のトークンは、APIへの今後のすべてのリクエストのヘッダーとして添付できます。

私のアーキテクチャでCSRF攻撃から保護するためのより良いソリューションはありますか？

javascriptcsrfajax
1
Steve

通常の注意事項を守っていれば可能です。セッションの開始時に1回リクエストし、それをアプリケーション内に保持し、SSLでAPIリクエストを保護し、トークンが適切に作成されるようにします（暗号学的に強力なランダム、または暗号化されたクレームなど）

CSRF防止に関するOWASPページの詳細については、こちらをご覧ください。 https://www.owasp.org/index.php/Cross-Site_Request_Forgery_（CSRF）_Prevention_Cheat_Sheet＃General_Recommendations_For_Automated_CSRF_Defense

0
GreatSeaSpider

実際にはトークンは必要ありません。カスタムヘッダーを使用してこれを作成できます。

私はバグバウンティハンターであるため、CSRFトークンが重要であることを知っていますが、代わりにブラウザのセキュリティに依存することができます。 CSRFトークンがサブドメインから漏洩する多くのケースを確認しました。

たとえば、a.mysite.comからデータを送信する場合は、次のヘッダーを含めます。

Ok-Request: 1

クロスドメインにデータを送信するので、次のようにHTTPヘッダーを構成する必要があります（b.mysite.comの場合）：

Access-Control-Allow-Headers: x-requested-with, content-type, accept, Origin, Ok-Request 
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Origin: a.mysite.com
Access-Control-Allow-Credentials:true



ブラウザーがカスタムヘッダーを送信するとき、すべてが（Origin、Method、Headers）のように問題がない場合は、最初にOPTIONリクエストが行われ、次に実際のリクエストが行われます。そうでない場合、ブラウザは [〜＃〜] sop [〜＃〜] エラーをスローします。

0
Abdullah Hussam