Plan de la séquence

Session (en informatique)

• « session n. f. (télécommunications, informatique) : Période de temps continue qui s’écoule entre la connexion et la déconnexion à un réseau ou à un système, ou encore l’ouverture et la fermeture d’un logiciel d’application. »

  Source : Grand dictionnaire terminologique - Office Québécois de la langue française

• « In computer science and networking in particular, a session is a time-delimited two-way link, a practical (relatively high) layer in the TCP/IP protocol enabling interactive expression and information exchange between two or more communication devices or ends […] »

  Source : https://en.wikipedia.org/wiki/Session_(computer_science)

Paradoxe : applications sur protocole sans état

• L’expérience utilisateur Web suppose une instance unique d’exécution d’application, comme dans un programme « sur le bureau »

• Faciliter la contextualisation du HATEOS :

  est-ce que passer d’un état à un autre est une transition valide ?

• Pourtant, le protocole HTTP est stateless (sans état) : chaque requête recrée un nouveau contexte d’exécution

Rappel l’application n’arrête pas de s’arrêter

À chaque requête :

1. démarrage application
2. routage vers méthode Contrôleur
   1. chargement données depuis base
   2. traitements
   3. sauvegarde en base données à persister
3. envoi Réponse
4. mort

Application peut garder la mémoire

• Le programme Web peut stocker un état (par ex. en base de données) avant de s’arrêter

  tracer dans cet état qu’on a fini de répondre à un client donné

• Il peut le retrouver au démarrage (début de la requête suivante)

  filtrer les traces précédentes pour retrouver les données du même client

Simule une session d’exécution unique comprenant une séquence d’actions du même client

Le client doit pour cela se faire reconnaître du serveur

Exécution contextualisée pour un client

À chaque requête :

1. Identification du client (contexte de la requête)
2. démarrage application
3. routage vers méthode Contrôleur
   1. chargement (depuis base) état précédent de ce client
   2. traitements
   3. sauvegarde (en base) nouvel état
4. envoi Réponse
5. mort

Rendre cela efficace !

Comment identifier le client HTTP

• Argument d’invocation dans URL : môche, car URL pas uniformes pour tous
• En-tête particulier de la requête ?
  • OUI : Cookie
• …

Respecter l’interopérabilité : standardisé par RFC 6265

Session de navigation typique

Cookies

Analogie avec badge d’accès dans le monde réel

• Juste un « jeton » unique qui identifie un client HTTP
• Sur un certain périmètre (serveur, chemin d’URL, application, …)
• Format choisi par le serveur
• Taille limitée :
  • peut contenir des données de l’application
  • pas un état de l’application complet
• Données en clair dans le stockage de cookies du navigateur
• Durée de vie potentiellement grande

Identification du client par cookie

Reconnaître le client HTTP

• Données du cookie stockées sur client, envoyées avec la requête au serveur (en-têtes)
• Serveur extrait données du cookie :
  • identifiant unique
  • …
• À partir de cet identifiant, le serveur peut trouver des données plus complètes stockées de son côté (base de données, stockage session, …)

Reconstituer côté serveur la continuité d’une session de navigation

À chaque nouvelle requête d’un client HTTP, la présentation du même cookie permet de relier :

• éléments de contexte dans la requête (en-têtes HTTP, arguments chemin,…)
• mémoire de l’état précédent sauvegardé côté serveur (notamment dans la session), à la fin de la réponse à la précédente requête HTTP du même client

Stocker de session côté serveur

Stockage de session côté serveur :

• Espace de stockage central côté serveur : référence du contexte d’exécution
• Accès en continu : rapide, solide, etc.
• Accès rapide : stocké dans la mémoire du serveur
• Durée de vie et unicité des sessions au choix du serveur

Accès rapide, y compris avec serveurs redondants !

Accessible pour la plate-forme applicative :

• Données plus ou moins volumineuses
• Disponibles rapidement pour les programmes (plus que SQL vers SGBD)
• Objets du modèle de l’application stockés dans la session (pas contrainte taille), sérialisés

Détails cookie

