18 Maret 2015
Django 1.7.7 memperbaiki beberapa kesalahan dan masalah keamanan di 1.7.6.
strip_tags()
¶Last year strip_tags()
was changed to work
iteratively. The problem is that the size of the input it's processing can
increase on each iteration which results in an infinite loop in
strip_tags()
. This issue only affects versions of Python that haven't
received a bugfix in HTMLParser; namely Python < 2.7.7 and
3.3.5. Some operating system vendors have also backported the fix for the
Python bug into their packages of earlier versions.
Untuk memperbaiki masalah ini, strip_tags()
akan sekarang mengembalikan masukan asli jika itu mengetahui panjang dari string itu sedang oleh meningkat. Ingat bahwa mutlak TIDAK ada jaminan disediakan tentang hasil dari strip_tags()
menjadi aman HTML. jadi JANGAN PERNAH menandai aman hasil dari panggilan strip_tags()
tanpa meloloskan itu pertama, sebagai contoh dengan escape()
.
Django relies on user input in some cases (e.g.
django.contrib.auth.views.login()
and i18n)
to redirect the user to an "on success" URL. The security checks for these
redirects (namely django.utils.http.is_safe_url()
) accepted URLs with
leading control characters and so considered URLs like \x08javascript:...
safe. This issue doesn't affect Django currently, since we only put this URL
into the Location
response header and browsers seem to ignore JavaScript
there. Browsers we tested also treat URLs prefixed with control characters such
as %08//example.com
as relative paths so redirection to an unsafe target
isn't a problem either.
Bagaimanapun, jika seorang pengembang bergantung pada is_safe_url()
untuk menyediakan ssaran pengalihan aman dan menaruh URL itu kedalam sebuah tautan, mereka dapat menderita dari sebuah serangan XSS ketika beberapa peramban seperti Google Chrome mengabaikan kendali karakter pada awal dari URL di sebuah jangkar href
.
makemigrations --merge
dipanggil dengan verbosity=3
berkas perpindahan ditulis menjadi stdout
(#24427).Apr 06, 2021