La sécurité des Applications Web : Comprendre les Vulnérabilités

Les applications web jouent un rôle essentiel dans notre vie quotidienne, mais leur sécurité est souvent mise à l’épreuve. Les attaques malveillantes peuvent compromettre les données sensibles des utilisateurs, provoquer des perturbations et causer des dégâts considérables. Dans cet article, nous examinerons de près certaines des vulnérabilités les plus courantes auxquelles les applications web sont confrontées, notamment les failles XSS, CORS, CSP, les injections SQL, BROKEN AUTHENTICATION, l’exposition de données sensibles, XML External Entities, BROKEN ACCESS CONTROL et la désérialisation non sécurisée, ainsi que leurs définitions techniques et des exemples commentés de code.

1. Sécurité Faille XSS (Cross-Site Scripting)

La faille XSS est une vulnérabilité qui permet à des attaquants d’injecter des scripts malveillants dans des pages web consultées par d’autres utilisateurs. Cela se produit lorsque les données fournies par l’utilisateur ne sont pas correctement validées et sont affichées sans échappement dans le code HTML, permettant ainsi l’exécution de scripts non autorisés.

Défaut technique et exemple de code :

<!-- Formulaire de recherche où l'utilisateur saisit une requête --> 

<form action="/rechercher" method="GET"> 
  <input type="text" name="q" id="searchQuery">
  <input type="submit" value="Rechercher"> 
</form>

<!-- Affichage des résultats de recherche sans échapper les données -->

<div>Résultats de recherche pour: <?php echo $_GET['q']; ?></div>

Explication du défaut technique : Dans cet exemple, si un utilisateur saisit une requête malveillante telle que <script> code malveillant ici </script> dans le champ de recherche, le code sera exécuté lors de l’affichage des résultats, ce qui peut compromettre la sécurité du site.

Solution via du code commenté :

Pour prévenir la faille XSS, il est essentiel d’échapper correctement les données avant de les afficher sur la page. Voici comment le faire en utilisant une fonction d’échappement dans PHP, par exemple htmlspecialchars() :

<!-- Formulaire de recherche avec échappement des données -->

<form action="/rechercher" method="GET">
  <input type="text" name="q" id="searchQuery"> 
  <input type="submit" value="Rechercher">
</form>

 <!-- Affichage des résultats de recherche avec échappement des données -->

 <div>Résultats de recherche pour: <?php echo htmlspecialchars($_GET['q']); ?></div>

Avec cette solution, toute balise ou script potentiellement dangereux saisi par l’utilisateur sera converti en entités HTML, rendant le code inoffensif lors de son affichage.

2. Vulnérabilité CORS (Cross-Origin Resource Sharing)

CORS est un mécanisme de sécurité qui limite les requêtes HTTP entre différents domaines. Il vise à empêcher les attaques de type Cross-Site Request Forgery (CSRF) en restreignant l’accès aux ressources d’un domaine depuis un autre domaine non autorisé.

Défaut technique et exemple de code :

// Exemple d'en-tête de réponse CORS côté serveur (en PHP)

 header("Access-Control-Allow-Origin: https://site-autorise.com");
 header("Access-Control-Allow-Methods: GET, POST, OPTIONS");

Explication du défaut technique : Dans cet exemple, le serveur autorise uniquement les requêtes provenant du domaine https://site-autorise.com à accéder à ses ressources. Cependant, s’il n’y a pas de vérification adéquate sur les en-têtes CORS, cela peut conduire à des problèmes de sécurité, tels que des fuites de données sensibles vers des domaines non autorisés.

Solution via du code commenté :

Il est crucial de configurer correctement les en-têtes CORS pour autoriser uniquement les domaines approuvés à accéder aux ressources du serveur. Voici comment le faire en utilisant des en-têtes HTTP appropriés :

// Exemple d'en-tête de réponse CORS côté serveur (en PHP) 

header("Access-Control-Allow-Origin: https://site-autorise.com");
header("Access-Control-Allow-Methods: GET, POST, OPTIONS");

Avec cette solution, le serveur répond uniquement aux requêtes provenant du domaine https://site-autorise.com et rejette les requêtes provenant d’autres domaines non autorisés, renforçant ainsi la sécurité du site.

3. CSP (Content Security Policy)

CSP est une politique de sécurité définie par l’administrateur du site web qui permet de limiter l’exécution de contenu actif (JavaScript, CSS, etc.) en spécifiant les sources approuvées. Cela aide à atténuer les risques de failles XSS en restreignant l’origine des scripts autorisés.

Défaut technique et exemple de code :

<!-- Exemple d'en-tête de CSP côté serveur (en-tête HTTP) --> 
Content-Security-Policy: default-src 'self' https://apisiteapprouve.com;

