More than 1 year has passed since last update.

posted at

updated at

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


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:

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:

すべての /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
What you can do with signing up