• Créé lors de la première requête d’un client (n’ayant pas fourni ce cookie)
• Le serveur délivre les cookies en les intégrant dans en-têtes de réponse HTTP

  • utilise l’en-tête particulier « Set-Cookie » (sur une ligne)

    Set-Cookie: <nom>=<valeur>;expires=<Date>;domain=<NomDeDomaine>; path=<Path>
    

• Le client stocke le cookie reçu dans la réponse, pour pouvoir le renvoyer aux prochaines requêtes vers ce serveur

• Exemple de réponse HTTP :

  HTTP/1.1 200 OK
  Server: Netscape-Entreprise/2.01
  Content-Type: text/html
  Content-Length: 100
  Set-Cookie: clientID=6969;domain=unsite.com; path=/jeux
  
  <HTML>...
  

• Par la suite, ce cookie sera renvoyé par le client au serveur, dans chaque requête ayant comme URL de début :

  http://www.unsite.com/jeux/...

• Sauf navigation privée dans navigateurs Web

Wrap-up sessions

• Requêtes HTTP déclenchées lors demandes de transition d’un état à l’autre de l’application
• L’exécution (PHP) résultante s’effectue sur serveur HTTP sans mémoire des interactions précédentes entre client et serveur (stateless)
• L’utilisateur a une impression de continuité : une seule session d’utilisation de l’application, où requêtes successives ont des relations de causalité
• Différentes solutions techniques, dont les cookies

Cookies !

Pourquoi tout ce tapage sur Cookies, RGPD, vie privée, etc.

• traçage requête accès ressources (images, scripts JS, fonts, etc.)
• régies publicitaires
• profilage (pas que les cookies)

Plus de détails : « Les Cookies, qui sont-ils ? Que veulent-ils ? » (LQDN)

Mais la publicité… quels modèles économique du Web ?

Aller plus loin : cf. « économie de l’attention », « capitalisme de surveillance » (Stéphane Croizat - UTC)

Mon conseil : bloqueurs de pubs (uBlock Origin, Privacy Badger, …)

Plan de la séquence

Protéger les données / fonctions

• Confidentialité : application accessible sur Internet, même si processus / données privés
• Privilèges : qui fait quoi
  • Spécifications fonctionnelles (profils utilisateurs)
  • Contrôle par l’application (HATEOS)
• Contrôle d’accès : reconnaître les utilisateurs, et mettre en place les restrictions (sans nuire à l’utilisabilité, mobilité, etc.)

Autres aspects sécurité vus dans une séance ultérieure

Contrôle des accès

• Protéger l’accès aux fonctionnalités de l’application
• Qui est autorisé à faire quoi

Dans un monde ouvert (Internet, Web, standards)

Sécurité par obscurcissement ?

• Ne pas protéger spécifiquement,
• et ne pas documenter / expliquer / rendre visible ?

Ce n’est pas parce que le code de l’application est caché sur le serveur que les méchants ne trouveront pas des failles !

#Fail

Contrôle effectif

• Au niveau de la configuration du serveur (ne pas permettre aux clients de découvrir les failles en regardant le source)
• Dans les fonctionnalités du logiciel : configuration dans le code du projet Symfony (module « firewall »)
• Mesures complémentaires (audit, etc.)

Modèle contrôle des accès

Identification

l’utilisateur fournit à un service un moyen de le reconnaître : identité

Authentification

le service vérifie cette identité

Autorisation

le service donne à l’utilisateur certaines permissions

1) Identification

• Identifiants :
  • email
  • identifiant d’utilisateur (login)
  • certificat client X509 (TLS)
  • Jeton dans un en-tête HTTP
  • …
• L’identification doit être confirmée par l’authentification

2) Authentification

• Vérifie client agit bien pour le propriétaire légitime de l’identifiant présenté
• Protocole de vérification :
  • mot-de-passe
  • signature valide d’une donnée quelconque (challenge) avec la clé privée associée au certificat client
  • délégation à service externe (Shibboleth/CAS, OAuth 2, …)
  • 2FA (two-factor authentication)
  • nouveaux standards : U2F, Fido, TOTP, …
  • …

3) Autorisations

• Permissions applicatives associées à l’identifiant
• Pour une certaine période
• Génération d’un jeton temporaire (session authentifiée)
  • Cookie

