Laravel Cookie Security Releases

Today we released several fixes to address a security vulnerability in the framework that we were notified of during the weekend.

Application's using the "cookie" session driver were the primary applications affected by this vulnerability. Since we have not yet released a security release for the Laravel 5.5 version of the framework, we recommend that all applications running Laravel 5.5 and earlier do not use the "cookie" session driver in their production deployments.

We have also released Passport 9.3.2 to provide compatibility with today's releases. If you are running Passport on Laravel 6.x or 7.x, you should update to today's Passport 9.3.2 release. The Passport release is not a security release; however, the library needed updates to be compatible with today's framework changes.

Regarding the vulnerability, applications using the "cookie" session driver that were also exposing an encryption oracle via their application were vulnerable to remote code execution. An encryption oracle is a mechanism where arbitrary user input is encrypted and the encrypted string is later displayed or exposed to the user. This combination of scenarios lets the user generate valid Laravel signed encryption strings for any plain-text string, thus allowing them to craft Laravel session payloads when an application is using the "cookie" driver.

Today's fix prefixes cookie values with an HMAC hash of the cookie's name before encryption and then verifies a matching hash on decryption, making it impossible to craft a valid cookie payload even if an encryption oracle is exposed via the application.

I would like to personally apologize for the inconvenience of today's security releases since the nature of this fix required us to invalidate existing encrypted cookies issued by Laravel applications. Thank you for your patience and understanding.

Keep reading

General April 4, 2024

Encryption and the In-between

Last year, we introduced a simple but surprisingly useful feature to Laravel Forge: the ability to add notes to servers. While checking the uptake of this feature, we noticed that customers were often storing sensitive data in the field. We hadn’t designed notes to store sensitive information, so we found ourselves in a situation where we now needed to encrypt existing unencrypted data, while also allowing for new data to be inserted as encrypted data - at the same time, the dashboard needed to be able to show the notes correctly whether they had been encrypted or not. Our migration process looked like this: 1. Run a command that encrypts all existing unencrypted server notes. 2. Update our model to cast the `notes` field, encrypting or decrypting as required. To do this, we leaned on [Laravel’s custom casts](https://laravel.com/docs/11.x/eloquent-mutators#custom-casts) feature to handle this “sometimes encrypted” data. We created a new cast `SometimesEncrypted` that allowed us to gracefully decrypt the encrypted notes, or simply return the plaintext version which may have been available during the migration: ```php

James Brooks

Stay connected with the latest Laravel news