1.     SOP La politique de même origine (Same Origin Policy). 1

2.     CORS (Cross-Origin Resource Sharing) 1

3.     CSP (Content Security Policy) 2

4.     Cookies HttpOnly. 2

5.     Un cookie sécurisé. 3

6.     Authentification ("authn") 3

7.     Autorisation ("authz") 3

8.     Authentification par jeton http (figure 16.6) 4

9.     Authentification via un tiers (figure 16.8) 5

10.       CSP : Content Security Policy (Politique de sécurité du contenu) 6

11.       CSRF : Cross-Site Request Forgery (Falsification de requête inter-sites) 7

12.       Exécution arbitraire de programme (Arbitrary Program Execution) 9

13.       Relais de courrier ouvert (Open Mail Relays) 10

 

 

Réference livre  : Fundamentals of web development de Randy Connolly. (2022).

1.     SOP
La politique de même origine (Same Origin Policy).

La politique de même origine est un mécanisme de sécurité fondamental dans les navigateurs web qui empêche les scripts exécutés sur une page web d'accéder aux données d'une autre page si elles ne partagent pas la même origine.

Une "origine" est définie par trois éléments :

1. le schéma (http ou https),
2. le nom de domaine (ex. www.example.com),
3. et le port (ex. 80, 443).

 

2.     CORS (Cross-Origin Resource Sharing)

CORS est un mécanisme de sécurité qui permet à un site web d'accéder à des ressources situées sur un domaine différent.
Par défaut, les navigateurs bloquent les requêtes inter-domaines pour des raisons de sécurité. CORS permet de contrôler et d'autoriser explicitement ces accès.

<?php // Permet à tous les domaines d'accéder aux ressources (Attention : sécurité) header("Access-Control-Allow-Origin: *"); // Ou pour un domaine spécifique (recommandé pour la sécurité) header("Access-Control-Allow-Origin: https://exemple.com"); // Autorise les méthodes HTTP (GET, POST, PUT, DELETE) header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE"); // Permet les en-têtes personnalisés header("Access-Control-Allow-Headers: Content-Type, Authorization");   // Si la requête est de type OPTIONS, on renvoie une réponse vide (pré-vol CORS) if ($_SERVER['REQUEST_METHOD'] == 'OPTIONS') {     exit(0);} // Autres traitements ici ?>

 

3.     CSP (Content Security Policy)

CSP est une politique de sécurité qui permet de définir quelles sources de contenu (scripts, images, styles, etc.) sont autorisées sur une page web.
Elle protège notamment contre les attaques XSS (Cross-Site Scripting).

 

4.     Cookies HttpOnly

Vous pouvez configurer les paramètres pour empêcher les cookies d’être accessibles via l’API document.cookie. Cela permet, par exemple, d’éviter que Google Analytics ne vole vos cookies.

5.     Un cookie sécurisé

Un cookie qui est uniquement transmis via une connexion HTTPS sécurisée. Pour marquer un cookie comme sécurisé, on utilise le flag Secure lors de sa création.

Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Strict

6.     Authentification ("authn")

Vérifie l’identité de l’utilisateur (vérifie que l’utilisateur est bien celui qu’il prétend être).
Elle repose sur trois types de facteurs :

• Quelque chose que vous connaissez (mot de passe) :

The solution to the rainbow table problem is salting Salting and hashing passwords let hash = crypto.createHash("sha256"); let salt = crypto.randomBytes(8); hash.update(salt); hash.update(password); let storedPassword = hash.digest("base64"); //Use different salt for different user Otherwise, same password across users => same hash   brute-force attack use of a CAPTCHA

 

• Quelque chose que vous possédez (carte, téléphone, clé cryptographique)
• Quelque chose que vous êtes (empreinte  ou autre donnée biométrique)
  → Cela conduit à une authentification multi-facteurs (MFA).

7.     Autorisation ("authz")

