So stellen Sie Django bereit

TEIL 1. Sicherheit geht vor

Der beste Zeitpunkt, Schwachstellen zu beheben, ist während der Entwicklung.

1.1 CSRF TOKEN

Im Sicherheitsframework von Django ist CSRF TOKEN eine entscheidende Sicherheitsstrategie. In vielen Fällen stellen einige Schüler, die gerade erst mit Django in Kontakt gekommen sind, fest, dass das Formular, das sie schließlich geschrieben haben, beim POST einen Fehler meldet. Nach einigen Suchvorgängen stellen sie fest, dass es sich um ein CSRF-TOKEN-Problem handelt, und folgen dann dem Online-Vorgang Methode zum Teilen des Formulars durch drei, fünf und zwei. Alle CSRF TOKEN-Konfigurationen in „settings.py“ wurden entfernt und der Code wurde normal ausgeführt. Sie wissen nicht, dass diese Art von Vorgang die Sicherheit der Website erheblich beeinträchtigen und die Kosten für das Patchen von Schwachstellen in der späteren Phase erhöhen wird. Die Beseitigung von Sicherheitsproblemen während der Entwicklungsphase ist der kostengünstigste.

Da in der offiziellen Dokumentation der relevante Inhalt von CSRF TOKEN ausführlich erläutert wurde, wird die spezifische Verwendung hier nicht beschrieben. Hier empfehlen wir eine komfortablere Nutzung, die für Entwickler während der Entwicklung weniger empfindlich ist und keine besondere Sorgfalt darauf erfordert, ob das Token erfolgreich gesendet wurde.

Fügen Sie {% csrf_token %} zur gesamten übergeordneten Vorlagenseite hinzu und legen Sie Folgendes im Abschnitt <script> fest: </script>

Auf diese Weise werden alle Nicht-GET|HEAD|OPTIONS| initiiert JQuery TRACE-Anfragen enthalten automatisch CSRF TOKEN (ein Teil des Codes zum Abrufen des CSRF TOKEN ist nicht aufgeführt. Wenn Sie andere HTTP-Bibliotheken oder Fetch verwenden, nehmen Sie einfach die entsprechenden Einstellungen vor).

1.2 API-Sicherheitsdesign

In einigen Fällen stellt unser Webdienst auch einige API-Dienste für Aufrufe von anderen Systemen zur Verfügung. Für diese API-Schnittstellen muss CSRF deaktiviert werden, andernfalls ist dies nicht möglich normal genutzt. Wir sollten auch andere Sicherheitsmaßnahmen ergreifen, um einen Missbrauch von API-Schnittstellen zu verhindern. Zusätzlich zu den normalen Übergabeparametern sollten wir sicherstellen, dass diese Parameter nicht von Zwischenhändlern manipuliert werden und nur autorisierten Personen erlauben, die entsprechende Schnittstelle aufzurufen. Aus diesem Grund müssen wir mehrere zusätzliche Übergabeparameter einführen: Zeitstempel, Vorzeichen usw. access_key, access_token.

Dieses Parameterpaar umfasst access_key und access_token. access_key entspricht der Identifizierung des Anrufers und access_token entspricht dem geheimen Schlüssel des Anrufers. Der Inhalt von access_token sollte nicht leicht vorhersehbar sein, und access_key kann aus Speichergründen eine einfachere Zeichenfolge auswählen. Nur wenn die beiden Parameter übereinstimmen, gilt der API-Aufruf als legal.

Wählen Sie die Genauigkeit des Zeitstempels entsprechend den Geschäftsanforderungen. Sie können zwischen Sekunden und Millisekunden wählen. Der Hauptzweck des Hinzufügens eines Zeitstempels besteht darin, zu verhindern, dass dieser Anruf wiederholt wird. Der Server sollte überprüfen, ob der vom Client übergebene Zeitstempel innerhalb eines Zeitbereichs liegt. Um die Authentizität der Parameter sicherzustellen, muss ein weiteres Parameterzeichen eingeführt werden, denn auch bei der Wiedergabe des Zeitstempels besteht weiterhin die Gefahr einer Manipulation.

sign ist der Signaturwert aller Parameter, der von allen an der Hash-Berechnung beteiligten Parameterwerten generiert wird. Jedes Mal, wenn sich die Parameter geringfügig ändern, muss das Vorzeichen neu generiert werden, um die Authentizität der Parameter sicherzustellen. Ein häufig verwendeter Algorithmus ist: Sortieren Sie den Parameterwert gemäß der alphabetischen Reihenfolge des Parameterschlüssels und verwenden Sie bestimmte Trennzeichen, um alle Parameter zu verbinden. Führen Sie dann eine Hash-Berechnung durch und übergeben Sie die Vorzeichenparameter gemeinsam an den Server. Beispielsweise ist der vorhandene Parameter ak=2222&at=1111&timestamp=3333&key1=aaa nach alphabetischer Sortierung 22221111aaa3333, nach Hinzufügen des Trennzeichens (|) 2222(|)1111(|)aaa(|)3333, und dann berechnet diese Zeichenfolge sha1 und generiert einen Vorzeichenwert. Es ist relativ einfach, es in Python-Code zu schreiben:

