it-swarm.com.de

Django SECRET_KEY Sicherheit, wie sind Methoden sicherer

Ich nähere mich einem Punkt, an dem ich meine Django - Anwendung in der feindlichen Umgebung bereitstellen werde, die auch als "Internet" bekannt ist, und ich versuche, die Auswirkungen des Django SECRET_KEY. Eine der Standardprozeduren scheint darin zu bestehen, den geheimen Schlüssel im settings.py Zu sichern. Fair genug. Die Dokumente gehen so weit zu sagen, dass Sie Ihren geheimen Schlüssel nicht festschreiben sollen SVN, CVS usw. Dies ermöglicht einen einfachen Zugriff auf Ihren Schlüssel. Wenn jedoch jemand versucht wäre, den geheimen Schlüssel für sein Repo festzulegen, würde dies darauf hinweisen, dass der geheime Schlüssel statisch ist (siehe Frage 4).

Wie auch immer, hier sind meine Fragen:

  1. Wie ist das Speichern des geheimen Schlüssels als Umgebungsvariable sicherer als das direkte Speichern in settings.py? Wenn ein Angreifer beispielsweise settings.py Lesen kann, kann er höchstwahrscheinlich nur $ echo $Django_SECRET_KEY Eingeben!
  2. Wie ist das Speichern des geheimen Schlüssels in einer Datei sicherer als das direkte Speichern in settings.py? Wenn er settings.py Lesen kann, kann er wahrscheinlich Django_secret_key.txt Lesen.
  3. Wenn der Angreifer Ihren Computer kompromittiert hat, kann er dann nicht einfach den python Interpreter mit settings.py In > print settings.SECRET_KEY Laden?
  4. Wäre es schließlich eine schlechte Praxis, den geheimen Schlüssel bei jedem Neustart des Webserver-Prozesses zufällig zu generieren? Dies kann völlig zufällig sein oder zur Benutzereingabe für den Schlüssel auffordern. Letzteres stellt offensichtlich eine ernsthafte Schwäche dar, wenn der Angreifer selbst den Webservice neu starten und den Schlüssel seiner Wahl eingeben kann.
26
James

Sobald ein Angreifer bereits Zugriff auf das System hat, ist es bereits viel zu spät. Das Hauptanliegen, den Schlüssel nicht zu verlieren, besteht darin, dass er häufig als Startwert für Hashing- und Signatursitzungen verwendet wird. Die Idee ist, dass Ihre Produktion SECRET_KEY Ganz anders sein muss als Ihre Entwicklung oder Inszenierung SECRET_KEY. Sie können es bei jedem Neustart zufällig generieren, obwohl dies die Benutzererfahrung beeinträchtigen kann (siehe Details unten).

Solange Sie sich an das Prinzip der Schlüsseländerung halten, besteht keine große Gefahr, ob Sie sich verpflichten oder nicht (solange Sie sicherstellen, dass es geändert wird, sobald Sie von dev zu prod wechseln). Wenn Sie dies nicht tun, kann jemand mit dem Schlüssel das Ergebnis von Hashing-Algorithmen (die für Sitzungen verwendet werden) vorhersagen oder sogar Sitzungen signieren.

Wenn ein Angreifer Zugriff auf Ihr System erhalten hat, sind Sie bereits zu weit gegangen, da es nicht mehr Ihr System ist. Sie müssen sicherstellen, dass die Dateiberechtigungen für Ihre Einstellungsdatei nur von dem Benutzer gelesen werden können, der den Webserver ausführt, und von niemand anderem. Dies verhindert, dass jemand, der unrechtmäßig Zugriff auf ein eingeschränktes Konto erhalten hat, das nicht mit dem Webserver-Konto identisch ist, Ihren Schlüssel gefährdet.

Hier auf Stack Overflow gibt es eine gute Antwort: Django SECRET_KEY geschrieben von sberder für welche Details es verwendet wird:

In Wirklichkeit verwenden viele der hier aufgelisteten Elemente SECRET_KEY Bis Django.utils.crypt.get_random_string(), wodurch die Zufalls-Engine gesetzt wird. Dies wird durch eine Wertänderung von SECRET_KEY Nicht beeinflusst.

Die Benutzererfahrung, die direkt von einer Wertänderung betroffen ist, ist:

  • in Sitzungen wird die Datendecodierung unterbrochen, die für jedes Sitzungs-Backend (Cookies, Datenbank, dateibasiert oder Cache) gültig ist.
  • das bereits gesendete Token zum Zurücksetzen des Passworts funktioniert nicht. Benutzer müssen ein neues Token anfordern.
  • das Kommentarformular (bei Verwendung von Django.contrib.comments) wird nicht überprüft, ob es vor der Wertänderung angefordert und nach der Wertänderung übermittelt wurde. Ich denke, das ist sehr geringfügig, könnte aber für den Benutzer verwirrend sein.
  • nachrichten (von Django.contrib.messages) werden nicht serverseitig unter den gleichen Zeitbedingungen wie für das Kommentarformular validiert.
19
Lucas Kauffman