Explication du défaut technique : Dans cet exemple, la politique de sécurité autorise uniquement les scripts hébergés localement (même origine) et ceux provenant du domaine https://apisiteapprouve.com à s’exécuter sur la page. Si cette politique est mal configurée, elle peut permettre à des scripts malveillants de s’exécuter sur la page, ou limiter l’accès à des ressources légitimes.

Solution via du code commenté :

Il est important de définir une politique CSP appropriée pour limiter les sources d’exécution de scripts. Voici comment faire cela en utilisant l’en-tête de réponse CSP :

<!-- Exemple d'en-tête de CSP côté serveur (en-tête HTTP) --> 
Content-Security-Policy: default-src 'self' https://apisiteapprouve.com;

Avec cette solution, seuls les scripts hébergés localement (même origine) et ceux provenant du domaine https://apisiteapprouve.com seront autorisés à s’exécuter sur la page, renforçant ainsi la sécurité en limitant l’exécution de scripts malveillants.

4. Injection SQL 

L’injection SQL est une attaque courante où les attaquants insèrent du code SQL malveillant dans des champs de saisie pour compromettre la base de données sous-jacente. Cela se produit généralement lorsque les requêtes SQL ne sont pas correctement paramétrées ou validées.

Défaut technique et exemple de code :

// Requête SQL vulnérable côté serveur (en PHP)

$nom_utilisateur = $_POST['nom_utilisateur'];
$mot_de_passe = $_POST['mot_de_passe'];

// La requête est construite en utilisant directement les données fournies par l'utilisateur

$sql = "SELECT * FROM utilisateurs WHERE nom_utilisateur='$nom_utilisateur' AND mot_de_passe='$mot_de_passe'";

Explication du défaut technique : Dans cet exemple, si un attaquant saisit ‘ OR ‘1’=’1 comme nom d’utilisateur et mot de passe, la requête SQL deviendrait :

SELECT * FROM utilisateurs WHERE nom_utilisateur='' OR '1'='1' AND mot_de_passe='' OR '1'='1';

Cela pourrait permettre à l’attaquant de contourner l’authentification et d’accéder illégalement aux données.

Solution via du code commenté :

Pour se protéger contre les attaques d’injection SQL, il est essentiel d’utiliser des requêtes préparées avec des paramètres. Voici comment faire cela en utilisant des requêtes préparées en PHP :

// Requête SQL sécurisée avec des paramètres (en PHP avec PDO)

$nom_utilisateur = $_POST['nom_utilisateur'];
$mot_de_passe = $_POST['mot_de_passe']; 

// Connexion à la base de données (exemple avec PDO)

$dbh = new PDO("mysql:host=localhost;dbname=ma_base_de_donnees", "utilisateur", "mot_de_passe");

// Requête SQL préparée

$sql = "SELECT * FROM utilisateurs WHERE nom_utilisateur = :nom AND mot_de_passe = :pass";

$stmt = $dbh->prepare($sql);
$stmt->bindParam(':nom', $nom_utilisateur);
$stmt->bindParam(':pass', $mot_de_passe);
$stmt->execute();

Avec cette solution, les paramètres sont correctement liés à la requête SQL, ce qui empêche l’injection SQL, car les données de l’utilisateur sont traitées en tant que données et non comme du code SQL potentiel.

5. BROKEN AUTHENTICATION

La vulnérabilité de l’authentification cassée se produit lorsque les mécanismes d’authentification ne sont pas correctement mis en œuvre, ce qui permet aux attaquants de compromettre les comptes utilisateur et d’accéder illégalement à des fonctionnalités et à des données sensibles.

Défaut technique et exemple de code :

// Exemple de vérification d'authentification vulnérable (en PHP)

$nom_utilisateur = $_POST['nom_utilisateur'];
$mot_de_passe = $_POST['mot_de_passe']; 
if ($nom_utilisateur === "admin" && $mot_de_passe === "admin123") {

// Authentification réussie, accès au compte administrateur 
// ...
} else { 
// Authentification échouée, affichage d'un message d'erreur
// ...
}

Explication du défaut technique : Dans cet exemple, l’authentification est effectuée en comparant directement le nom d’utilisateur et le mot de passe fournis par l’utilisateur avec des valeurs prédéfinies. Cela rend l’authentification vulnérable aux attaques par force brute et aux attaques d’injection.

Solution via du code commenté :

Pour renforcer l’authentification, il est recommandé d’utiliser des méthodes d’authentification robustes, telles que les hachages de mot de passe avec des techniques de salage, la mise en œuvre de politiques de verrouillage de compte après plusieurs tentatives infructueuses, etc.

Voici comment renforcer l’authentification en utilisant les hachages de mot de passe et le salage en PHP :