Dans protocole HTTP

• Identification / authentification de « bas niveau » dans le protocole HTTP (cf. RFC2617 RFC 7617: The ’Basic’ HTTP Authentication Scheme)
• Rappel : HTTP est sans état
  • Le client HTTP doit se réauthentifier à chaque requête
• Permet de transporter l’authentification dans les en-têtes
• Alternative : authentification applicative + session applicative

Plan de la séquence

Mécanismes

• Authentification HTTP
  • Authentification « Basic »
  • autres
• Authentification applicative

Basic Auth

Inconvénient : pas de logout

Gestion de l’identification et de l’authentification par l’application

• L’authentification est une des fonctionnalités de l’application, via la session
• Formulaire d’authentification
  • Login
  • Mot-de-passe
• « base de données » de comptes

Formulaire d’authentification

• Formulaire « standard »
• Champs :
  • Login ou email
  • Mot-de-passe (saisie cachée)

• Requête POST
• Initialise / Récupère session applicative contenant identification ou directement les autorisations

Vérification de l’authentification

• Comparer avec profil d’utilisateur connu (en base de données)
• Générer une session pour reconnaître l’utilisateur par la suite
• Attention : attaques « force brute »
  • Invalider un compte/profil, ou faire une gestion de surcharge qui désactive les tentatives (throttling, blacklist réseau, etc.)

Dans Symfony

• Composant Security
• Flexible : gestion souple et extensible de l’authentification

• Gère par exemple les utilisateurs dans la base de données via classe User + Doctrine
• Assistants générateurs de code pour les dialogues

Procédures ?

• Gestion des mots-de-passe (qualité aléa, longueur, stockage approprié, etc.)
• Récupération de compte si oubli mot-de-passe
  • Canal sécurisé ou envoi jeton de réinitialisation sur email (implique gestion emails)
• Confirmations d’authentification pour sections critiques de l’application
• Garder des traces (audit, obligations légales)
• Conformité RGPD (données personnelles dans les profils)

Se protéger

En tant qu’hébergeur d’une application Web

• HTTPS everywhere
  • Cookie dans en-têtes, chiffrés => identifiant de session secret
• Déjouer les attaques par force brute

Captcha

Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA)

Vérifier qu’un humain est aux commandes

• Pas infaillible
• Problèmes accessibilité

« Merdification » du Web

Combien de fois par jour voyez-vous ça ?

Se protéger du scraping des bots des IA

Les bots des opérateurs d’IA génératives moissonnent (scraping) violemment, et les sites s’écroulent

Protection

• Même style que pour attaques DDoS avant IA
• Pièges à bots : proof of work (Anubis)
• Pas évident (et pas gratuit)

Protection efficace, mais risque monopôle, et surveillance à grande échelle !

Généralisation tracking des utilisateurs légitimes ?

Impact environnemental !!!

Travail dissimulé pour l’IA

En passant :

• Travail grauit dissimulé (petites mains du clic des IA)
• Entraîner des systèmes d’armes autonomes ?

Source : Dazed & Confused: A Large-Scale Real-World User Study of reCAPTCHAv2 Andrew Searles, Renascence Tarafder Prapty, Gene Tsudik

Authentification à double facteur

2FA (Two factor authentication)

• + robuste :
  1. élémént connu
  2. élément possédé
• Exemples :
  • carte bancaire (possession) + code PIN (connu)
  • login + mdp (connu) + SMS reçu (possession mobile)
  • login + mdp (connu) + badge de sécurité générant un code unique (possession)
  • login + mdp (connu) + code TOTP récupéré dans appli sur ordiphone

Plan de la séquence

Role-Based Access Control (RBAC)

Contrôle d’accès à base de rôles

• Utilisateur
• Rôle
• Permissions

Permissions

• Modèle applicatif de permissions
• Vérifier les permissions à chaque traitement de requête
  • Routage
  • Dans les traitements fonctionnels

Module « Firewall » de Symfony

Réponses Web

• Code 200 + Page mentionnant problème de permissions
• Code 403 (et peut-être un message dans la page) ?

Plan de la séquence

Flexibilité

