Base de Connaissances

Des formulaires PHP non sécurisés ? Voici comment valider et filtrer toutes les entrées utilisateur avec les fonctions natives de PHP – sans se prendre la tête.

Les sessions PHP permettent de maintenir un état utilisateur entre les requêtes HTTP (ex : authentification, paniers d'achat). Une mauvaise configuration expose votre application à des attaques comme :

• Session Hijacking (vol de cookie via XSS ou sniffing réseau).
• Session Fixation (forcer un ID de session connu à un utilisateur).
• CSRF (Cross-Site Request Forgery) si SameSite est mal configuré.

✅ Bonnes pratiques clés :

1. Régénérer l’ID de session (session_regenerate_id(true)) uniquement aux moments critiques (login, logout, changement de mot de passe).
2. Configurer les cookies avec HttpOnly, Secure, et SameSite=Strict.
3. Détruire proprement les sessions (session_unset() + session_destroy()).
4. Stocker les sessions hors du DocumentRoot (ou utiliser Redis/une base de données).
5. Limiter la durée de vie des sessions (ex : 30 min d’inactivité).

🔹 Cas d’usage :

• Authentification utilisateur.
• Panier d’achat (e-commerce).
• Préférences utilisateur (thème, langue).

Le guide ultime pour maîtriser la gestion moderne des mots de passe en PHP : sécurisé, pratique et garanti sans MD5.

Le CSRF (Cross-Site Request Forgery) est une attaque qui force un utilisateur authentifié à exécuter des actions non désirées sur une application web, sans son consentement.

• Mécanisme : Un site malveillant (ou un email piégé) envoie une requête HTTP à l’insu de la victime vers un site vulnérable (ex: bank.com/transfer?to=hacker&amount=1000), en exploitant :
  • Les cookies de session déjà actifs (l’utilisateur est connecté).
  • L’absence de vérification de l’origine de la requête.
• Impact :
  • Modification de données (ex: changement de mot de passe, transfert d’argent).
  • Actions administratives (suppression de compte, envoi de messages).
• Exemple concret : Une victime connectée à facebook.com clique sur un lien malveillant qui envoie une requête POST pour publier un message à son insu ou ajouter un ami frauduleux.

⚠️ Pourquoi c’est dangereux ? Contrairement au XSS (qui vole des données), le CSRF exploite la confiance du serveur envers l’utilisateur authentifié.

Le Cross-Site Scripting (XSS) est une faille de sécurité qui permet à un attaquant d’injecter du code JavaScript malveillant dans des pages web consultées par d’autres utilisateurs. Cela se produit quand une application PHP affiche des données utilisateur non filtrées (ex : commentaires, champs de formulaire, URL) sans les échapper correctement.

Exemple vulnérable :

<!-- Affichage direct d'une entrée utilisateur -->
<p>Bonjour, <?php echo $_GET['nom']; ?> !</p>

Attaque : Si un utilisateur visite http://site.com/page.php?nom=<script>alert('Hacké !')</script>, le JavaScript s’exécute dans son navigateur.

Types de XSS :

1. XSS stocké (Persistant) : Le code malveillant est sauvegardé dans une base de données (ex : commentaire, profil utilisateur) et s’exécute à chaque affichage.
2. XSS réfléchi (Non-persistant) : Le code est inclus dans une URL ou un formulaire et s’exécute immédiatement (ex : lien piégé).
3. XSS DOM-based : L’injection se produit côté client via une manipulation du DOM (ex : document.write()).

Risques :

• Vol de cookies/sessions (ex : document.cookie envoyé à un serveur malveillant).
• Redirection vers des sites frauduleux.
• Keylogging (capture des frappes clavier).
• Défiguration du site (ex : remplacement du contenu).

L’injection SQL est une faille de sécurité critique qui permet à un attaquant d’exécuter des requêtes SQL malveillantes en exploitant des entrées utilisateur non sécurisées (ex : formulaires, URL, cookies). En PHP, cela arrive souvent quand des données utilisateur sont concatenées directement dans une requête SQL sans validation ni échappement.

Exemple vulnérable :

$username = $_POST['username'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";
$result = mysqli_query($conn, $query);

Un attaquant pourrait injecter ' OR '1'='1 comme nom d’utilisateur pour contourner l’authentification.

Risques :

• Vol/modification de données (ex : suppression de tables avec DROP TABLE users).
• Prise de contrôle du serveur (si le SGBD a des privilèges élevés).
• Fuites d’informations sensibles (ex : mots de passe, données clients).