More than 3 years have passed since last update.

omniauth CVE-2015-9284 はどうすればよいのか

Last updated at Posted at 2019-12-30


Patched version: No fix

Gemfile.lock において omniauth 1.9.0 を使っているとGitHubにこれを指摘されるし、お客さんにこれ使わないとできないの?って言われた時にいや大丈夫っすよ、、、と言えるようになりたい。



GEM側での対応はない(仕様)ので実装でがんばる。具体的には /auth/:provider へGETアクセスできないようにし、CSRF対策GEMを導入してPOSTのみ受け付けるようにする。


CVE-2015-9284 (GitHubより引用

Vulnerable versions: <= 1.9.0
Patched version: No fix

CVE-2015-9284 (CVEより引用

CVE - CVE-2015-9284

The request phase of the OmniAuth Ruby gem is vulnerable to Cross-Site Request Forgery when used as part of the Ruby on Rails framework, allowing accounts to be connected without user intent, user interaction, or feedback to the user. This permits a secondary account to be able to sign into the web application as the primary account.



OmniAuth Ruby gem におけるクロスサイトリクエストフォージェリの脆弱


What is クロスサイトリクエストフォージェリ

クロスサイトリクエストフォージェリ - Wikipedia


Resolving CVE 2015 9284 · omniauth/omniauth Wiki

Using GET requests


A key part of resolving this vulnerability is to avoid allowing GET requests for /auth/:provider.

この脆弱性を解決するキーパートは /auth/:provider のGETリクエストを許可しないことです。

If using GET links to /auth/:provider is essential for your application (for example, if you are ever redirecting to /auth/:provider as part of an authentication process), then you will need to put together a more involved solution for your specific needs. This may mean redirecting to a standard log-in screen which includes link_to 'Log in', '/auth/:provider', method: :post or another POST/form-based approach (like button_to).

アプリで /auth/:provider のGETへのリンクが不可欠な場合(たとえば、認証プロセスで /auth/:provider にリダイレクトする場合)、より複雑な解決方法が必要。

これは普通のログインに以下を含む link_to 'Log in;, '/auth/:provider', method: :post か、他のPOST/form-based 

Mitigating in Rails applications


  1. Add Rails' inbuilt CSRF protection to the POST requests by using the omniauth-rails_csrf_protection gem: # Gemfile gem 'omniauth-rails_csrf_protection', '~> 0.1'

Rails アプリに omniauth-rails_csrf_protection GEM を加える

2 . Update all links to /auth/:provider to use POST requests.

/auth/:provider へのリンクをアップデートし、POSTを使うようにする。

3 . If you're using bundler-audit, you will need to explicitly ignore the CVE:
bundle audit check --ignore CVE-2015-9284

bundler-audit を使っているのならば、本CVEを無視するようにする。

※ bundler-audit はGEMのCVEチェックをしてくれるツール

bundler-audit の警告を無視するための、シンプルな方法 - Qiita

4 . If you are continuing to use GET requests to access /auth/:provider then you will need to explicitly enable it, as omniauth-rails_csrf_protection modifies the default to be POST-only (but remember that using GET requests for /auth/:provider is not recommended and you should try to stick to POST requests if at all possible):

GETリクエストを使用して /auth/:provider にアクセスし続ける場合、omniauth-rails_csrf_protectionはデフォルトをPOSTのみに変更するため、明示的に有効にする必要があります。
(ただし GETリクエストの使用は推奨されません。可能な限り、POSTリクエストにすべき)。

Mitigating in non-Rails applications


1 . Add CSRF protection to OmniAuth POST requests with the rack-protection gem, using an approach similar to that which @abrom has put together: https://gist.github.com/abrom/effe58b27a4f4ac1b97fb85593d7c3be.

rack-protection GEMを用追加せよ

2 . Provided you do not need GET access to /auth/:provider, you should ensure only POST requests are allowed:

/auth/:provider へはPOSTリクエストのみを許可する

3 . Update all links to /auth/:provider to use POST requests. You will need to craft forms that POST to /auth/:provider, and have a hidden field with the value of the session's CSRF token. The rack-protection source code has a good example: https://github.com/sinatra/sinatra/blob/eee711bce740d38a9a91aa6028688c9a6d74b23b/rack-protection/lib/rack/protection/authenticity_token.rb#L63

すべての /auth/:provider リンクを、POSTにアップデートせよ。ポストする際にはセッションのCSRFトークンをhidden-fieldに加えてポストせよ。

4 . If you're using bundler-audit, you will need to explicitly ignore the CVE:


Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up