Sécurité
1Introduction
Temma fournit nativement un ensemble d'outils pour sécuriser vos applications web : authentification et contrôle d'accès, validation des données entrantes, protection contre les injections SQL, le XSS et le CSRF, sessions sécurisées…
Cette page donne une vue d'ensemble des bonnes pratiques de sécurité dans une application Temma. Chaque section renvoie vers les pages de documentation détaillées.
2Authentification et contrôle d'accès
Temma fournit un système complet d'authentification des utilisateurs, ainsi qu'un mécanisme de contrôle d'accès basé sur des rôles et des services.
- La page Authentification explique pas-à-pas comment mettre en place un système d'authentification sans mot de passe (passwordless).
- Le contrôleur/plugin Auth gère le formulaire de connexion, l'envoi des liens magiques par email et la session utilisateur.
- L'attribut Auth restreint l'accès aux contrôleurs et aux actions en fonction de l'authentification de l'utilisateur, de ses rôles et de ses services.
- Le plugin API sécurise les API avec une authentification par clés publiques/privées.
3Validation des données entrantes
Toute donnée provenant de l'extérieur (paramètres d'URL, variables GET et POST, payload JSON, fichiers téléversés) doit être validée avant d'être utilisée.
- La page Validation des données présente le système complet de validation de Temma, en entrée comme en sortie.
- Les attributs Check permettent de valider les données entrantes de manière déclarative, directement sur les contrôleurs et les actions.
- Le helper DataFilter valide et filtre des données à partir d'un contrat définissant le type et les contraintes attendus.
4Injections SQL
Une injection SQL consiste à faire exécuter des requêtes arbitraires en profitant de données insérées dans une requête sans échappement. Ne construisez jamais une requête SQL en concaténant des données non échappées.
La source de données SQL fournit tout ce qu'il faut pour s'en protéger :
- Le paramètre parameters des méthodes exec(), queryOne() et queryAll(), qui échappe automatiquement les valeurs.
- Les requêtes préparées, dont les paramètres sont eux aussi échappés automatiquement.
- Les méthodes quote() et quoteNull() pour les échappements explicites.
5Cross-site scripting (XSS)
Une attaque XSS consiste à faire afficher par le site du code HTML ou JavaScript malveillant, généralement injecté au travers de contenus fournis par les utilisateurs.
- La vue Smarty active par défaut l'échappement automatique : toutes les variables affichées dans les templates sont échappées, sauf usage explicite du modificateur |raw. N'utilisez ce modificateur que sur des contenus sûrs.
- Le helper HTMLCleaner nettoie les flux HTML fournis par les utilisateurs (par exemple depuis un éditeur WYSIWYG), en supprimant tout code interdit.
6Cross-site request forgery (CSRF)
Une attaque CSRF consiste à faire exécuter une action sensible à un utilisateur authentifié à son insu, en déclenchant une requête vers votre site depuis un site tiers.
Trois mécanismes se combinent pour s'en protéger :
- N'acceptez que des requêtes POST pour les actions sensibles, grâce à l'attribut Method.
- Les cookies de session créés par Temma ont le paramètre SameSite=Lax : ils ne sont pas envoyés lors des requêtes POST provenant d'un autre domaine. Une requête POST forgée depuis un site tiers arrive donc sans session, et l'action protégée par authentification est refusée.
- L'attribut Referer permet de vérifier que la requête provient bien d'une page de votre propre site.
7Server-side request forgery (SSRF)
Une attaque SSRF consiste à amener le serveur à effectuer lui-même des requêtes vers une cible contrôlée par l'attaquant (par exemple un service interne inaccessible depuis l'extérieur), en manipulant une donnée entrante utilisée pour construire la requête.
La protection principale est la validation stricte des données entrantes utilisées pour construire des requêtes côté serveur. Autant que possible, ne laissez pas l'utilisateur fournir une URL libre : préférez une liste blanche de valeurs autorisées (par exemple avec le type enum du DataFilter), à partir desquelles le serveur construit lui-même l'URL finale.
8Sessions et cookies
Les sessions gérées par Temma sont sécurisées par défaut :
- Les cookies de session sont créés avec les paramètres httponly (inaccessibles en JavaScript), secure (en HTTPS) et SameSite=Lax (voir la section CSRF ci-dessus).
- Les identifiants de session sont générés par un générateur pseudo-aléatoire cryptographiquement sûr.
- Les données de session sont stockées côté serveur (par le moteur de sessions de PHP, ou dans une source de données comme Redis ou Memcache) ; seul l'identifiant de session transite dans le cookie.
9La configuration x-security
Les directives de configuration liées à la sécurité sont regroupées dans la configuration étendue x-security du fichier etc/temma.php.
| Clé | Rôle | Utilisée par |
|---|---|---|
| redirect | URL de redirection par défaut en cas d'accès refusé | attributs Auth, Method, Referer et Check |
| authRedirect | URL de redirection spécifique en cas de refus d'authentification | attribut Auth |
| authVariable | Nom de la variable de template contenant l'utilisateur courant | attribut Auth |
| methodRedirect | URL de redirection spécifique en cas de méthode HTTP refusée | attribut Method |
| refererRedirect, refererDomain, refererUrl, refererPath | Redirection et critères de vérification du referer | attribut Referer |
| auth | Sous-configuration du système d'authentification (personnalisation des emails, des tables, etc.) | contrôleur/plugin Auth et plugin API |
Exemple :
<?php
return [
'x-security' => [
// redirection par défaut en cas d'accès refusé
'redirect' => '/',
// redirection vers le formulaire de connexion si non authentifié
'authRedirect' => '/auth/login',
]
];