Endo Tech Blog

Techブログと言う名のただのブログです。

【翻訳】Laravelを5.6から5.6.30にアップグレードする(Security Release)

Laravelのセキュリティリリースがアナウンスされました。

laravel-news.com

このセキュリティ修正が入るverは5.6.305.5.42です。

記事によるとアプリケーションの暗号化キーである APP_KEYが悪意のある第三者に渡ってしまった場合に起きるという事なので、大前提としてAPP_KEY流失させない and もし流失してしまっているなら暗号化キー変更するようにして下さい。

なお、readoubleでもアップグレード方法が日本語で記載されているのでこちらもご覧下さい!

アップグレードガイド 5.6 Laravel

以下はLaravelNewsの記事の翻訳とアップグレードガイドの紹介です。

この翻訳記事はLaravel Newsの運営者である、Eric L. Barnesさんに許可を頂いて翻訳しています。

Security Release: Laravel v5.6.30 and v5.5.42 have been released

Laravel 5.6.30 and Laravel 5.5.42 have both been released to fix a security issue and is recommended that all users upgrade as soon as possible. According to the upgrade docs:

Laravel 5.6.30とLaravel 5.5.42は両方のバージョンでセキュリティ問題を解決するためにリリースされており、できるだけ早くアップグレードすることをお勧めします。アップグレードドキュメントによると

This vulnerability may only be exploited if your application encryption key (APP_KEY environment variable) has been accessed by a malicious user. Typically, it is not possible for users of your application to gain access to this value. However, ex-employees that had access to the encryption key may be able to use the key to attack your applications. If you have any reason to believe your encryption key is in the hands of a malicious party, you should always rotate the key to a new value.

この脆弱性は、アプリケーションの暗号化キー(APP_KEY環境変数)が悪意のあるユーザーが渡った場合にのみ悪用される可能性があります。 通常、アプリケーションのユーザーがこの値にアクセスすることはできません。 ただし、暗号化キーにアクセスした事のある元従業員は、キーを使用してアプリケーションを攻撃することができます。 暗号化キーが悪意のあるユーザーの手に入ると思われる理由がある場合は、そのキーを常に新しい値に変更して下さい。

Laravel 5.6.30 also contains a breaking change to cookie encryption and serialization logic, so please read the upgrade notes carefully before performing an upgrade.

Laravel 5.6.30には、Cookieの暗号化とシリアライズ処理が含まれていますので、アップグレードを行う前にアップグレードノートをよく読んで下さい。

It’s also worth pointing out again that this is only exploitable if a bad person has your APP_KEY and this shouldn’t ever happen unless a disgruntled ex-employee has it or you’ve left it open in a public git repo or something

この脆弱性は攻撃者があなたのアプリケーションの暗号化キーを持っているか、不満持っていた元従業員が持っているか、git repoで暗号化キーを公開しない限りは、利用されないという事を再度お伝えします。

The upgrade guide includes everything you need to know on this release and the security impact, so please read it.

アップグレードガイドには、今回のリリースで知っておくべき情報とセキュリティへの影響が含まれていますので、是非読んでみて下さい。

Upgrading To 5.6.30 From 5.6 (Security Release)

laravel.com

Laravel 5.6.30 is a security release of Laravel and is recommended as an immediate upgrade for all users. Laravel 5.6.30 also contains a breaking change to cookie encryption and serialization logic, so please read the following notes carefully when upgrading your application.

Laravel 5.6.30はLaravelのセキュリティ リリースであり、すべてのユーザーに対して速やかにアップグレードする事を推奨しています。 Laravel 5.6.30には、Cookieの暗号化とシリアライゼーションに関する処理の変更も含まれていますのでアップグレードする際には、以下の注意事項をよくお読みください。

This vulnerability may only be exploited if your application encryption key (APP_KEY environment variable) has been accessed by a malicious user.

この脆弱性は、アプリケーションの暗号キーである (APP_KEY 環境変数)が悪意のあるユーザにアクセスされる場合に起きます。

Typically, it is not possible for users of your application to gain access to this value. However, ex-employees that had access to the encryption key may be able to use the key to attack your applications. If you have any reason to believe your encryption key is in the hands of a malicious party, you should always rotate the key to a new value.

通常ユーザーがこの値にアクセスすることはできません。ただし、暗号化キーにアクセスした事にある元従業員がそのキーを使用してアプリケーションを攻撃することはできます。暗号化キーが悪意のあるユーザーの手に渡ったと思われる場合は、そのキーを常に新しい値に変更して下さい。