1.3 Einige verschiedene Punkte

Zusätzlich zu den beiden oben genannten wichtigeren Punkten gibt es einige Stellen, die zusätzliche Aufmerksamkeit erfordern.

Deaktivieren Sie den DEBUG-Modus in der Produktionsumgebung.

Setzen Sie die Datei „settings.py“ nicht zur Versionsverwaltung ein und schützen Sie SECRET_KEY.

Verwenden Sie das von Django bereitgestellte ORM Vermeiden Sie nach Möglichkeit die direkte Ausführung von SQL-Anweisungen über Methoden wie .raw(), stellen Sie sicher, dass Sie die Parameter korrekt maskieren, um SQL-Injection-Schwachstellen zu vermeiden. Wenn nötig, deaktivieren Sie Django Admin Verwenden Sie es, ändern Sie es bitte. TEIL 2. So stellen Sie es bereit: Ziehen Sie den Code aus Git, installieren Sie Projektabhängigkeiten und führen Sie den Dienst über manage.py aus , aber planen Sie wirklich, es in der Produktion einzusetzen? Ist das in der Umgebung der Fall?

2.1 Isolierte Umgebung

Unter normalen Umständen gibt es auf unserem Server nur eine Python-Umgebung. Bei der Bereitstellung installieren wir normalerweise die für das Projekt erforderlichen Abhängigkeiten über pip Verzeichnis.

Bei der Bereitstellung mehrerer Projekte kann diese Methode zum Installieren von Abhängigkeiten leicht zu Abhängigkeitskonflikten führen. Um ein einfaches Beispiel zu geben: Wir haben jetzt zwei Projekte, Projekt-A und Projekt-B. Sowohl A als auch B hängen von unterschiedlichen Versionen des Drittanbieterpakets „Third-A“ ab , Die Abhängigkeit von Third-A wird in der globalen Python-Umgebung installiert. Wenn wir pip install -r require-b.txt erneut installieren, wird zu diesem Zeitpunkt auch Third-A erneut installiert, wenn die Versionen von denen die beiden Projekte abhängen sind inkonsistent, zum Beispiel erfordert Projekt A Version 1.0 und Projekt B erfordert Version 2.0, was zu einem Abhängigkeitskonflikt führt und dazu führt, dass die Installation von Abhängigkeiten fehlschlägt.

Wie kann man dieses Problem lösen? Wir können uns leicht vorstellen, dass dieses Problem leicht gelöst werden kann, wenn wir über mehrere unabhängige isolierte Umgebungen verfügen und jedes Projekt in einer unabhängigen Umgebung bereitgestellt wird. Virtualenv wurde entwickelt, um dieses Problem zu lösen. Es kann für jedes Projekt eine separate Betriebsumgebung erstellen, um Abhängigkeitskonflikte zu vermeiden.

2.2 Versionsverwaltung

Wir wussten früher, wie man isolierte Umgebungen erstellt und verschiedene Projekte in verschiedenen Umgebungen bereitstellt, aber es gibt ein Problem. Die von allen Umgebungen verwendete Python-Version ist die gleiche. Wenn Sie zufällig mehrere verschiedene Versionen von Python-Projekten bereitstellen müssen, z. B. Python 2.7 (ich weiß, dass diese Version nicht bald gewartet wird, aber ich werde hier ein Beispiel geben), Python 3.6 und Jython-Projekte, scheint es sinnvoll, sie einzeln zu installieren Etwas kompliziert, selbst beim Kompilieren und Installieren fehlt versehentlich ein bestimmter Kompilierungsparameter und muss neu kompiliert werden, was den Arbeitsaufwand für die Bereitstellung etwas erhöht.

Wir können pyenv verwenden, um die Probleme mehrerer Python-Versionen zu verwalten, und außerdem das Pyenv-Plug-in pyenv-virtualenv verwenden, um die Probleme mehrerer Python-Versionen und mehrerer virtueller Umgebungen zu verwalten.

2.3 Gateway-Schnittstelle

Nachdem wir die Probleme in verschiedenen Umgebungen gelöst haben, ist es an der Zeit, darüber nachzudenken, wie das Projekt ausgeführt werden soll. Wenn Sie an Python manage.py runserver 0.0.0.0:80 denken, ist das etwas zu viel. Einfach.