// Exemple de vérification d'authentification sécurisée (en PHP avec hachage de mot de passe et salage) 

$nom_utilisateur = $_POST['nom_utilisateur'];
$mot_de_passe = $_POST['mot_de_passe'];

// Récupération du mot de passe haché depuis la base de données
// Exemple de mot de passe haché (le salage doit être stocké avec le mot de passe) : 
// $mot_de_passe_hache = password_hash($mot_de_passe . $sel, PASSWORD_BCRYPT);

 $mot_de_passe_hache = ...; 

// Récupérer le mot de passe haché depuis la base de données 
// Vérification du mot de passe 
if (password_verify($mot_de_passe . $sel, $mot_de_passe_hache)) {
  // Authentification réussie, accès au compte administrateur
  // ...
} else { 
  // Authentification échouée, affichage d'un message d'erreur 
  // ...
}

Avec cette solution, le mot de passe est haché avec un sel aléatoire avant d’être stocké dans la base de données, ce qui rend plus difficile pour les attaquants de deviner le mot de passe réel.

6. L’EXPOSITION DE DONNÉES SENSIBLES

L’exposition de données sensibles se produit lorsque des informations confidentielles, telles que des mots de passe, des numéros de sécurité sociale ou des informations financières, sont stockées ou transmises sans être correctement protégées, ce qui les rend accessibles aux attaquants.

Défaut technique et exemple de code :

// Exemple de gestion de mot de passe vulnérable (en PHP)

$mot_de_passe = $_POST['mot_de_passe'];

// Affichage du mot de passe en clair (à des fins de démonstration uniquement) 
echo "Votre mot de passe est : $mot_de_passe";

Explication du défaut technique : Dans cet exemple, le mot de passe est affiché en clair sur la page, ce qui peut le rendre accessible à des tiers non autorisés ou être stocké dans des journaux non sécurisés.

Solution via du code commenté :

Il est essentiel de protéger les données sensibles en les stockant de manière sécurisée et en évitant de les afficher directement sur les pages web. Voici comment gérer les mots de passe de manière sécurisée :

// Exemple de gestion de mot de passe sécurisée (en PHP avec hachage et salage)

$mot_de_passe = $_POST['mot_de_passe'];

// Hachage du mot de passe avec un sel aléatoire avant de le stocker dans la base de données
// Exemple de hachage (le sel doit être stocké avec le mot de passe) :
// $mot_de_passe_hache = password_hash($mot_de_passe . $sel, PASSWORD_BCRYPT);

$mot_de_passe_hache = password_hash($mot_de_passe . $sel, PASSWORD_BCRYPT);
 
// Stocker le mot de passe haché dans la base de données
// ... 

// Ne pas afficher le mot de passe en clair, mais plutôt un message de confirmation 
echo "Votre mot de passe a été enregistré avec succès.";

Avec cette solution, le mot de passe est haché avec un sel aléatoire avant d’être stocké dans la base de données, ce qui rend les données sensibles plus sécurisées.

7. XML EXTERNAL ENTITIES (XXE)

Les attaques par entités externes XML (XXE) exploitent les fonctionnalités d’analyse XML pour charger des entités externes potentiellement malveillantes et accéder à des ressources sensibles du serveur.

Défaut technique et exemple de code :

<!-- Exemple de document XML vulnérable --> 
<!DOCTYPE utilisateur [ 
<!ENTITY fichier SYSTEM "file:///etc/passwd"> 
]>
<utilisateur>
  <nom>&fichier;</nom>
</utilisateur>

Explication du défaut technique : Dans cet exemple, l’entité externe fichier est chargée depuis le système de fichiers du serveur (/etc/passwd), ce qui peut exposer des informations sensibles aux attaquants.

Solution via du code commenté :

Pour se protéger contre les attaques XXE, il est recommandé de désactiver les fonctionnalités d’analyse de DTD (Document Type Definition) ou de définir une DTD personnalisée qui n’inclut pas d’entités externes potentiellement malveillantes.

<!-- Exemple de document XML sécurisé -->
<!DOCTYPE utilisateur [ 
<!-- DTD vide pour désactiver les entités externes --> 
]> 
<utilisateur> 
  <nom>Nom de l'utilisateur</nom> 
</utilisateur>

Avec cette solution, les entités externes sont désactivées, ce qui empêche les attaques XXE et protège les ressources sensibles du serveur.

8. BROKEN ACCESS CONTROL

La vulnérabilité de contrôle d’accès cassé se produit lorsque les restrictions d’accès aux ressources ou aux fonctionnalités ne sont pas correctement appliquées, permettant ainsi aux utilisateurs non autorisés d’accéder à des données sensibles ou à des fonctionnalités restreintes.

Défaut technique et exemple de code :

// Exemple de contrôle d'accès vulnérable (en PHP) 

