Laravel 10

Cours Laravel 10 – la sécurité – on se protège

28 février 2023 /

Lorsqu’on développe une application on prend plein de précautions, par exemple les utilisateurs doivent s’authentifier pour éviter des actions non autorisées. Dans le code on peut vérifier si la personne est authentifiée et quel est son degré d’habilitation. On a vu que Jetstream introduit une gestion complète des équipes avec des rôles et des permissions.

En dehors de l’authentification on doit gérer certaines situations comme par exemple savoir si un utilisateur authentifié a le droit de modifier une ressource particulière. Laravel nous offre un système d’autorisations bien pratique.

L’authentification

Les middlewares

On a déjà vu l’authentification en détail dans un précédent chapitre. On peut aussi gérer les utilisateurs authentifiés selon un rôle ou leur degré d’habilitation sans nécessairement utiliser Jetstream. On peut filtrer les accès selon un statut avec des middlewares. Par exemple on peut créer un middleware Admin :

Avec ce code :

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

class Admin
{
    /**
     * Handle an incoming request.
     *
     * @param  \Closure(\Illuminate\Http\Request): (\Symfony\Component\HttpFoundation\Response)  $next
     */
    public function handle(Request $request, Closure $next): Response
    {
        $user = $request->user();
        if ($user && $user->role === 'admin') {
            return $next($request);
        }
        return redirect()->route('home');
    }
}

Dans la méthode handle on récupère l’utilisateur en cours ($request->user()) et on teste s’il s’agit d’un administrateur en imaginant que dans la table users on a créé une colonne role ($user->role === ‘admin’).

On peut ainsi filtrer les routes réservées aux administrateurs :

use App\Http\Middleware\Admin;

Route::middleware(Admin::class)->group(function () {
    ...
}

Le throttle

Jusqu’à la version 7, Laravel intégrait automatiquement dans l’authentification une sécurisation de la connexion contre les attaques « brute force ». On disposait d’un trait  Illuminate\Foundation\Auth\AuthenticatesUsers qu’il suffisait d’inclure dans le contrôleur de connexion. A compter de la version 8 il faut utiliser Breeze ou Jetstream pour en bénéficier. Au niveau du fonctionnement, l’utilisateur est bloqué pendant une minute au bout d’un certain nombre d’essais infructueux.

Rate limiter

On dispose d’un limiteur d’accès qu’on peut appliquer à une route ou un groupe de routes. Comme il s’agit de route on utilise le provider RouteServiceProvider. Il y a déjà ce code par défaut :

protected function configureRateLimiting(): void
{
    RateLimiter::for('api', function (Request $request) {
        return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());
    });
}

Ici on a un limiteur qui va fixer le maximum à 60 accès par minutes pour les API. Au-delà on obtient une erreur 429 ou une réponse personnalisée. Il est possible d’affiner selon l’utilisateur ou le type, je vous renvoie à la documentation pour ces précisions.

Pour l’application du limiteur on utilise un middleware :

Route::middleware(['throttle:uploads'])->group(function () {
    Route::post('/articles', function () {
        //
    });

    ...
});

Quelques éléments à prendre en considération

Les injections SQL

Une injection SQL est une attaque qui consiste à ajouter à une requête inoffensive un complément qui peut être dangereux pour l’application (des explications plus précises ici).

Si vous utilisez Eloquent vous êtes automatiquement immunisé contre ces attaques.

Par contre si vous faites des requêtes avec par exemple DB::raw() ou whereRaw, autrement dit si vous contournez Eloquent, alors vous devez vous-même vous prémunir contre les attaques SQL.

CSRF

Je vous ai déjà parlé de la protection CSRF dans ce cours, elle est automatiquement mise en place par Laravel.

XSS (Cross-Site Scripting)

Dans ce cas c’est une injection insidieuse de Html ou de JavaScript. Laravel ne fait pas de nettoyage des entrées en dehors de la validation. Si vous voulez en faire un libre à vous, par exemple avec ce composant. Par contre vous avez avec Blade la syntaxe sécuritaire {{ .. }} qui « échappe » les données à l’affichage.

Faites très attention avec la syntaxe {!! … !!} ! En gros vous devez l’éviter avec des données issues de l’extérieur de l’application.

L’assignation de masse

Je vous ai déjà parlé de l’assignation de masse. Vous devez choisir avec soin les colonnes des tables qui sont sans danger dans une mise à jour de masse, celles que vous mettez dans la propriété $fillable (ou $guarded avec la logique inverse) d’un modèle.

Les requêtes de formulaire

Un autre lieu où on peut sécuriser l’application est au niveau des requêtes de formulaires. On a vu qu’il y a une méthode authorize.

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

abstract class Request extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     */
    public function authorize(): bool
    {
        return true;
    }

    ...
}

