Autorisatielek in Livewire maakt acties op andermans gegevens mogelijk

Wat is er gebeurd

Er zijn drie samenhangende problemen ontdekt in de manier waarop het #[Authorize]-attribuut van Livewire autorisatie afdwingt: 1. Parameters in verkeerde volgorde bij acties: #[Authorize] bepaalde welk model gecontroleerd moest worden aan de hand van de array-sleutel, terwijl de actie zelf de parameters positioneel ontving. Door een verzoek te sturen met parameters als object met omgewisselde integer-sleutels (bijvoorbeeld {"1": 2, "0": 1}), kon de autorisatiecontrole slagen voor een record dat de gebruiker wél bezit, terwijl de daadwerkelijke actie werd uitgevoerd op een ander record. Met #[Authorize('delete', 'comment')] op een methode deleteComment(Comment $comment) kon een gebruiker bijvoorbeeld een reactie van iemand anders verwijderen. 2. Hetzelfde probleem deed zich voor bij event listeners die #[On] combineren met #[Authorize] en een modelparameter gebruiken, via de interne __dispatch-aanroep. 3. #[Json]-methoden werden uitgevoerd vóórdat de autorisatie plaatsvond: bij methoden met zowel #[Json] als #[Authorize] werd de inhoud van de methode al uitgevoerd voordat de autorisatiecontrole plaatsvond. Het HTTP-antwoord gaf nog wel een 403-foutcode terug, maar eventuele neveneffecten van de methode (zoals schrijfacties naar de database) hadden dan al plaatsgevonden.

Technische oorzaak

De kern van het probleem is een mismatch tussen de manier waarop #[Authorize] modelparameters herkent (via de array-sleutel) en de manier waarop de onderliggende actie of listener parameters verwerkt (positioneel). Dit verschil kon worden misbruikt door parameters met omgewisselde integer-sleutels mee te sturen. Daarnaast werd bij methoden met #[Json] de inhoud van de methode uitgevoerd vóórdat de #[Authorize]-controle plaatsvond, waardoor autorisatie feitelijk te laat werd gecontroleerd om neveneffecten te voorkomen. Applicaties die autorisatie handmatig binnen de methode zelf uitvoeren (bijvoorbeeld via $this->authorize(...)) in plaats van te vertrouwen op het #[Authorize]-attribuut, zijn niet getroffen. Livewire 3.x is eveneens niet getroffen.

Waarom dit belangrijk is

Elke Livewire-applicatie die het #[Authorize]-attribuut gebruikt op methoden met modelparameters, of op #[Json]-methoden, loopt het risico dat een geauthenticeerde gebruiker ongeautoriseerde acties kan uitvoeren op gegevens van een andere gebruiker — inclusief destructieve acties zoals verwijderen — terwijl de autorisatiecontrole ogenschijnlijk slaagt. Omdat hiervoor slechts beperkte rechten nodig zijn en geen interactie van het slachtoffer vereist is, is dit relatief eenvoudig te misbruiken door een geauthenticeerde aanvaller die de structuur van het verzoek begrijpt.

Getroffen versies

Versies van livewire/livewire vanaf 4.3.0 tot (maar niet inclusief) 4.4.8 zijn getroffen. Livewire 3.x wordt expliciet als niet-getroffen genoemd. Het probleem is verholpen in versie 4.4.8.

Oplossingen en mitigatie

De leverancier heeft versie 4.4.8 uitgebracht, waarin alle drie de problemen zijn verholpen: parameters bij calls en events moeten nu als lijst of met benoemde (string) sleutels worden aangeleverd, anders wordt het verzoek geweigerd, en #[Json]-methoden worden nu geautoriseerd vóórdat hun inhoud wordt uitgevoerd. Als directe update niet mogelijk is, kunnen applicaties dit risico beperken door expliciet $this->authorize(...) aan te roepen binnen de getroffen methoden, in plaats van uitsluitend op het #[Authorize]-attribuut te vertrouwen.

Aanbevolen actie

Werk livewire/livewire zo snel mogelijk bij naar versie 4.4.8 of hoger. Als directe update niet mogelijk is, controleer dan alle methoden die het #[Authorize]-attribuut gebruiken met modelparameters of #[Json], en voeg als tijdelijke mitigatie expliciete $this->authorize(...)-aanroepen toe.