Django hat eine einfache WSGI-Implementierung integriert, mit der wir den Webdienst über die oben beschriebene Methode starten können. Wenn Sie nur ein paar Leute debuggen oder Dienste bereitstellen möchten, ist dies auch eine optionale Lösung. Es sieht nicht sehr elegant aus.

Wenn Sie die Anwendung wirklich in einer tatsächlichen Produktionsumgebung bereitstellen möchten, benötigen Sie auch einen leistungsstarken WSGI-Server und nicht den einfachen WSGI-Server von Django. Gunicorn und uWSGI sind beide relativ gängige WSGI-Server. Wählen Sie einfach einen davon entsprechend der tatsächlichen Bereitstellungsumgebung aus.

Ich persönlich bevorzuge jedoch Gunicorn, obwohl es in vielen Leistungstests die Oberhand hat. Der Grund für die Wahl von Gunicorn ist, dass es im Vergleich zu uWSGI sehr einfach ist und nicht über sehr komplexe und selten genutzte Funktionen verfügt Seine Funktionen wurden nach und nach von Nginx unterstützt und Gunicorn ist relativ einfach und bequem zu konfigurieren. Beachten Sie außerdem, dass Sie bei der Bereitstellung unter Windows möglicherweise Apache+mod_wsgi verwenden müssen.

2.4 Reverse-Proxy

Nachdem unser WSGI-Server gestartet wurde, müssen wir das Problem des Reverse-Proxys berücksichtigen. Der Grund, warum es eine andere Ebene von Nginx gibt, um Reverse-Proxy auszuführen, ist aus folgenden Gründen:

Nginx ist erforderlich Umgang mit statischen Ressourcen. Wenn Sie den DEBUG-Modus von Django auf „False“ setzen, werden Sie feststellen, dass viele statische Ressourcen wie CSS und JS nicht geladen werden können. Dies liegt daran, dass Django diese Anfragen nicht aktiv verarbeitet und Nginx bei der Verarbeitung helfen muss um den Lastausgleich mehrerer Backends durchzuführen. Wenn Ihr Dienst auf mehreren Servern bereitgestellt wird oder über eine primäre und eine Backup-Bereitstellung verfügt, können diese durch einfache Einstellungen auf Nginx erreicht werden.

Es gibt bestimmte Probleme beim direkten Aufdecken von uWSGI- oder Gunicorn-Sicherheitsrisiken Verwenden Sie Nginx, um HTTP-Probleme zu lösen.

Darüber hinaus gibt es einige Gründe, die hier nicht aufgeführt sind. Auch hier gilt: Wenn Ihr Dienst sehr einfach ist und nur wenige Personen darauf zugreifen, müssen Sie keine derart komplizierten Einstellungen vornehmen .

2.5 Process Daemon

Ab sofort haben wir den Dienst erfolgreich bereitgestellt und können mit der normalen Bereitstellung von Diensten beginnen. Aber wir denken weniger darüber nach, wenn unser Django aus irgendeinem unbekannten Grund leider beendet wird, wird unser Webdienst zu einem 502. Um die Stabilität des Dienstes sicherzustellen, müssen wir den Django-Prozess schützen. Wenn ein unbekanntes Problem auftritt und einen abnormalen Exit verursacht, muss der erforderliche Prozess automatisch aufgerufen werden.

Die Verwendung von Supervisor als Überwachungstool kann das stabile Überleben des Django-Prozesses sicherstellen. Es ist wichtig, darauf zu achten, dass die Schwachstelle „Supervisord“ bei der Remote-Befehlsausführung vermieden wird, um schwerwiegendere Unfälle zu vermeiden.

TEIL 3. Hintergrunddienst

Wenn Sie einen Hintergrunddienst starten möchten, ist Sellerie im Allgemeinen eine universelle Wahl, aber oft möchten wir keine so starke Abhängigkeit einführen, also müssen wir einen Weg finden, dies zu tun Starten Sie den Hintergrunddienst selbst.

Eine einfache Methode besteht darin, den Befehl manage.py zu erteilen, unseren Hintergrunddienst über ./manage.py runcommand zu starten und den Start und Stopp des Dienstes durch das Schreiben eines Shell-Skripts zu steuern oder ihn über Supervisor zu verwalten.

Wenn Sie möchten, dass der Hintergrundprozess gleichzeitig mit dem Webdienst gestartet und gestoppt wird, ist es eine gute Wahl, ihn in wsgi.py einzufügen. Initialisieren Sie den entsprechenden Hintergrunddienst in wsgi.py und starten Sie ihn. Dieser Ansatz ist jedoch nicht flexibel genug. Wenn der Webdienst oder der Hintergrunddienst separat aktualisiert werden müssen, müssen beide Dienste neu gestartet werden. Mit der ersten Methode kann jedoch einer der Dienste separat aktualisiert werden.

Das obige ist der detaillierte Inhalt vonSo stellen Sie Django bereit. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!