Détermine si l’utilisateur est autorisé à effectuer une action.
Par exemple, à l’aide de listes de contrôle d'accès (ACL) ou d’URL à capacités.

Il existe deux types d’authentification :

• Stateful : Les données de session sont stockées côté serveur.
• Stateless : Les données de session sont stockées dans un jeton délivré au client.

L’authentification stateless est utilisée pour surmonter les limites de l’authentification stateful.

8.     Authentification par jeton http (figure 16.6)

L’authentification par jeton HTTP (également appelée authentification Bearer) permet à quiconque possédant le jeton d’accéder à la ressource.

Ses principaux avantages sont :

1. Amélioration des performances du site (pas besoin de gérer des sessions).
2. En n’utilisant pas de cookies, cette approche élimine un ensemble de vulnérabilités liées aux cookies comme les attaques XSS et CSRF (qui seront abordées plus loin).
3. Fonctionne en dehors du navigateur, ce qui permet à des applications mobiles d’utiliser la même stratégie.

Il est important de noter que, tout comme pour l’authentification basique, l’authentification par jeton nécessite une communication via HTTPS.

Bien que différents types de jetons puissent être utilisés, le format le plus courant est le JWT (JSON Web Token).
Un JWT est composé de trois chaînes encodées en Base64, séparées par des points, contenant :

• un en-tête (métadonnées du jeton),
• une charge utile (payload) (les "claims" de sécurité sous forme de paires clé/valeur),
• une signature (utilisée pour valider le jeton).

Les jetons (tokens) sont des structures de données encodées utilisées pour la validation, ce qui élimine le besoin d’envoyer les identifiants à chaque requête.
Ils assurent l’intégrité des données grâce à des mécanismes cryptographiques, mais ne sont pas nécessairement chiffrés par défaut.

Le JWT (JSON Web Token) est un format standardisé de jeton composé de trois éléments :

• un en-tête (header),
• une charge utile (payload),
• une signature.

Leur nature autonome permet la vérification des informations (ou "claims") sans stockage côté serveur.

Le JWT est une solution efficace et présente les avantages suivants :

• Compact : de petite taille, ce qui permet de l’envoyer via une URL, un paramètre POST ou dans un en-tête HTTP, facilitant une transmission rapide.

Autonome : contient toutes les informations nécessaires sur l’utilisateur, évitant ainsi d’interroger la base de données à chaque requête.

 

