Fix typos, spelling & grammar

reference/session/security.xml

@@ -44,13 +44,13 @@
     des tierces personnes. I.E. injections Javascripts, identifiants
     de session dans les URLs, reniflement de paquets, accès physique
     au périphérique, etc.
-    Un identifiant de session divulgué permet à un tierce d'accéder
+    Un identifiant de session divulgué permet à un tiers d'accéder
     à toutes les ressources associées avec cet identifiant. Tout d'abord,
     les URLs contenant les identifiants de session. S'il y a des liens
     vers des sites ou des ressources externes, l'URL incluant l'identifiant
     de session doit être stockée dans les logs refferer du site externe.
     Si ces données ne sont pas chiffrées, les identifiants de session
-    vont être transmises en texte clair sur le réseau. La solution ici est
+    vont être transmis en texte clair sur le réseau. La solution ici est
     d'implémenter SSL/TLS sur le serveur et le rendre madataire pour les
     utilisateurs. HSTS devrait être utilisé pour améliorer également la
     sécurité.
@@ -80,7 +80,7 @@
 
     <para>
      Lorsque <link linkend="ini.session.use-strict-mode">session.use_strict_mode</link>
-     est activée, et que le gestionnaire de sauvegarde des sessions le supporte,
+     est activé, et que le gestionnaire de sauvegarde des sessions le supporte,
      un identifiant de session non initialisé est rejeté, et un nouveau est créé.
      Ceci prévient une attaque qui force les utilisateurs à utiliser un
      identifiant de session connu.
@@ -124,7 +124,7 @@
       <link linkend="ini.session.use-strict-mode">session.use_strict_mode</link>
       limite les risques concernant le gestionnaire adaptatif de session, un
       attaquant peut forcer les utilisateurs à utiliser un identifiant de
-      session non initialisé qui a été créé par l'attaquant. i.e. via des injections
+      session non initialisé qui a été créé par l'attaquant, i.e. via des injections
       Javascript. Ce type d'attaque peut être limité en utilisant les
       recommandations de ce manuel.
      </simpara>
@@ -135,7 +135,7 @@
       utiliser les timestamps basés sur le gestionnaire de session,
       et regénérer les identifiants de session en utilisant la fonction
       <function>session_regenerate_id</function> avec les procédures
-      recommandées. Si les développers suivent tout ceci, un identifiant de session
+      recommandées. Si les développeurs suivent ces instructions, un identifiant de session
       généré par un attaquant sera normalement supprimé.
      </simpara>
 
@@ -145,7 +145,7 @@
       l'utilisateur ; ces informations seront utiles pour de futures
       investigations. L'utilisateur devrait être forcé à se déconnecter
       de toutes les sessions, i.e. le forçant ainsi à s'identifier de
-      nouveau. Ceci permet de contrer les attaques en utilisant des sessions
+      nouveau. Ceci permet de contrer les attaques utilisant des sessions
       volées.
      </simpara>
     </note>
@@ -175,7 +175,7 @@
       utiliser <acronym>CSPRNG</acronym>, i.e. <filename>/dev/urandom</filename>, ou la fonction
       <function>random_bytes</function> et les fonctions de hachage
       pour générer un nouvel identifiant de session. La fonction
-      <function>session_create_id</function> a des mécanismes de détection
+      <function>session_create_id</function> possède des mécanismes de détection
       de collision, et génère un identifiant de session suivant les
       configurations INI des sessions. L'utilisation de la fonction
       <function>session_create_id</function> est recommandée.
@@ -248,9 +248,9 @@
 
    <para>
     <function>session_regenerate_id</function> <emphasis>n'effacera pas</emphasis>
-    les sessions anciennes par défaut. Les sessions authentifiées obsolètes
+    les anciennes sessions par défaut. Les sessions authentifiées obsolètes
     peuvent être présente pour être utilisées. Les développeurs doivent s'assurer
-    que les sessions anciennes ne soient pas utilisées par tout le monde.
+    que les anciennes sessions ne soient pas utilisées par tout le monde.
     Ils doivent interdire l'accès aux données de session obsolète
     en utilisant eux-même des timestamps.
    </para>
@@ -271,8 +271,8 @@
      <varname>$_SESSION</varname>, et interdire l'accès aux données de session.
     </simpara>
     <simpara>
