Sicherheit

Verwendung von Umgebungsvariablen zur Verwaltung von Einstellungen auf verschiedenen Servern

Die Verwendung von Umgebungsvariablen ist eine weit verbreitete Methode, um die Konfiguration einer App abhängig von ihrer Umgebung zu setzen.

Da sich Konfigurationen wahrscheinlich zwischen verschiedenen Einsatzumgebungen ändern, ist dies eine sehr interessante Möglichkeit, die Konfiguration zu ändern, ohne im Quellcode der App graben zu müssen, sowie Geheimnisse außerhalb der Anwendungsdateien und des Quellcode-Repositorys zu bewahren.

In Django befinden sich die wichtigsten Einstellungen als settings.py im Ordner Ihres Projekts. Da es sich um eine einfache Python-Datei handelt, können Sie das os-Modul von Python aus der Standardbibliothek verwenden, um auf die Umgebung zuzugreifen (und sogar entsprechende Voreinstellungen vorzunehmen).

Quelle: https://stackoverflow.com/questions/42077532/django-security-and-settings

Schutz vor SQL-Injection

SQL-Injection ist eine Angriffsart, bei der ein böswilliger Benutzer in der Lage ist, beliebigen SQL-Code auf einer Datenbank auszuführen. Die Querysets von Django sind vor SQL-Injection geschützt, da ihre Abfragen mithilfe von Query-Parametrisierung konstruiert werden. Der SQL-Code einer Abfrage wird getrennt von den Parametern der Abfrage definiert. Da Parameter vom Benutzer bereitgestellt werden können und daher unsicher sind, werden sie vom zugrunde liegenden Datenbanktreiber escaped.

Django gibt Entwicklern auch die Möglichkeit, rohe Abfragen zu schreiben oder benutzerdefiniertes SQL auszuführen. Diese Fähigkeiten sollten sparsam eingesetzt werden und es sollte immer darauf geachtet werden, alle Parameter, die der Benutzer kontrollieren kann, richtig zu escapen. Darüber hinaus ist bei der Verwendung von extra() und RawSQL Vorsicht geboten.

Schutz vor Cross Site Request Forgery (CSRF)

CSRF-Angriffe ermöglichen es einem böswilligen Benutzer, Aktionen mit den Anmeldeinformationen eines anderen Benutzers ohne dessen Wissen oder Zustimmung auszuführen. Django verfügt über einen eingebauten Schutz gegen die meisten Arten von CSRF-Angriffen, vorausgesetzt, dieser wurde vom Entwickler aktiviert und gegebenenfalls verwendet. Allerdings gibt es, wie bei jeder Schutztechnik, Einschränkungen.

• Das CSRF-Modul kann global oder für bestimmte Ansichten deaktiviert werden
  ➜Lösung: Nicht deaktivieren, wenn man keine Ahnung von Sicherheit hat
• Einschränkungen bei Subdomains der eigenen Website, die außerhalb der eigenen Kontrolle liegen
  ➜Lösung: Sicherstellen, dass Verbindungen HTTPS verwenden (unsichere Verbindungsanfragen weiterleiten und HSTS für unterstützte Browser verwenden)
• Vorsichtig mit der Markierung von Ansichten mit dem Dekorator csrf_exempt, es sei denn, es ist absolut notwendig

Schutz vor Cross-Site-Scripting (XSS)

XSS-Angriffe können von jeder nicht vertrauenswürdigen Datenquelle ausgehen, z.B. von Cookies oder Webdiensten, wenn die Daten vor dem Einfügen in eine Seite nicht ausreichend bereinigt wurden. Die Verwendung von Django-Templates schützt vor der Mehrzahl der XSS-Angriffe. Es ist jedoch wichtig zu verstehen, welche Schutzmechanismen es bietet und wo seine Grenzen liegen.

<style class={{ var }}>...</style>

• var könnte auf class1 onmouseover=javascript:func() gesetzt werden, welches zu einer unzulässigen JavaScript-Ausführung führt
  ➜Lösung: Zitieren des Attributwertes

• Vorsicht, wenn is_safe, safe und mark_safe mit benutzerdefinierten Template-Tags verwendet werden und autoescape ausgeschaltet ist

• Ausgabe eines anderen Formats als HTML
  ➜ Lösung: Zeichen und Wörter escapen

• Möglichst kein HTML in der Datenbank speichern, insbesondere nicht, wenn dieses HTML abgerufen und angezeigt wird

Schutz vor Clickjacking

Clickjacking ist eine Angriffsart, bei der eine bösartige Website eine andere Website in einen Rahmen einbettet. Django enthält einen Clickjacking-Schutz in Form der X-Frame-Options-Middleware, die in einem unterstützenden Browser verhindern kann, dass eine Site innerhalb eines Frames gerendert wird.

Es ist allerdings möglich, den Schutz pro Ansicht zu deaktivieren oder den genauen Header-Wert zu konfigurieren, der gesendet wird. Die Middleware wird dringend für jede Site empfohlen, deren Seiten nicht von Drittanbietern in einen Frame eingebettet werden müssen oder die dies nur für einen kleinen Teil der Site zulassen muss.

SSL/HTTPS

Für die Sicherheit ist es immer besser, die Website hinter HTTPS einzurichten. Wenn HTTPS auf dem Server aktiviert wurde, sind möglicherweise einige zusätzliche Schritte erforderlich:

