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;
class Admin
{
/**
* Handle an incoming request.
*
* @param \Illuminate\Http\Request $request
* @param \Closure $next
* @return mixed
*/
public function handle($request, Closure $next)
{
$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 :Route::middleware('admin')->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. Avec la version 8 ce trait a disparu et si on veut ce type de protection il faut utiliser Jetstream, c'est du moins ce qui est précisé dans la documentation...
En fait c'est Fortify qui assure cette protection, si on regarde dans config/fortify.php on trouve ce code :/*
|--------------------------------------------------------------------------
| Rate Limiting
|--------------------------------------------------------------------------
|
| By default, Fortify will throttle logins to five requests per minute for
| every email and IP address combination. However, if you would like to
| specify a custom rate limiter to call then you may specify it here.
|
*/
'limiters' => [
'login' => null,
],
Donc si on n'utilise pas jetstream mais quand même Fortify pour l'authentification (et on aurait bien tort de ne pas le faire) on bénéficie de automatiquement cette protection. On voit que par défaut l'utilisateur a droit à 5 essais par minute. Si on veut changer ça il faut préciser un rate limiter. On va voir tout de suite de quoi il s'agit.
Rate limiter
Laravel 8 propose 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. Prenons l'exemple d ela documentation :
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;
RateLimiter::for('global', function (Request $request) {
return Limit::perMinute(1000);
});
Ici on met en place un limiteur qui va fixer le maximum à 1000 accès par minites. 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
{
/**
* Authorization
*
* @return boolean
*/
public function authorize()
{
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
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\HandlesAuthorization;
class UserPolicy
{
use HandlesAuthorization;
/**
* Determine whether the user can view any models.
*
* @param \App\Models\User $user
* @return mixed
*/
public function viewAny(User $user)
{
//
}
/**
* Determine whether the user can view the model.
*
* @param \App\Models\User $user
* @param \App\Models\User $model
* @return mixed
*/
public function view(User $user, User $model)
{
//
}
/**
* Determine whether the user can create models.
*
* @param \App\Models\User $user
* @return mixed
*/
public function create(User $user)
{
//
}
/**
* Determine whether the user can update the model.
*
* @param \App\Models\User $user
* @param \App\Models\User $model
* @return mixed
*/
public function update(User $user, User $model)
{
//
}
/**
* Determine whether the user can delete the model.
*
* @param \App\Models\User $user
* @param \App\Models\User $model
* @return mixed
*/
public function delete(User $user, User $model)
{
//
}
/**
* Determine whether the user can restore the model.
*
* @param \App\Models\User $user
* @param \App\Models\User $model
* @return mixed
*/
public function restore(User $user, User $model)
{
//
}
/**
* Determine whether the user can permanently delete the model.
*
* @param \App\Models\User $user
* @param \App\Models\User $model
* @return mixed
*/
public function forceDelete(User $user, User $model)
{
//
}
}
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)
{
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).
Par bestmomo
Nombre de commentaires : 2