-     Les développeurs ne doivent pas interdire l'accès aux données des sessions
-     anciennes immédiatement après l'exécution de la fonction 
+     Les développeurs ne doivent pas interdire l'accès aux données des 
+     anciennes sessions immédiatement après l'exécution de la fonction 
      <function>session_regenerate_id</function>. L'accès doit être interdit
      à un stade ultérieure ; i.e. quelques secondes après pour les réseaux
      stables, comme un réseau filaire et quelques minutes après pour les réseaux
@@ -281,13 +281,13 @@
     <simpara>
      Si un utilisateur accède à une session obsolète (session ayant expirée), l'accès
      à cette session doit être refusé. Il est également recommandé de supprimer le
-     statut d'authentification de toutes les sessions utilisateurs sinon cela
+     statut d'authentification de toutes les sessions utilisateurs, car cela
      peut représenter un axe d'attaque.
     </simpara>
    </warning>
 
    <para>
-    L'utilisation prore de la directive <link linkend="ini.session.use-only-cookies">session.use_only_cookies</link> et de la fonction
+    L'utilisation de la directive <link linkend="ini.session.use-only-cookies">session.use_only_cookies</link> et de la fonction
     <function>session_regenerate_id</function> peuvent causer des DoS personnel
     avec des cookies non-supprimés définis par les attaquants. Dans ce cas,
     les développeurs peuvent inviter les utilisateurs à supprimer les cookies
@@ -305,7 +305,7 @@
      <link linkend="ini.session.use-strict-mode">session.use_strict_mode</link>.     
     </simpara>
     <simpara>
-     DoS peut uniquement survenir lorsque le compte subit une attque. Une injection
+     DoS peut uniquement survenir lorsque le compte subit une attaque. Une injection
      Javascript dans une application représente la plupart des axes d'attaque.
     </simpara>
    </warning>
@@ -322,40 +322,40 @@
     </para>
 
     <para>
-     Les données de sessions oàbsolètes doivent être supprimées aussi vite
+     Les données de sessions obsolètes doivent être supprimées aussi vite
      que possible. Cependant, les sessions actives ne doivent pas être
      supprimées instantanément. Pour satisfaire ces recommandations, les développeurs
-     doivent implémenter un gestionnaire des données de session basé sur
-     un timestamp eux-même.
+     eux-mêmes doivent implémenter un gestionnaire des données de session basé sur
+     un timestamp.
     </para>
 
     <para>
      Définissez et gérez l'expiration du timestamp dans la variable
      globale $_SESSION. Interdisez l'accès aux données de sessions
      périmées. Lorsqu'un accès à des données de session obsolète est détecté,
-     il convient de supprimer toutes les status authentifiés des sessions
+     il convient de supprimer toutes les statuts authentifiés des sessions
      utilisateurs et forcer les utilisateurs à s'authentifier de nouveau.
      L'accès à des données de sessions obsolètes peut représenter une attaque.
-     Pour arriver à cette fin, les developpeurs doivent suivre tous les sessions
+     Pour arriver à cette fin, les développeurs doivent suivre toutes les sessions
      actives de tous les utilisateurs.
     </para>
 
     <note>
      <simpara>
       L'accès à une session obsolète peut également survenir à cause d'un réseau instable
-      et/ou d'un accès concurent à une site web. i.e. le serveur tente de définir un
+      et/ou d'un accès concurrent à un site web, i.e. le serveur tente de définir un
       nouvel identifiant de session via un cookie, mais le paquet Set-Cookie n'a jamais
       atteint le client en raison d'une perte de connexion. Une connexion peut
       créer un nouvel identifiant de session via la fonction <function>session_regenerate_id</function>,
-      mais une atre connexion concurente peut ne pas avoir encore deçu
+      mais une autre connexion concurrente peut ne pas avoir encore reçu
       l'identifiant de session. Toutefois, les développeurs doivent interdire l'accès
-      à une session obsolète à un moment plus éloingé. i.e. la gestion des sessions
+      à une session obsolète à un moment plus éloigné. i.e. la gestion des sessions
       basés sur le timestamp est obligatoire.
      </simpara>
     </note>
 
     <para>
-     En résumé, les données de sessions ne doivent pas être détruite avec la fonction
+     En résumé, les données de sessions ne doivent pas être détruites avec la fonction
      <function>session_regenerate_id</function>, ni avec la fonction <function>session_destroy</function>,
      mais les timestamps doivent être utilisés pour contrôler l'accès aux données de
      session. Laissez la fonction <function>session_gc</function> supprimer les données obsolètes