Cross Site Request Forgery (CSRF) protection changes in Atlassian REST
Atlassian REST の先日の変更を受け、リクエストのオリジンが信頼されない場合に一部のブラウザ リクエストがブロックされるようになりました。
次の条件が満たされる場合、REST リクエストのオリジンの CSRF チェックが行われます。
- リクエストが POST リクエストである (http 動詞が POST)
- リクエストが既知のブラウザから送信されている
- リクエストが次のいずれかに該当しない content-type を送信している
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain
- 空白または指定なし
信頼されないオリジンが上の条件に該当するリクエストを送信しようとした場合、リクエストはブロックされ、次のようなログ エントリがご利用のアプリケーションのログ ファイルに記録されます。
2015-09-01 17:25:46.530585500 2015-09-01 07:25:46,530 ajp-nio-127.0.0.104-8009-exec-23 WARN anonymous 1045x1465x1 sibktb 127.0.0.1 /rest/auth/latest/session [c.a.p.r.c.security.jersey.XsrfResourceFilter] Additional XSRF checks failed for request: https://example.domain/rest/auth/latest/session , origin: https://another-origin.domain , referrer: null , credentials in request: true , allowed via CORS: false}}
症状
次の症状が確認され、これらは設定を修正することで解決されます。
- Universal Plugin Manager を含むアドオンを Atlassian Marketplace から更新
CSRF オリジン保護の仕組み
CSRF オリジン保護は、受信リクエストのオリジンを origin および referer ヘッダーで比較することで動作します。簡潔に説明すると、リクエストのオリジンがアプリケーションそのものと同じオリジン であるか、リクエストのオリジンがアプリケーションによって信頼されているかどうかが確認されます。
例:
注意: https://trusted-origin.com はアプリケーションによって信頼されているとします。
| リファラーのヘッダーの値 | オリジンのヘッダーの値 | アプリケーション URI | 許可されるかどうか |
|---|---|---|---|
| http://example.com | http://example.com |  - ホスト、ポート、スキーマの一致 | |
| https://example.com/foobar | https://example.com/example | - ホスト、ポート、スキーマの一致 | |
| http://somethingelse.com | http://example.com |  - ホストの不一致 | |
| http://example.com:81/ | http://example.com/ | - ポートの不一致 | |
| http://example.com | https://example.com | - スキーマの不一致。http != https | |
| http://example.com | http://example.com | - ホスト、ポート、スキーマの一致 | |
| https://example.com/foobar | https://example.com/example | - ホスト、ポート、スキーマの一致 | |
| http://somethingelse.com | http://example.com | - ホストの不一致 | |
| http://example.com:81/ | http://example.com/ | - ポートの不一致 | |
| http://example.com | https://example.com | - スキーマの不一致。http != https | |
| https://trusted-origin.com | https://example.com | - リクエストが信頼されるオリジンから送信されているため、許可。上記の前提にあるように、https://trusted-origin.com はアプリケーションで信頼されています。 | |
| https://trusted-origin.com | https://example.com/ | - リクエストが信頼されるオリジンから送信されているため、許可。上記の前提にあるように、https://trusted-origin.com はアプリケーションで信頼されています。 |
修正方法
Bitbucket Server 5.0 以降では、Tomcat コネクタを直接構成することはできません。
server.xml 構成は <Bitbucket home directory>/shared/bitbucket.properties で置き換えられました。
これは通常、Tomcat のプロキシ構成の問題によって発生します。
アトラシアン アプリケーションがプロキシの背後で実行されているときにオリジン ベースの CSRF 保護の問題が発生する場合、server.xml で次のパラメーターが設定されているかどうかをご確認ください。
proxyNameの構成内容が、アプリケーションがアクセスされているホスト名に一致するかどうかproxyPortの構成内容が、アプリケーションがアクセスされているポートに一致するかどうかschemeの構成内容が、アプリケーションがアクセスされているスキーマに一致するかどうか
たとえば、Jira が Apache の背後で実行されていて、Jira にアクセスするための URL が https://example.domain/ である場合、正しいプロキシ設定は次のようになります。
- proxyName="example.domain"
- proxyPort="443"
- scheme="https"
同じ例で server.xml に設定ミスがあり、HTTP を指すようにパラメーターが構成されている場合、次の UPM の問題が再現されます。
- proxyName="example.domain"
- proxyPort="80"
- scheme="http"
Postman 拡張機能を利用した回避策
Postman のブラウザ拡張機能の利用をご希望の場合、Postman Interceptor ブラウザ拡張機能のインストールが必要になる場合があります。次の手順では同一オリジンのポリシーに従い、オリジンのヘッダーをリクエスト宛先と同じオリジンに設定しています。
- Postman アプリケーションの上部で 'Proxy / Interceptor' ボタンをクリックします。
- 指示にしたがって Postman Interceptor をインストールします。
- Postman で Intercepter を有効化します。
- [Headers] タブで、Origin をリクエストの送信先のサーバーに、Content-Type を application/json に更新します。
たとえば Postman を利用して https://foobar.example/ にリクエストを送信したい場合、Origin のヘッダーを https://foobar.example/ に設定します。