Re: [RFR2] wml://security/2016/dla-14{0,1,2,3,5}.wml

[Baptiste Jammet]

Bonjour, 

Dixit JP Guillonneau, le 12/08/2017 :

>D’autres commentaires ?

URL au féminin ?

Baptiste

--- 00000ad5.dla-143.wml	2017-08-14 18:45:02.783037147 +0200
+++ ./00000ad5.dla-143-bj.wml	2017-08-14 18:46:18.414155239 +0200
@@ -47,13 +47,13 @@
 
 <p>Django dépend des saisies d’utilisateur dans certains cas (par exemple,
 django.contrib.auth.views.login() et i18n) pour rediriger l’utilisateur vers
-un URL lors d’un <q>succès</q>. Les vérifications de sécurité pour ces
+une URL lors d’un <q>succès</q>. Les vérifications de sécurité pour ces
 redirections (à savoir django.util.http.is_safe_url()) ne retirent pas les
-espaces de début dans les URL testés et de cette façon considèrent les URL
-tels que « \njavascript:... » sûrs. Si un développeur se fie à is_safe_url()
-pour fournir des cibles de redirections fiables et met un tel URL dans un
+espaces de début dans les URL testées et de cette façon considèrent les URL
+telles que « \njavascript:... » sûrs. Si un développeur se fie à is_safe_url()
+pour fournir des cibles de redirections fiables et met une telle URL dans un
 lien, elles pourraient subir une attaque XSS. Ce bogue n’affecte pas
-actuellement Django, puisque cet URL est seulement mis dans l’en-tête de
+actuellement Django, puisque cette URL est seulement mis dans l’en-tête de
 réponse Location et les navigateurs paraissent ignorer JavaScript ici.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2015-0221";>CVE-2015-0221</a>
@@ -72,7 +72,7 @@
 n’est pas renforcé lors d’une utilisation en production, et devrait être
 seulement utilisée comme aide au développement. C’est peut-être le moment
 d’analyser votre projet et servir vos fichiers en production en utilisant un
-vrai serveur web frontal si vous ne le faites déjà.</p></li>
+vrai serveur web frontal si vous ne le faites pas déjà.</p></li>
 
 </ul>
 

pgpvBGUR7iXXW.pgp
Description: OpenPGP digital signature