1 listopada 2016
Django 1.9.11 fixes two security issues in 1.9.10.
Podczas uruchamiania testów z bazą danych Oracle, Django tworzy tymczasowego użytkownika bazy danych. W starszych wersjach, jeśli hasło nie zostało podane ręcznie w słowniku TEST ustawień bazy danych, używane jest hasło zahard-code’owane. To mogło pozwalać atakującemu z dostępem sieciowym do serwera bazy danych na połączenie.
Ten użytkownik jest zazwyczaj usuwany po tym, jak zestaw testów skończy się wykonywać, lecz nie gdy używa się opcji manage.py test --keepdb lub kiedy użytkownik ma aktywną sesję (taką jak połączenie atakującego).
Losowo generowane hasło jest teraz używane przy każdym uruchomieniu testu.
DEBUG=True¶Older versions of Django don’t validate the Host header against
settings.ALLOWED_HOSTS when settings.DEBUG=True. This makes them
vulnerable to a DNS rebinding attack.
Jako że Django nie dostarcza modułu, który zezwala na zdalne wykonywanie kodu, jest to co najmniej wektor cross-site scriptingu, który może być całkiem poważny, jeśli deweloperzy ładują kopię produkcyjnej bazy danych w dewelopmencie lub łączą się do jakiś produkcyjnych usług, które na przykład nie mają deweloperskich instancji. Jeśli projekt używa pakietu takiego jak django-debug-toolbar, wtedy atakujący mógł wykonać własny SQL, który mógł być szczególnie zły, jeśli deweloperzy łączą się do bazy danych kontem superusera.
settings.ALLOWED_HOSTS jest teraz walidowane bez względu na DEBUG. Dla wygody, jeśli ALLOWED_HOSTS jest puste i DEBUG=True, następujące wariacje localhosta są dopuszczone ['localhost', '127.0.0.1', '::1']. Jeśli twoje lokalne ustawienia mają twoją produkcyjną wartość ALLOWED_HOSTS, musisz teraz ją ominąć, aby uzyskać wypisane wartości fallback.
sie 03, 2022