Vous pouvez ici vérifier par exemple si un utilisateur a le droit d’utiliser effectivement le formulaire et renvoyer false si ce n’est pas le cas.

Généralités

Il y a des choses qui vont sans dire mais beaucoup mieux en les disant. Laravel ne peut pas être en toute sécurité sur un serveur qui ne l’est pas, donc le choix de l’hébergement est un facteur important à prendre en compte et la présence d’un bon Firewall est indispensable. De plus le SSH devient de nos jours incontournable.

Il faut aussi régulièrement mettre à jour Laravel et les packages associés. Il y a régulièrement des correctifs de sécurité et si on ne les installe pas on se retrouve exposé.

Faites des sauvegarde de votre site et surtout de la base de données ! On n’est jamais à l’abri d’un accident…

Les autorisations

En plus de ces possibilités Laravel nous offre un système complet d’autorisations. Pour voir de quoi il s’agit on va prendre un exemple simple. On va créer une ressource pour les utilisateurs à partir d’une installation de base de Laravel équipé de l’authentification :

php artisan make:controller UserController --resource

Changez ainsi le code de ces deux fonctions :

public function edit($id)
{
    return 'Formulaire pour modifier';
}

public function update(Request $request, $id)
{
    return 'Ok on a modifié !';
}

Et les routes correspondantes qu’on protège avec le middleware auth :

use App\Http\Controllers\UserController;

Route::resource('users', UserController::class)->middleware('auth');

Maintenant on est sûrs que seules les personnes authentifiées peuvent accéder à la ressource mais… si quelqu’un veux faire une modification sur un utilisateur, donc passer par les routes users.edit et users.update il serait souhaitable de ne laisser l’accès à un utilisateur que pour ses propres informations. Autrement dit si on a l’utilisateur avec l’id 6 il ne doit avoir accès qu’aux urls :

  • users/6
  • users/6/edit

Comment réaliser celà ?

On dispose d’une commande pour créer une autorisation :

php artisan make:policy UserPolicy --model=User

Comme on a mentionné le modèle on a déjà toutes les méthodes prêtes :

<?php

namespace App\Policies;

use App\Models\User;
use Illuminate\Auth\Access\Response;

class UserPolicy
{
    /**
     * Determine whether the user can view any models.
     */
    public function viewAny(User $user): bool
    {
        //
    }

    /**
     * Determine whether the user can view the model.
     */
    public function view(User $user, User $model): bool
    {
        //
    }

    /**
     * Determine whether the user can create models.
     */
    public function create(User $user): bool
    {
        //
    }

    /**
     * Determine whether the user can update the model.
     */
    public function update(User $user, User $model): bool
    {
        //
    }

    /**
     * Determine whether the user can delete the model.
     */
    public function delete(User $user, User $model): bool
    {
        //
    }

    /**
     * Determine whether the user can restore the model.
     */
    public function restore(User $user, User $model): bool
    {
        //
    }

    /**
     * Determine whether the user can permanently delete the model.
     */
    public function forceDelete(User $user, User $model): bool
    {
        //
    }
}

Il faut ensuite déclarer cette autorisation dans le provider AuthServiceProvider. Mais comme Laravel est conciliant, si on respecte les appelations, ce qui est le cas ici parce que j’ai respecté le nom du modèle, la déclaration est automatique. On va donc protéger la méthode update :

public function update(User $user, User $model): bool
{
    return auth()->id() === $model->id;
}

Il ne reste plus qu’à utiliser l’autorisation dans le contrôleur :

use App\User;

...


public function edit(User $user)
{
    $this->authorize('update', $user);

    return 'Formulaire pour modifier';
}

public function update(Request $request, User $user)
{
    $this->authorize('update', $user);
    
    return 'Ok on a modifié !';
}

Et maintenant si c’est le bon utilisateur il a l’accès sinon il tombe sur une erreur 404.

Plutôt que d’intervenir dans chaque méthode de la ressource on peut aussi faire agir l’autorisation globalement sur la ressource avec ce code dans le constructeur :

public function __construct()
{
    $this->authorizeResource(User::class, 'user');
}

Vous pouvez trouver la documentation complète ici.

En résumé

  • L’authentification permet de sécuriser une application et d’adapter l’affichage selon le degré d’habilitation de l’utilisateur.
  • Eloquent immunise contre les injections SQL.
  • La protection CSRF est automatiquement mise en place par Laravel.
  • Il faut être très prudent avec la syntaxe {!! … !!} de Blade.
  • On peut sécuriser les requêtes de formulaire avec leur méthode authorize.
  • Laravel comporte un système complet et simple de gestion des autorisations (policies).

 

Print Friendly, PDF & Email

Laisser un commentaire