Django 1.8.16 release notes

1 listopada 2016

Django 1.8.16 fixes two security issues in 1.8.15.

Użytkownik tworzony z zahard-code’owanym hasłem podczas uruchamiania testów na Oracle’u

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.

Słabość rebindingu DNS, gdy 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.