(

 

9.     Authentification via un tiers (figure 16.8)

Des mécanismes d'authentification tiers comme OpenID et OAuth sont populaires auprès des développeurs et sont utilisés en arrière-plan par de nombreux grands sites web, notamment Amazon, Facebook, Microsoft et Twitter, pour ne citer que quelques exemples.

 

10.  CSP : Content Security Policy (Politique de sécurité du contenu)

La Content Security Policy (CSP) est une recommandation en constante évolution du W3C qui fournit une couche de sécurité supplémentaire (et de contrôle) aux navigateurs. Elle peut être configurée site par site via les en-têtes HTTP envoyés par le serveur.

La CSP permet d’indiquer au navigateur, à l’avance, quelles sources de contenu il peut considérer comme fiables.
De manière simple, elle permet à un administrateur web de définir quelles ressources (scripts, images, styles, etc.) sont autorisées ou interdites pour une page.

Exemple de configuration CSP :

En-tête HTTP dans un serveur Apache :

Header set Content-Security-Policy "default-src 'self';"

Ou via une balise HTML :

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://res.cloudinary.com; font-src fonts.gstatic.com; style-src 'self' fonts.googleapis.com">

Ici :

 

default-src 'self' autorise les ressources provenant uniquement du même domaine.

 

img-src https://res.cloudinary.com autorise les images provenant de ce domaine.

 

font-src fonts.gstatic.com autorise les polices de ce domaine.

 

style-src 'self' fonts.googleapis.com autorise les styles internes et ceux provenant de Google Fonts.

 

11.  CSRF : Cross-Site Request Forgery (Falsification de requête inter-sites)

 

Une attaque CSRF consiste à tromper un utilisateur pour qu’il soumette involontairement une requête web à un site sur lequel il est authentifié.

En d'autres termes, l'attaquant exploite la confiance qu’un site a envers l’utilisateur.
Par exemple, un utilisateur connecté à sa banque pourrait être amené, sans le savoir, à effectuer un virement d'argent ou à changer son mot de passe, simplement en cliquant sur un lien malveillant ou en visitant une page contenant du code injecté.

 

 

Prévention des attaques CSRF (Cross-Site Request Forgery)

Quatre techniques couramment utilisées :

1. Validation du Referer
   Vérifier que l’en-tête Referer d’une requête provient bien du domaine attendu.
2. Jeton de validation secret (CSRF Token)
   Ajouter un jeton unique, difficile à deviner, dans chaque formulaire modifiant l’état. Par exemple :

<input type="hidden" name="csrf-token" value="lR4Xbi...wX4WFoz" />

 

1. Ce jeton est généré à chaque fois que le serveur renvoie un formulaire, et est validé lors de la soumission.
2. En-tête HTTP personnalisé
   Certains frameworks exigent qu’une requête modifiant l’état contienne un en-tête HTTP personnalisé que seul du JavaScript côté client peut ajouter (ce que les navigateurs ne font pas automatiquement pour des requêtes inter-domaines).
3. Cookies SameSite
   L’option SameSite permet de limiter l’envoi des cookies dans les requêtes inter-domaines :
• Strict : n’envoie jamais les cookies dans un contexte inter-site (même pour un lien classique).
• Lax : les cookies sont envoyés dans certains cas de navigation, mais pas lors des requêtes type POST.

Exemple de configuration :

Set-Cookie: sessionid=abc123; Secure; HttpOnly; SameSite=Strict

12. Exécution arbitraire de programme (Arbitrary Program Execution)

Une autre attaque critique liée au contrôle utilisateur est l'exécution de commandes système via un script (souvent PHP).
Les fonctions comme exec(), system() ou passthru() en PHP permettent au serveur d’exécuter des commandes comme s’il s’agissait d’un utilisateur connecté au système Unix.

Exemple d’attaque :

Si un script PHP reçoit une entrée utilisateur non filtrée et l’utilise ainsi :

$user_input = $_GET['cmd']; system($user_input);

Alors une requête comme script.php?cmd=rm+-rf+/ peut entraîner des conséquences désastreuses.

Solution :

• Ne jamais exécuter directement des commandes shell avec des entrées utilisateur.
• Si nécessaire :
• Nettoyer les entrées avec des fonctions comme :

escapeshellarg($user_input);

escapeshellcmd($user_input);

 

  Limiter les commandes possibles avec une liste blanche (whitelist).

  Éviter autant que possible d'utiliser ces fonctions dans les scripts web accessibles au public.

Exemple

13.  Relais de courrier ouvert (Open Mail Relays)

Un relais de courrier ouvert est un serveur de messagerie mal configuré qui permet à n'importe qui d'envoyer des e-mails à n'importe quel destinataire, et ce sans aucune authentification.

Ce type de configuration est extrêmement dangereux, car il peut être exploité par des spammeurs ou des attaquants pour :

• Envoyer du spam en masse,
• Délivrer des e-mails de phishing,
• Détourner l’identité d’une organisation (spoofing),
• Faire mettre en liste noire votre serveur par les fournisseurs d’e-mail (Gmail, Outlook, etc.).

 

                        Solution :

Pour éviter que votre serveur soit un relais ouvert :

• Exiger une authentification pour toute tentative d’envoi d’e-mails.
• Restreindre les adresses IP autorisées à relayer des messages.
• Utiliser des protocoles de sécurité et d’authentification comme :

o   SMTP AUTH,

o   TLS/SSL,

o   SPF (Sender Policy Framework),

o   DKIM (DomainKeys Identified Mail),

o   DMARC.