# Django 5.2.8 documentation

# Django 1.9.11 versionsinformation

1 november 2016

Django 1.9.11 åtgärdar två säkerhetsproblem i 1.9.10.

## Användare med hårdkodat lösenord som skapas när tester körs på Oracle

När tester körs med en Oracle-databas skapar Django en tillfällig databasanvändare. I äldre versioner, om ett lösenord inte anges manuellt i databasinställningarna `TEST` dictionary, används ett hårdkodat lösenord. Detta kan göra det möjligt för en angripare med nätverksåtkomst till databasservern att ansluta.

Den här användaren släpps vanligtvis efter att testsviten har slutförts, men inte när alternativet `manage.py test --keepdb` används eller om användaren har en aktiv session (t.ex. en angripares anslutning).

Ett slumpmässigt genererat lösenord används nu för varje testkörning.

## DNS-sårbarhet för ombindning när `DEBUG=True`

Äldre versioner av Django validerar inte `Host`-headern mot `settings.ALLOWED_HOSTS` när `settings.DEBUG=True`. Detta gör dem sårbara för en DNS rebinding attack.

Även om Django inte levererar en modul som tillåter exekvering av fjärrkod, är detta åtminstone en cross-site scripting-vektor, vilket kan vara ganska allvarligt om utvecklare laddar en kopia av produktionsdatabasen i utveckling eller ansluter till vissa produktionstjänster för vilka det inte finns någon utvecklingsinstans, till exempel. Om ett projekt använder ett paket som `django-debug-toolbar`, kan angriparen köra godtycklig SQL, vilket kan vara särskilt illa om utvecklarna ansluter till databasen med ett superanvändarkonto.

`settings.ALLOWED_HOSTS` valideras nu oberoende av `DEBUG`. För enkelhetens skull, om `ALLOWED_HOSTS` är tomt och `DEBUG=True`, tillåts följande varianter av localhost `['localhost', '127.0.0.1', '::1']`. Om din lokala inställningsfil har ditt produktionsvärde för `ALLOWED_HOSTS` måste du nu utelämna det för att få dessa reservvärden.