• SECURE_PROXY_SSL_HEADER setzen und sicherstellen, dass die dortigen Warnungen genau verstanden wurden. Andernfalls kann dies zu CSRF-Schwachstellen führen.

• SECURE_SSL_REDIRECT auf True setzen, sodass Anfragen über HTTP auf HTTPS umgeleitet werden
  Bitte Vorbehalte unter SECURE_PROXY_SSL_HEADER beachten. Für den Fall eines Reverse-Proxys kann es einfacher oder sicherer sein, den Haupt-Webserver so zu konfigurieren, dass er die Umleitung auf HTTPS vornimmt.

• 'Sichere' Cookies verwenden
  Wenn sich ein Browser zunächst über HTTP verbindet, was bei den meisten Browsern die Standardeinstellung ist, ist es möglich, dass vorhandene Cookies ausspioniert werden. Aus diesem Grund sollten die Einstellungen SESSION_COOKIE_SECURE und CSRF_COOKIE_SECURE auf True gesetzt werden. Dies weist den Browser an, diese Cookies nur über HTTPS-Verbindungen zu senden. Dies bedeutet, dass Sitzungen nicht über HTTP funktionieren und der CSRF-Schutz verhindert, dass POST-Daten über HTTP akzeptiert werden (was in Ordnung ist, wenn der gesamte HTTP-Datenverkehr auf HTTPS umgeleitet wird).

• Verwenden von HTTP Strict Transport Security (HSTS)
  HSTS ist ein HTTP-Header, der einen Browser darüber informiert, dass alle zukünftigen Verbindungen zu einer bestimmten Site immer HTTPS verwenden sollten. In Kombination mit der Umleitung von Anfragen über HTTP auf HTTPS wird so sichergestellt, dass Verbindungen immer die zusätzliche Sicherheit von SSL genießen, sofern eine erfolgreiche Verbindung stattgefunden hat. HSTS kann entweder mit SECURE_HSTS_SECONDS, SECURE_HSTS_INCLUDE_SUBDOMAINS und SECURE_HSTS_PRELOAD oder auf dem Webserver konfiguriert werden.

Validierung des Host-Headers

Django verwendet in bestimmten Fällen den vom Client bereitgestellten Host-Header, um URLs zu konstruieren. Während diese Werte bereinigt werden, um Cross-Site-Scripting-Angriffe zu verhindern, kann ein gefälschter Host-Wert für Cross-Site-Request-Forgery, Cache-Poisoning-Angriffe und das Vergiften von Links in E-Mails verwendet werden.

Da selbst scheinbar sichere Webserver-Konfigurationen anfällig für gefälschte Host-Header sind, validiert Django Host-Header gegen die ALLOWED_HOSTS -Einstellung in der Methode django.http.HttpRequest.get_host(). Diese Validierung gilt nur über get_host(); wenn Ihr Code direkt auf den Host-Header aus request.META zugreift, umgehen Sie diesen Sicherheitsschutz.

Referrer-Richtlinie

Browser verwenden den Referrer-Header, um Informationen darüber an eine Website zu senden, wie Benutzer dorthin gelangt sind. Durch das Festlegen einer Referrer-Richtlinie kann dazu beigetragen werden, die Privatsphäre der Benutzer zu schützen, indem eingeschränkt wird, unter welchen Umständen der Referrer-Header gesetzt wird. Weitere Informationen befinden sich im Abschnitt "Referrer-Richtlinie" in der Security-Middleware-Referenz.

Session-Sicherheit

Ähnlich wie bei den CSRF-Beschränkungen, die erfordern, dass eine Site so eingerichtet werden muss, dass nicht vertrauenswürdige Benutzer keinen Zugriff auf Subdomains haben, gibt es auch bei django.contrib.sessions Einschränkungen. Weitere Informationen befinden sich im Abschnitt Sicherheit im Session-Themenhandbuch.

Zusätzliche Sicherheitsthemen

• Sicherstellen, dass sich der Python-Code außerhalb des Stammverzeichnisses des Webservers befindet. Dadurch wird sichergestellt, dass der Python-Code nicht versehentlich als reiner Text ausgegeben (oder versehentlich ausgeführt) wird.

• Django drosselt keine Anfragen zur Authentifizierung von Benutzern. Um sich gegen Brute-Force-Angriffe auf das Authentifizierungssystem zu schützen, kann ein Django-Plugin oder Webserver-Modul eingesetzt werden, das diese Anfragen drosselt.

• Den SECRET_KEY geheim halten.

• Die Zugänglichkeit des Caching-Systems und der Datenbank sollten mit einer Firewall begrenzt werden.

• Werfen Sie einen Blick auf die Top-10-Liste des Open Web Application Security Project (OWASP), in der einige häufige Schwachstellen in Webanwendungen aufgeführt sind. Während Django über Werkzeuge verfügt, um einige der Probleme zu beheben, müssen andere Probleme beim Design Ihres Projekts berücksichtigt werden.

• Mozilla diskutiert verschiedene Themen zur Web-Sicherheit. Ihre Seiten enthalten auch Sicherheitsprinzipien, die für jedes System gelten.

Quelle: https://docs.djangoproject.com/en/3.1/topics/security/