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>
Attachment:
pgpvUQa9e20_a.pgp
Description: OpenPGP digital signature