Wie man die Content Security Policy entspannt

Entwickler
1

Hallo

Ich möchte Discourse testen, ohne unbedingt den konfigurierten öffentlichen Domainnamen zu verwenden. Wenn Discourse beispielsweise unter https://uat.mysite.com installiert und konfiguriert wurde, kann ich natürlich meinen Browser öffnen und zu https://uat.mysite.com navigieren. Das bedeutet, dass mein Browser mein internes Netzwerk verlassen und ins öffentliche Internet gehen würde, um den Domainnamen auf seine öffentliche IP-Adresse aufzulösen und die Seiten über seine öffentliche IP-Adresse zu laden.

Ich habe gerade versucht, über die interne IP-Adresse des Servers (z. B. 192.168.1.2, siehe unten) auf Discourse zuzugreifen, und zu Recht wird es wegen der Content Security Policy nicht geladen. Die Fehler, die ich erhalte, haben folgendes Format:

Refused to load the script 'http://192.168.1.2:12000/assets/locales/en-a9c88e45eb548bd7c807aecfd37d218891e213b5c1fd254857e0f16c72d73996.js' because it violates the following Content Security Policy directive: "script-src http://uat.mysite.com/logs/ http://uat.mysite.com/sidekiq/ http://uat.mysite.com/mini-profiler-resources/ http://uat.mysite.com/assets/ http://uat.mysite.com/brotli_asset/ http://uat.mysite.com/extra-locales/ http://uat.mysite.com/highlight_js/ http://uat.mysite.com/javascripts/ http://uat.mysite.com/plugins/ http://uat.mysite.com/theme-javascripts/ http://uat.mysite.com/svg-sprite/ 'sha256-rwfDVOTzygQmkOwFNAeX564B66beHoel4+gRLgQUgHg='". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.

                                           --------------------------------------------
                                          |                                             |
                                           ------------
uat.mysite.com löst auf zu 98.1.2.3 -->   |  Public IP |  Server mit Discourse.     |
                                          |  96.1.2.3. |
                                           ------------                                 |
                                          |                                             |
                                          |                  ----------------           |
                                          |                  |  Private IP  |           |
                                          |                  | 192.168.1.2  |           |
                                           --------------------------------------------
                                                                         ^
                                                                         |
192.168.1.2   ------------------------------------------------------------

Der Grund, warum ich über die interne IP-Adresse des Servers auf Discourse zugreifen möchte, ist, dass ich testen möchte. Wenn ich zum Beispiel Tests durchführen möchte, möchte ich nicht unbedingt das Netzwerk nutzen, das das Internet bedient. Oder wenn ich eine Testinstanz auf meinem Laptop oder einem Build-Server installieren möchte, ohne unbedingt DNS einrichten zu müssen.

Ich schätze, ich kann dies immer überschreiben, indem ich einen benutzerdefinierten Eintrag in /etc/hosts setze, aber gibt es eine Möglichkeit, CSP zu deaktivieren oder es so einzustellen, dass andere Quellen zum Testen zugelassen werden?

1 „Gefällt mir“
2

Konfigurieren Sie dann Ihre Maschine so, dass sie diese Adresse auf die lokale IP des Discourse-Servers auflöst. Es gibt viele Möglichkeiten, dies zu tun, aber sie sind betriebssystemabhängig, daher sollten Sie das Betriebssystem in Ihre Google-Suche aufnehmen. (Unter Linux und ich glaube auch unter Mac können Sie einfach /etc/hosts bearbeiten.)

1 „Gefällt mir“
3

Ich habe tatsächlich /etc/hosts ausprobiert, aber aufgrund von CSP immer noch denselben Fehler. Ich hätte gedacht, dass es ein Flag oder eine Einstellung gibt, mit der dies umgeschaltet werden kann, damit Entwickler alles auf ihrem Laptop erledigen können, ohne eine DNS-Lösung einrichten zu müssen. Wenn man sich Install Discourse on macOS for development - documentation / developers - Discourse Meta ansieht, scheint es etwas zu bootstrappen, das mit http://localhost:3000 anstelle einer IP funktioniert.

Die Herausforderung, vor der ich stehe, ist, dass ich Automatisierung zur Installation von Discourse habe und denselben Prozess verwenden möchte, um sowohl Entwicklungs-, UAT- als auch Produktionsumgebungen einzurichten, und ich möchte nicht unbedingt, dass die Entwicklungsumgebung aus dem öffentlichen Internet zugänglich ist, was derzeit eine Anforderung zu sein scheint, da sie einen ordnungsgemäßen FQDN auflösen muss. Es gibt mehrere Anwendungsfälle, einer davon ist beispielsweise die Automatisierung des wöchentlichen Upgrades von Discourse in der Entwicklungsumgebung und die Durchführung einer Reihe von Tests, um zu sehen, ob etwas fehlschlägt.

Wie auch immer, wenn es eine Möglichkeit gibt, die Anforderung zu lockern, um direkten Zugriff über IP zu ermöglichen, wäre es gut zu wissen. Ansonsten ist die einzige andere Lösung wohl, einen kleinen DNS-Dienst einzurichten und dann den Laptop so einzustellen, dass er den benutzerdefinierten DNS-Dienst verwendet, aber das scheint etwas umständlich zu sein.

4

Es gibt eine Website-Einstellung namens content security policy. Sie können das Kontrollkästchen deaktivieren und speichern, um CSP zu deaktivieren.

Solange dies nicht in einer Produktionsinstanz geschieht, ist es in Ordnung.

3 „Gefällt mir“
5

Das ist keine gute Idee. Das wird nie funktionieren. Eine Entwicklungsumgebung ist zwangsläufig anders, da sie vorkompilierte Assets und eine Reihe anderer Dinge enthält, die die Entwicklung unmöglich machen. Wenn Sie keine Plugins entwickeln, benötigen Sie überhaupt keine Entwicklungsumgebung. Wenn das der Fall ist, kann Ihre Entwicklungsumgebung eine Docker-Installation sein, es ist nur nicht das, was hier als Entwicklungsumgebung bezeichnet würde.

Sie möchten Ihre Staging- und Produktionsumgebungen mit Docker starten, wie in der Standardinstallation beschrieben.

3 „Gefällt mir“
6

Hallo! Das mache ich regelmäßig, aber mit Docker-Installationen. Wenn Sie unsere Standard-Docker-Installation in der Produktion verwenden, sollten Sie für Ihre Akzeptanztests dieselbe verwenden. Es gibt große Unterschiede zwischen Entwicklungs- und Docker-Installationen (Konfiguration, Gem- und JS-Paketversionen usw.), die bei der Bereitstellung zu Migräne führen können.

Docker-Installationen verwenden und erzwingen standardmäßig HTTPS. Wenn Sie die Container-Vorlage nicht anpassen möchten (was einige versteckte Komplexität aufweist), können Sie die HTTPS-Erzwingung einfach mit einer anderen Website-Einstellung deaktivieren.

Dies ist mein Snippet zum “Entspannen der Sicherheit in einer lokalen Docker-Installation”, das vor der Produktion genauso leicht rückgängig gemacht werden kann:

SiteSetting.content_security_policy = false
SiteSetting.force_https = false

Dann müssen Sie nur noch sicherstellen, dass Ihr Browser Port 80 im Docker-Container unter http://uat.mysite.com finden kann – beachten Sie, dass Sie http anstelle von https verwenden.

Dafür ist der /etc/hosts-Trick von @pfaffman der richtige Weg; Details für jedes Betriebssystem hier.

2 „Gefällt mir“