• Symfony permet de gérer plein de modalités d’authentification
• Choix : s’appuyer sur la base de données, et des contrôleurs d’authentification générés par les assistants

Gestion des utilisateurs avec Doctrine

• Classe User du Modèle (et mapping Doctrine en base)
• Définition de règles dans le firewall Symfony
• Rôles
• Ajouter des formulaires (+ templates) :
  • Login + password
  • Logout
  • (Inscription, rappel du mot-de-passe, …)

Classe User

symfony console make:user

namespace App\Entity;

use App\Repository\UserRepository;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface;
use Symfony\Component\Security\Core\User\UserInterface;

#[ORM\Entity(repositoryClass: UserRepository::class)]
class User implements UserInterface, PasswordAuthenticatedUserInterface
{
    // ...

    #[ORM\Column(length: 180, unique: true)]
    private ?string $email = null;

(appelée Member dans le projet)

Hiérarchie de rôles

• Arbitraire, selon les besoins de l’application
• Exemple :
  1. ROLE_SUPER_ADMIN
  2. ROLE_ADMIN
  3. ROLE_CLIENT
  4. ROLE_USER

# security.yml

role_hierarchy:
    ROLE_CLIENT:      ROLE_USER
    ROLE_ADMIN:       ROLE_USER
    ROLE_SUPER_ADMIN: [ROLE_USER, ROLE_ADMIN]

Firewall

Contrôle l’accès aux URLs en fonction des rôles :

# app/config/security.yml
security:
    # ...

    firewalls:
        # ...
        default:
            # ...

    access_control:
        # require ROLE_ADMIN for /admin*
        - { path: ^/admin, roles: ROLE_ADMIN }

Utilisation dans les contrôleurs

• Contrôle d’accès sur les routes :

  #[Route('/comment/{postId}/new', name: 'comment_new', methods: ['GET', 'POST'])]
  #[IsGranted('IS_AUTHENTICATED_FULLY')]
  function addComment(Post $post): Response {
      //...
  

  IS_AUTHENTICATED_FULLY : un utilisateur qui vient vraiment de se reconnecter

• Contrôle d’autorisation dans le code des méthodes :

  public function adminDashboard(): Response {
      $this->denyAccessUnlessGranted('ROLE_ADMIN', null, 'Access denied!');
  

  « Entrée interdite, à moins que… »

Profil de l’utilisateur

• Accès aux propriétés de l’utilisateur :

  $this->getUser()
  
  // ...
  
  $email = $this->getUser()->getEmail();
  $post->setAuthorEmail($email);
  

Personnalisation apparence

Gabarits Twig

{% if is_granted('ROLE_ADMIN') %}
  <a href="...">Delete</a>
{% endif %}

Gestion fine

• Dans code d’une méthode de contrôleur :

  $this->denyAccessUnlessGranted('ROLE_ADMIN', null, 'Access denied!');
  

• équivalent à :

  if (! $this->get('security.authorization_checker')->isGranted('ROLE_ADMIN')) {
      throw $this->createAccessDeniedException('Access denied!');
  }
  

Déclenche une exception :

• erreur 403
• ou redirection vers login

Exceptions et codes retour

try {
    // faire quelque chose qui appelle : throw
} catch (Exception $e) {
    echo 'Exception reçue : ',  $e->getMessage(), "\n";
}

Permet d’intercepter de façon standard les exceptions :

• AccessDeniedException (403)
• NotFoundHttpException (404)

Take away

• Sessions
  • Cookies
  • Session Symfony
• Contrôle d’accès
  • Principes
    • Identification
    • Authentification
    • Autorisations
  • Rôles (RBAC)
  • Contrôle dans Symfony

Récap

• [X] HTTP (GET)
• [X] PHP
• [X] Doctrine
• [X] Routeur Symfony
• [X] HTML
• [X] Twig
• [X] CSS
• [X] Formulaires
• [X] Sessions
• [X] Contrôle d’accès

Tout ce qu’il faut pour un site mis en ligne

Postface

Crédits illustrations et vidéos

Copyright

• Document propriété de ses auteurs et de Télécom SudParis (sauf exceptions explicitement mentionnées).
• Réservé à l’utilisation pour la formation initiale à Télécom SudParis.