# Django 3.0.9.dev - dokumentacja

# Django 1.9.11 release notes

1 listopada 2016

Django 1.9.11 fixes two security issues in 1.9.10.

## 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.