Django-Sicherheitstipps

Sie haben Glück, wenn Sie das Webframework für Perfektionisten mit knappen Deadlines verwenden (auch bekannt als Django)! Das Django-Team hat sich viele Gedanken zur Sicherheit gemacht (die Sicherheitsfunktionen finden Sie in der Dokumentation; auch die Sicherheitsrichtlinie ist interessant). Wir haben einige der besten Tipps zusammengefasst, mit denen Sie Ihr Django-Projekt schützen können.

Laden Sie unseren Spickzettel mit Django-Sicherheitstipps herunter.

Kennen Sie Ihre Version und verwenden Sie eine sichere Version

Welche Django-Version verwenden Sie? Derzeit sind drei Hauptversionen von Django im Einsatz (der Langzeit-Support für Version 1.11 endet jedoch im April 2020). Die von Ihnen verwendete Django-Version hat verschiedene Auswirkungen auf Ihr Projekt. Django 1.11 ist beispielsweise die letzte Version, die Python 2 unterstützt (dessen Support Anfang 2020 eingestellt wurde).

Außerdem bestimmt die Versionswahl, welche bekannten Sicherheitslücken in Ihrer Anwendung vorhanden und potenziell ausnutzbar sind. Erfahren Sie mehr über bekannte Django-Sicherheitslücken in unserer Schwachstellendatenbank oder scannen Sie Ihr Projekt mit Snyk. Wir informieren Sie, wenn Sie eine verwundbare Version verwenden.

Wichtig ist außerdem, dass Sie einen Plan haben, um Ihre Django-Version aktuell zu halten. Im Allgemeinen empfiehlt es sich, eine Version mit langfristigem Support zu wählen und den Umstieg auf die nächsthöhere Version zu planen, bevor der Support für Ihre aktuelle Version endet. So profitieren Sie vom Support der Maintainer, ohne Ihre Version ständig ändern zu müssen.

Noch ein Hinweis: Achten Sie darauf, die Dokumentation für die richtige Django-Version zu verwenden. Sie möchten sicher nicht aufgrund einer Sicherheitsrichtlinie, von der Sie in der Dokumentation gelesen haben, davon ausgehen, dass eine Sicherheitsmaßnahme aktiv ist, und dann feststellen, dass die von Ihnen verwendete Version nicht mit der Version in der Dokumentation übereinstimmt.

Begrenzen Sie die Anzahl der Authentifizierungsversuche

Django verfügt über zahlreiche integrierte Sicherheitsfunktionen, doch das Authentifizierungssystem bietet keinen grundlegenden Schutz vor Brute-Force-Angriffen. Ein Angreifer könnte zahlreiche Anmeldeversuche auf Ihrem System durchführen und sich möglicherweise Zugang verschaffen.

Wenn Sie solche Angriffe für Ihr Projekt als Bedrohung einschätzen, können Sie ein Projekt wie Django Defender verwenden, um Benutzer nach zu vielen Anmeldeversuchen zu sperren.

Schützen Sie Ihren Quellcode

Den Quellcode zu schützen, mag selbstverständlich erscheinen. Da es dabei jedoch mehrere Aspekte zu berücksichtigen gibt, lohnt es sich, das Thema genauer zu betrachten. Eine Möglichkeit besteht darin, sicherzustellen, dass sich Ihr Quellcode nicht im Stammverzeichnis Ihres Webservers befindet. Andernfalls besteht die Gefahr, dass er bereitgestellt oder teilweise auf eine Weise ausgeführt wird, die Sie nicht vorgesehen haben.

Und auch wenn es selbstverständlich sein sollte: Wenn Ihr Projekt vertraulich ist, verwenden Sie unbedingt ein privates Repository auf GitHub, Bitbucket oder Gitlab. Achten Sie außerdem darauf, niemals Geheimnisse in Ihr Versionskontrollsystem einzuchecken – unabhängig davon, ob Sie ein privates Repository verwenden möchten. Ein privates Repository bleibt möglicherweise nicht immer privat, und nicht allen Personen mit Zugriff darauf kann man vertrauen.

