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 操作の オリジン/リファラー ヘッダーの検証を強制します（詳細については、 アップグレードノートをお読みください））。

• 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 にセッションの作成を強制します (以降のリクエストではセッション Cookie が想定されます)。

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