CSRF の保護

HTTP リクエストの CSRF チェック

TeamCity の観点から HTTP リクエストの安全性を検討するときは、次のチェックが順番に行われます。

1. HTTP リクエストが（GET などの）変更されていないリクエストである場合、安全と見なされます。

2. HTTP リクエストのパラメーターまたは HTTP ヘッダーにセキュアな CSRF トークンがあり、このトークンがユーザセッションに格納されているものと一致する場合、安全であると見なされます。

ブラウザー以外の HTTP クライアントへの影響

ブラウザー以外の API アクセスの場合は、トークンベースの認証の使用をお勧めします。

CORS クライアントへの影響

CORS リクエストを使用するには、ここで説明されているように CORS サポートを構成します。この構成は、GET リクエストには十分です。
CORS 経由で POST/PUT/DELETE リクエストを送信する必要がある場合は、authenticationTest.html?csrf 呼び出しを使用して CSRF トークンを取得し、このトークンを変更する HTTP リクエストに提供する必要があります。

トラブルシューティング

TeamCity で CSRF 保護に関する問題が発生した場合 (たとえば、サーバーから「CSRF チェックに失敗したため、403 ステータスコードで応答します」応答が返された場合)、次の手順を試してください。

• 2020.1 より前の TeamCity バージョンでの動作と同様に、teamcity.csrf.paranoid=false 内部プロパティを設定して、CORS 操作の Origin/Referer ヘッダーの検証を強制します（詳細については、アップグレードノートを参照してください）。

• teamcity.csrf.origin.check.enabled=logOnly 内部プロパティを設定して、CSRF 保護を一時的に無効にします。

• 失敗した CSRF 試行に関する情報は、TeamCity/logs/teamcity-auth.log ファイルに記録されます。リクエストのより詳細な診断を行うには、debug-auth ロギングプリセットを有効にします。

• 「安全でない」(PUT、POST、DELETE) リクエストがアクセストークンを使用して Bearer 認証スキームを採用する場合は、セッション Cookie をクリアすることを検討してください。これにより、TeamCity は CSRF トークンの検証を完全にスキップできるようになります。

• 環境またはシナリオでセッションクッキーの存在が必須である場合は、期限切れのセッションに対応する CSRF トークンがリクエストで使用されていないことを確認してください。回避策として、最初の HTTP リクエストのセッションクッキーを次のリクエストに再利用することもできます。cURL でこれを行うには、--cookie-jar および --cookie コマンドラインオプション(英語)を使用して、ファイルへのクッキーの保存とファイルからのクッキーの読み取りを行います。さらに、teamcity.tokenAuth.setSessionCookie=true 内部プロパティを追加して、TeamCity にセッションの作成を強制します (次のリクエストに対してセッションクッキーを期待します)。

リストされている手順のいずれも問題の解決に役立たない場合は、サポートに連絡し、teamcity-auth.log ログに有効な teamcity-auth ロギングプリセットを提供してください。