Catatan terbitan Django 1.6.11

18 Maret 2015

Django 1.6.11 memperbaiki dua masalah keamanan di 1.6.10.

Kemungkinan denial-of-service dengan 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().

Mengurangi kemungkinan serangan XSS melalui mengalihkan URL penyediaan-pengguna

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.