Gehen Sie mit Raw Queries und benutzerdefiniertem SQL vorsichtig um

Auch wenn es verlockend ist, Raw-SQL-Abfragen und benutzerdefiniertes SQL zu schreiben, kann dadurch ein Einfallstor für Angriffe entstehen. Das Object-Relational-Mapping-Framework (ORM) von Django erleichtert Datenbankabfragen. QuerySets werden mithilfe von Query-Parametrisierung erstellt. Die Abfrageparameter sind vom SQL-Code der Abfragen getrennt. Wer eine SQL-Injection versucht (also beliebiges SQL in einer Datenbank ausführt), hat es deutlich schwerer, wenn Sie stets das ORM verwenden.

Django ermöglicht die Verwendung von Raw Queries, empfiehlt sie jedoch nicht. Wenn Sie sie dennoch nutzen, achten Sie besonders darauf, alle Parameter ordnungsgemäß zu escapen. Falls das Django-ORM Ihren Anforderungen nicht genügt, können Sie auch ein anderes ORM mit Django verwenden. SQLAlchemy ist ein Beispiel für ein ORM, das sich mit Django einsetzen lässt. Wenn ein anderes ORM besser zu Ihrem Projekt passt, ist dessen Verwendung vorzuziehen, statt große Mengen Raw-SQL zu schreiben.

Verwenden Sie HTTPS

Unabhängig davon, für welches Framework Sie sich entscheiden, sollten Sie Ihre Anwendung immer über HTTPS bereitstellen. Dadurch wird verhindert, dass Angreifer die zwischen Client und Server übertragenen Informationen abfangen. Damit HTTPS korrekt funktioniert, müssen Sie Ihre Einstellungen sorgfältig festlegen.

Die folgenden Einstellungen sind für die Verwendung von HTTPS wichtig. Machen Sie sich damit vertraut und aktivieren Sie sie korrekt. Die Dokumentation erläutert die Einstellungen, die sicheren Standardwerte und die Gründe, aus denen Sie sie gegebenenfalls ändern müssen.

• SECURE_PROXY_SSL_HEADER

• SECURE_SSL_REDIRECT

• SESSION_COOKIE_SECURE

• CSRF_COOKIE_SECURE

• SECURE_HSTS_SECONDS

• SECURE_HSTS_INCLUDE_SUBDOMAINS

• SECURE_HSTS_PRELOAD

Behalten Sie Ihre Header im Blick 

Betrachten wir zunächst den Referer-Request-Header. Dieser Header enthält die Adresse der vorherigen Webseite, von der aus Sie die aktuelle Seite aufgerufen haben. Diese Information ist unter anderem für Analysen nützlich. Manchmal verursacht sie jedoch Probleme, denn im Allgemeinen möchten Menschen nicht im Web verfolgt werden. Aus Datenschutzgründen lässt sich diese Funktion deaktivieren.  Ob ein Referer-Request-Header mitgesendet wird, lässt sich über den Referer-Policy-Header festlegen. Je nach Bedingungen werden teilweise Informationen übermittelt, in anderen Fällen alle Informationen – und manchmal wird gar kein Referer-Request-Header weitergeleitet.

Wird die Website über HTTPS bereitgestellt, nutzt Django den Referer-Request-Header, um vor Cross-Site-Request-Forgery-Angriffen (CSRF) zu schützen. Wenn Sie die Referer-Policy zu streng festlegen, deaktivieren Sie damit den CSRF-Schutz von Django. Letztlich müssen Sie die Datenschutzvorteile einer strikten Referer-Policy gegen die Vorteile des CSRF-Schutzes abwägen. Ein Kompromiss ist möglich: Aktivieren Sie in der Referer-Policy ausschließlich Same-Origin-Referrer.

Gehen Sie sorgfältig mit Cookies um