Cookie Serialization

Laravel 5.6.30 disables all serialization / unserialization of cookie values. Since all Laravel cookies are encrypted and signed, cookie values are typically considered safe from client tampering

Laravel 5.6.30では Cookieのシリアライズ化/非シリアライズ化をすべて無効にします。すべてのLaravelのCookieは、暗号化され、署名されているため通常クライアントからの改ざんに安全だと考えられています。

However, if your application's encryption key is in the hands of a malicious party, that party could craft cookie values using the encryption key and exploit vulnerabilities inherit to PHP object serialization / unserialization, such as calling arbitary class methods within your application.

しかし、アプリケーションの暗号化キーが悪意のある人の手に渡ると、暗号化キーを使用してCookie値を作成し、PHPオブジェクトのシリアライズ化/非シリアライズ化に継承される脆弱性を悪用されて、アプリケーション内の任意のクラスメソッドを呼び出す事ができてしまいます。

Disabling serialization on all cookie values will invalidate all of your application's sessions and users will need to log into the application again. In addition, any other encrypted cookies your application is setting will have invalid values. For this reason, you may wish to add additional logic to your application to validate that your custom cookie values match an expected list of values you expect; otherwise, you should discard them.

すべてのCookieでシリアライズを無効にすると、アプリケーションに含まれているセッションが無効になりユーザーはアプリケーションに再度ログインする必要があります。さらに、アプリケーションが使用している他の暗号化されたCookieの設定値も無効になります。このため、アプリケーションに機能を追加して、Cookie値が予期した値が一致することを検証するようにして下さい。さもなければ、そのCookieは破棄して下さい。

Configuring Cookie Serialization

Since this vulnerability is not able to be exploited without access to your application's encryption key, we have chosen to provide a way to re-enable encrypted cookie serialization while you make your application compatible with these changes.

この脆弱性はアプリケーションの暗号化キーへのアクセスなしに悪用される可能性がない為、ここでは暗号化されたCookieのシリアル化を再度有効にして、アプリケーションに互換性を持たせる方法を紹介します。

To enable / disable cookie serialization, you may change the static serialize property of the App\Http\Middleware\EncryptCookiesmiddleware

クッキーのシリアライズをを有効/無効にするにはApp\Http\Middleware\EncryptCookiesミドルウェアのserializestaticプロパティを以下のように変更して下さい。

/**
 * Indicates if cookies should be serialized.
 *
 * @var bool
 */
protected static $serialize = true;

Note: When encrypted cookie serialization is enabled, your application will be vulnerable to attack if its encryption key is accessed by a malicious party. If you believe your key may be in the hands of a malicious party, you should rotate the key to a new value before enabling encrypted cookie serialization.

注意:暗号化されたCookieのシリアライズ化が有効になっていると、暗号化キーが悪意のあるユーザーからアクセスされた際に、アプリケーションが攻撃を受けやすくなります。 アプリケーションの暗号化キーが悪意のある人の手元にあると思われる場合は、暗号化されたCookieのシリアライズを有効にする前に、暗号化キーを新しい値に変更して下さい。

余談

この件はredditでも上がっています。

ここにTaylor Otwellさん、自身がコメントしているみたいなので、そちらを紹介して終わろうと思います。

www.reddit.com

That cookie will contain some serialization garbage if the cookie was previously serialized (the previous default behavior) and serialization is turned off (the default behavior in 5.6.30). You would need to invalidate it and reset it within your application. I honestly never use cookies at all (other than the default Laravel session stuff) so it doesn't affect me much but wanted to point it out.

Cookieが以前にシリアライズされていた(以前のデフォルトの動作)、或いはシリアライゼーションがオフになっている場合(5.6.30のデフォルトの動作)、そのCookieにはシリアライゼーションガーベジが含まれいます。 だから、無効化してアプリケーション内でリセットする必要があります。 正直なところ、(Laravelセッションのデフォルトのもの以外の)Cookieを全く使用しないので、私にはあまり影響しないけど、この件は指摘しなければ、と思いました。

It kind of sucks but I think was worth doing, even if the chance of exploitation is pretty remote for most applications.

まぁ確かに大変だと思うけど、たとえこの脆弱性がほとんどのアプリケーションで稀なケースだとしてもやる価値はあると思います。

参考にした資料

PS

翻訳の誤訳、typoの指摘がある場合は遠慮なくブログのコメントにてお伝え下さい。 速やかに修正致します。