Base de Connaissances

Le code mort désigne tout élément du code source qui n'est ni exécuté, ni appelé, mais reste présent dans la base. Cela inclut :

• Fonctions/méthodes non utilisées
• Variables déclarées mais jamais lues
• Imports/modules inutilisés
• Fichiers orphelins (non référencés)
• Branches de code inatteignables (ex : if (false))
• Commentaires ou annotations obsolètes

Problèmes concrets :

• Sécurité : Code vulnérable oublié (ex : fonctions de debug exposées).
• Maintenance : Temps perdu à analyser des portions inutiles.
• Fiabilité : Risque de régression si un développeur réutilise du code obsolète par erreur.

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 MVC (Modèle-Vue-Contrôleur) est un design pattern architectural largement utilisé en développement web pour séparer les responsabilités entre la logique métier, l'interface utilisateur et la gestion des requêtes. En PHP, ce modèle permet d'organiser le code de manière modulaire, maintenable et évolutive, en évitant le mélange de HTML et de logique PHP dans un seul fichier.

🔹 Avantages : ✅ Meilleure séparation des concerns (logique, affichage, contrôle) ✅ Code plus lisible et maintenable ✅ Réutilisabilité des composants ✅ Facilité de collaboration en équipe ✅ Testabilité améliorée (unit tests, intégration tests)

🔹 Cas d'usage :

• Développement d'applications web structurées (CMS, e-commerce, SaaS)
• Projets nécessitant une évolutivité (ajout de fonctionnalités sans tout réécrire)
• Équipes travaillant en agile avec une base de code propre

Clés d'API en clair ? Mots de passe commités sur GitHub ? Ne soyez pas la prochaine victime d'une fuite de données. Découvrez le guide universel pour maîtriser .env et .gitignore sur PHP, JS, Python et plus encore. Une méthode unique pour sécuriser tous vos projets.

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

Si vous vous intéressez à la cybersécurité, vous avez forcément croisé le terme de "Sel" (ou Salt en anglais). Mais à quoi sert-il concrètement ? Est-ce un ingrédient de cuisine ou un outil de sécurité ?

Spoiler : C’est ce qui empêche un pirate de craquer des milliers de comptes en une seule seconde après avoir volé une base de données.

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 pattern Checks-Effects-Interactions (CEI) est une bonne pratique de sécurité en Solidity qui consiste à ordonner les opérations d’une fonction dans un ordre strict pour éviter :

• Les attaques par reentrancy (ex : exploit du DAO en 2016).
• Les incohérences d’état (ex : double dépense, sols négatifs).
• Les échecs silencieux (ex : transfer() qui échoue sans revert).

Problème sans CEI : Si un contrat modifie son état après un appel externe, un attaquant peut rappeler la fonction avant la mise à jour de l’état (via un fallback() malveillant), ce qui conduit à des boucles de retrait infinies ou des états corrompus.

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).