Manche Cookies sind sicherer als andere – standardmäßig werden Cookies über HTTP übertragen. Da wir bereits festgestellt haben, dass Sie HTTPS verwenden sollten, müssen Sie auch sicherstellen, dass Ihre Cookies ausschließlich über HTTPS gesendet werden. Um zu verhindern, dass Cookies offengelegt werden, setzen Sie SESSION_COOKIE_SECURE und CSRF_COOKIE_SECURE auf True. Damit weisen Sie den Browser an, diese Cookies nur über HTTPS-Verbindungen zu senden. Wenn Sie diese Parameter auf True setzen, kann es zu interessanten Nebeneffekten kommen. Diese sollten sich jedoch durch die Weiterleitung von HTTP-Datenverkehr an HTTPS abmildern lassen.

Behandeln Sie Uploads von Benutzern sorgfältig

Wenn Ihre Webanwendung Benutzern das Hochladen von Dateien ermöglicht, eröffnen Sie damit einen potenziellen Angriffsvektor. Die Upload-Logik sollte daher sorgfältig umgesetzt werden. Zunächst müssen Sie alle hochgeladenen Dateien validieren, um sicherzustellen, dass sie den Erwartungen entsprechen (zum Beispiel eine Bilddatei und kein PHP-Skript!). Es darf Benutzern nicht möglich sein, Code auszuführen.

Mit verschiedenen Maßnahmen können Sie hochgeladene Dateien validieren oder sorgfältiger behandeln. Dazu gehören:

• Erstellen Sie eine Positivliste zulässiger Dateitypen

• Begrenzen Sie die zulässige Dateigröße, um Denial-of-Service-Probleme zu verhindern

• Deaktivieren Sie Handler, die statische Dateien als Code ausführen würden (deaktivieren Sie zum Beispiel Apache mod_php)

• Nutzen Sie Schutzmaßnahmen gegen Cross-Site-Scripting. Wenn Sie Benutzerinhalte über eine separate Top-Level-Domain bereitstellen, greifen die Schutzmaßnahmen gegen Cross-Site-Scripting und schützen Sie. Dabei kann es sich um eine von Ihnen verwaltete Domain handeln. Wahrscheinlich ist es jedoch einfacher, die Dateien über einen Cloud-Dienst oder einen Content-Delivery-Network-Anbieter bereitzustellen.

Machen Sie sich mit all Ihren Abhängigkeiten vertraut

Wenn Sie eine Django-Version mit wenigen oder gar keinen bekannten Sicherheitsrisiken gewählt haben, denken Sie vielleicht, dass es keine weiteren Sicherheitsprobleme gibt. Es ist jedoch wichtig, die Open-Source-Bibliotheken zu kennen, die Django importiert, und zu wissen, ob diese Bibliotheken Schwachstellen enthalten.

Wenn Sie Django (oder eine beliebige Open-Source-Bibliothek) einbinden, binden Sie in der Regel _auch_ jede Bibliothek ein, die Ihre gewählte Bibliothek verwendet. Open Source basiert auf Open Source, das wiederum auf noch mehr Open Source basiert.

Indirekte Abhängigkeiten können ebenso wahrscheinlich Risiken verursachen wie direkte Abhängigkeiten, doch diese Risiken werden seltener erkannt. Mit einem Tool wie Snyk können Sie Ihren gesamten Abhängigkeitsbaum nachvollziehen. Und da Snyk jetzt Fix-Pull-Requests für Python anbietet, lassen sich Probleme – auch in indirekten Abhängigkeiten – einfacher denn je beheben.

Lassen Sie nicht zu, dass Perfektion dem Guten im Weg steht

Jeder Schritt, den Sie für mehr Sicherheit unternehmen, ist ein Schritt in die richtige Richtung. Django mag für Perfektionisten mit knappen Deadlines gedacht sein, doch Ihr Code muss nicht perfekt sein, damit Sie von mehr Sicherheit profitieren. Wenn Sie die oben beschriebenen Konzepte so gut wie möglich umsetzen, können Sie die Sicherheit Ihres Codes erheblich verbessern und ein robusteres, widerstandsfähigeres Projekt schaffen. Viel Spaß beim Programmieren, Pythonistas!