web-dev-qa-db-ja.com

swagger-ui.htmlページをロードすると、Host:port /およびHost:port / csfrにリクエストが送信されます

私はSpring boot 2アプリケーション(rest API)を使用しており、UIライブラリーを含むSpringfox Swagger 2ライブラリーを使用しています。 http://localhost:8080/swagger-ui.htmlにあるswaggerインターフェイスを開くと、すべてが期待どおりに機能しますが、ロガーで404結果を返す2つの要求が行われます。

http:// localhost:8080 / (私のアプリのルートには何もマップされていません)
http:// localhost:8080/csfr (このマッピングも存在しませんが、「クロスサイト偽造リクエスト」の略です)

どうやらSwaggerは ここで説明 のように、ある種のcsfrトークンチェックを「サポート」するため、これを行います。これらの404呼び出しを構成できるかどうかについて、数か月間調査が行われているため、代わりにエンドポイントの実装を検討しています。普段何をすべきかについての情報が見つかりません。 swaggerはどのような種類のヘッダー/トークンを期待していますか?それはその中の情報で何をしますか?これを使用して、アプリ(またはSwaggerエンドポイント)をより安全またはアクセス可能にすることができますか?要するに:ポイントは何ですか:)?

8
user1884155

一つずつお答えします。

http://localhost:8080/http://localhost:8080/csrfへのリクエストが行われるのはなぜですか?

これは、Springfox SwaggerがデフォルトでCSRFのサポートを有効にしているためです。これにより、アプリケーション内のSwaggerエンドポイントにアクセスしようとするたびに、以下の順序でCSRFトークンがチェックされ、リクエストヘッダーに添付されます。

  • /で提供されるメタタグ内のCSRFトークン
  • エンドポイント/csrf
  • Cookie内のCSRFトークン

Springfox SwaggerがCSRFトークンをアタッチする理由は、アプリケーションでCSRF保護が有効になっている場合に、Swaggerエンドポイントへのリクエストが失敗するためです。ヘッダーの一部としてCSRFトークンを持ちます。

Swaggerはどのような種類のヘッダー/トークンを期待していますか?それはその中の情報で何をしますか?

前述したように、swaggerはCSRFトークンを予期しており、swaggerエンドポイントにアクセスしようとすると、それが要求のヘッダーに添付されます。

これを使用して、アプリ(またはSwaggerエンドポイント)をより安全またはアクセス可能にすることができますか?

アプリ内でCSRF保護を有効にすると、アプリは必ずしもCSRF攻撃から保護され、必ずしもjustヘッダーにアタッチするために、CSRFトークンを提供します。アプリ内でCSRF保護を有効にしている場合、アプリ内のSwaggerエンドポイントにアクセスするには、上記の3つの方法のいずれかでCSRFトークンを提供する必要があります 。 CSRF保護を有効にする使用法については、 ここ を参照してください。

実際に実装するものに関する情報を見つけることができません

アプリ内でCSRF保護を有効にしていない場合は、冗長になるため、swaggerにCSRFトークンプロビジョニングを実装する必要はありません。ただし、swaggerにCSRFトークンプロビジョニングを実装する場合は、以下の3つの方法のいずれかで実行できます。

1)/で提供されるメタタグ内のCSRFトークン

<html>
<head>
  <meta name="_csrf" content="${_csrf.token}"/>
  <!-- default header name is X-CSRF-TOKEN -->
  <meta name="_csrf_header" content="${_csrf.headerName}"/>
</head>

これは、JSP、thymeleafなどのテンプレートメカニズムを使用している場合です。

2)エンドポイント/csrf

エンドポイント/csrfを定義して、CSRFトークンを提供します。

  @RequestMapping("/csrf")
  public CsrfToken csrf() {
    //logic to return the CSRF token
  }

3)Cookie内のCSRFトークン

検索されるデフォルトのCookie名はXSRF-TOKENで、返されるデフォルトのヘッダー名はX-XSRF-TOKENです。 Springセキュリティは、以下の設定でswaggerが必要とする場合、CSRFトークンをcookieに保存する方法を提供します

@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse());
    }
}

上記の3つのいずれかを実装すると、要求ヘッダーに添付するCSRFトークンがSwaggerに提供されます。

上記への参照は GitHub PR からのものであり、これにより、Springfox swaggerにCSRFサポートが提供され、以前にリンクしたSpringのセキュリティドキュメントも提供されました。

現在、デフォルトで有効になっているCSRFサポート ここ 、および修正 #2639 および #2706 を含むいくつかの未解決のPRに関する未解決の問題があります。

8
Madhu Bhat