if (isset($_GET['id'])) { 
  $id_utilisateur = $_GET['id']; 
  $donnees_utilisateur = recuperer_donnees_utilisateur($id_utilisateur);

  if ($donnees_utilisateur) { 
  // Afficher les informations de l'utilisateur 
  // ...
  } else {
  // Afficher un message d'erreur si l'utilisateur n'existe pas
  // ... } 
}

Explication du défaut technique : Dans cet exemple, l’accès à certaines informations utilisateur est basé sur l’ID fourni dans l’URL. Cependant, il n’y a aucune vérification supplémentaire pour s’assurer que l’utilisateur a le droit d’accéder à ces informations, ce qui peut permettre à des utilisateurs non autorisés de consulter des données sensibles d’autres utilisateurs.

Solution via du code commenté :

Pour renforcer le contrôle d’accès, il est essentiel de mettre en place des vérifications supplémentaires pour s’assurer que l’utilisateur a l’autorisation d’accéder aux ressources ou aux fonctionnalités.

// Exemple de contrôle d'accès sécurisé (en PHP) 

if (isset($_GET['id'])) {
  $id_utilisateur = $_GET['id'];
  // Vérifier si l'utilisateur actuel a l'autorisation d'accéder à l'utilisateur spécifié 

    if (utilisateur_a_le_droit($id_utilisateur)) {
      $donnees_utilisateur = recuperer_donnees_utilisateur($id_utilisateur);

      if ($donnees_utilisateur) {
      // Afficher les informations de l'utilisateur 
      // ...
      } else { 
      // Afficher un message d'erreur si l'utilisateur n'existe pas 
      // ... }

    } else { 
    // Afficher un message d'erreur si l'utilisateur n'est pas autorisé à accéder à cette ressource 
    // ...
  } 
}

Avec cette solution, des vérifications supplémentaires sont effectuées pour s’assurer que l’utilisateur a l’autorisation d’accéder aux informations de l’utilisateur spécifié, renforçant ainsi le contrôle d’accès et protégeant les données sensibles.

9. DÉSÉRIALISATION NON SÉCURISÉE

La désérialisation non sécurisée se produit lorsqu’une application désérialise des données provenant de sources non fiables sans validation appropriée, ce qui peut permettre aux attaquants d’exécuter du code malveillant ou de manipuler les objets désérialisés de manière inattendue.

Défaut technique et exemple de code :

// Exemple de désérialisation non sécurisée (en PHP avec la fonction unserialize())

$data = $_COOKIE['data']; $objet = unserialize($data);

Explication du défaut technique : Dans cet exemple, les données désérialisées sont directement obtenues à partir d’un cookie ($_COOKIE[‘data’]), sans aucune validation ou filtrage préalable. Cela peut permettre à des attaquants de manipuler les données désérialisées pour exécuter du code malveillant.

Solution via du code commenté :

Pour se protéger contre les attaques de désérialisation non sécurisée, il est important de mettre en œuvre des mécanismes de validation et de filtrage appropriés sur les données désérialisées avant de les traiter.

// Exemple de désérialisation sécurisée (en PHP avec filtre et vérification de classe)

 $data = $_COOKIE['data'];
// Vérifier si les données désérialisées sont une instance de la classe attendue 

if (is_string($data)) {
  $objet = @unserialize($data);

  if ($objet instanceof ClasseAttendue) {
  // Traitement des données désérialisées en toute sécurité
  // ... 
  } else { 
  // Les données désérialisées ne sont pas de la classe attendue, traitement des erreurs 
  // ... }
}

Avec cette solution, les données désérialisées sont vérifiées pour s’assurer qu’elles sont conformes à la classe attendue avant d’être traitées, ce qui réduit considérablement le risque d’exécution de code malveillant.

Conclusion 

La sécurité des applications web est un sujet crucial. Comprendre les vulnérabilités courantes telles que les failles XSS, CORS, CSP, les injections SQL, BROKEN AUTHENTICATION, l’exposition de données sensibles, XML External Entities, BROKEN ACCESS CONTROL et la désérialisation non sécurisée est essentiel pour les développeurs et les administrateurs système afin de protéger efficacement leurs applications.

En appliquant des pratiques de sécurité telles que la validation des données, la mise en œuvre de politiques CSP et CORS, l’utilisation de requêtes SQL préparées, la mise en place d’une authentification sécurisée, la protection des données sensibles, la désactivation des entités externes XML et la validation des données désérialisées, les risques d’attaques malveillantes peuvent être considérablement réduits.

En tant que développeurs, il est primordial de toujours accorder une attention particulière à la sécurité lors de la conception et de la mise en œuvre d’applications web pour protéger les utilisateurs et les données contre les menaces potentielles.