GHSA-p62r-7637-3wwc
Laravel Hijacked authentication cookies vulnerability
- Severity
- Medium
- The publisher's own rating, not a CVSS score
- Exploit chance (EPSS)
- —
- No score published
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-384 Session Fixation
- Fix
4.1.26- Upgrade laravel/framework to this version or later
Description
Laravel 4.1.26 introduces security improvements for "remember me" cookies. Before this update, if a remember cookie was hijacked by another malicious user, the cookie would remain valid for a long period of time, even after the true owner of the account reset their password, logged out, etc.
This change requires the addition of a new remember_token column to your users (or equivalent) database table. After this change, a fresh token will be assigned to the user each time they login to your application. The token will also be refreshed when the user logs out of the application. The implications of this change are: if a "remember me" cookie is hijacked, simply logging out of the application will invalidate the cookie.
Affected versions
Packagist
| Package | Vulnerable | Fixed in |
|---|---|---|
| laravel/framework | >= 4.0.0, < 4.1.26 |
4.1.26 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
laravel/framework Packagist → 4.1.26
- composer
composer require laravel/framework:^4.1.26
Weakness
CWE-384: Session Fixation
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
How to prevent it
- Architecture and Design: Invalidate any existing session identifiers prior to authorizing a new user session.
- Architecture and Design: For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again.
- Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
References
Packages
Other links
Timeline
- Published
- Last updated by the source
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| CVE-2018-15133 Laravel Framework RCE Vulnerability | High Known exploited | Also affects laravel/framework |
| GHSA-f9x3-7vq9-cph6 Laravel TokenGuard authentication bypass through non-string API credentials | Critical | Also affects laravel/framework |
| GHSA-5wcm-3v2w-8362 Laravel relationship inclusion can trigger unauthorized data destruction | Medium | Also affects laravel/framework |
| GHSA-jh5r-qr3c-85q8 Laravel: XSS in Debug Page Information | Low | Also affects laravel/framework |
| GHSA-crmm-hgp2-wgrp Laravel Framework: Temporary Signed URL Path Confusion | Medium | Also affects laravel/framework |
| GHSA-5vg9-5847-vvmq Laravel Framework: CRLF injection in default email rule | High | Also affects laravel/framework |
| GHSA-83wp-f5c3-hqqr Laravel framework susceptible to reflected cross-site scripting | Medium | Also affects laravel/framework |
| GHSA-546h-56qp-8jmw Laravel framework susceptible to reflected cross-site scripting | Medium | Also affects laravel/framework |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor