Ankündigung

Einklappen
Keine Ankündigung bisher.

Content-Security-Policy (CSP) richtig configurieren.

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Content-Security-Policy (CSP) richtig configurieren.

    Hallo Forum,

    ich bin bin neulich auf CSP gestoßen und arbeite nun daran dies in mein System zu integrieren.
    Leider habe ich die ein oder anderen Punkte die mir unklar sind.
    Im Grunde wäre es mir generell recht wenn jede Datei mit einem nonce-Attribut eingebunden würde, da hat man eben 100%tige Whitelist, dies hat soweit auch geklappt, diese konnten dann aber trotz des Tokkens kein Inline ausführen. Was problematisch ist.

    Code:
    header("content-security-policy: script-src 'nonce-{$nonceTokken}'; style-src 'nonce-{$nonceTokken}'");
    Nun habe ich natürlich auch mal bei großen Seiten spioniert und fand folgendes:
    Code:
    header("content-security-policy: default-src 'self' blob: wss: data: https:; img-src 'self' data: https:; script-src 'self' 'unsafe-inline' blob: data: https:; style-src 'self' 'unsafe-inline' data: https:;");
    Obwohl die Seite mansche Elemente mit einem nonce-Tokken einbaut, ist dort im Header kein Tokken zu finden, was mich etwas verwirrt.
    Des weiteren habe ich leider keine Dokumentation gefunden die auch mal die Parameter blop/data näher erklärt.

    default-src umfasst alle Elemente die nicht separat definiert werden (wenn ich es richtig verstanden habe) und klar die Values wss/https sind entsprechende SSL-Protokolle.
    Ich denke mal das hier mit der Angabe 'self' gesagt wird das eben aus eigener Quelle stammende Dateien über https zugelassen werden.
    Da kein nonce-Tokken gesetzt ist müssten eigentlich alle externen Sachen abgelehnt werden und doch hat die Seite externe Sachen eingebunden.

    Nun gut d.h. aus eigener Quelle würden css/js inline ausführen können da ja bei script/style 'unsafe-inline' gesetzt ist aber das einbetten von fremden Quellen funktioniert ebenfalls obwohl 'self' gesetzt ist.
    Es muss doch möglich sein eine Kombination zu setzten in der man sagt eigene Quellen (inkl. subdomains, wichtig!!) sind sicher und dürfen inline ausführen externe Dateien erfordern einen nonce tokken.
    Wobei das ganze unsafe-inline ja eigentlich kein Sinn macht, Sinn und zweck ist ja XSS-vorzubeugen, schleußt der Angreiffer dennoch code ein welcher im Dom landet kann er wieder inline ausführen xD
    Schöner wäre es ja die attribute style/onLoad etc. zu verbieten aber sichere JS-Dateien müssen weiterhin den DOM frei manipulieren können sonst gibt es eben Probleme mit entsprechenden modulen.

    Ich hoffe Jemand kann etwas Licht ins dunkle bringen, ein anwendbares Beispiel zwecks Syntax wäre toll.

    MfG: Paykoman



  • #2
    Das hat nichts mit PHP zu tun. Content Security Policy ist ein Sicherheitskonzept und Level 3 ist in der Bearbeitung. Es wird iim Header von HTTP übertragen.
    Welche Eigenschaften davon von den Browsern unterstützt werden findet sich auf der MDN Seite.

    Inline mit Token geht nicht, es muss alles in Dateien stehen, also CSS und Javascript, sonst ist das Sicherheitskopnzept ja auch unnütz.
    Allgemeines steht bei Wikipedia.

    Kommentar


    • #3
      Hallo, nun das es nix mit PHP zu tun hat ist klar, hatte ja lediglich erwähnt das ich entsprechenden Header über PHP setze um CSP zu aktivieren.
      So habe ich eben ausdrücken können wie bzw. was genau ich als Header setzte und was eine andere große Seite als Header gesetzt hat, dazu hatte ich ja dann entsprechende Fragen warum und wieso...

      Aktuell verwende ich eben immer noch folgende Parameter:
      Code:
      header("content-security-policy: script-src 'nonce-{$nonceTokken}'; style-src 'nonce-{$nonceTokken}'");
      Meine Problematik war oben ja eigentlich beschrieben, das selbst Dateien die auf Grund eines Tokkens als sicher geflagt werden trotzdem kein inlinecode (oder ggf. nur direkten) anwenden dürfen.
      Ich habe z.B. Fancybox3 eingebunden, diese erstellt neue DOM-Elemente mit style Attribute was vom Browser geblockt wird weil die Art und Weise wohl nicht optimal ist.

      Wenn ein Element so erstellt wird $('<div style="display: none;">hallo</div>).appendTo('body'); wird es geblock aber ein $('<div>').css({'display':'none').appendTo('body') ; kann hinzugefügt werden.
      Einer meiner Fragen war ob es nicht möglich ist Dateien die als sicher gelten wieder stinknormal vollen Zugriff zu gewähren (wer weiß was später noch so auf ploppt das ich bugfixen muss weil inline nicht geht).

      Der andere Header (oben) war von eBay, diese setzten bei style/script-src 'self' 'unsafe-inline' aber wenn ich die Parameter so setzte kann ich doch direkt auf CSP verzichten weil eben direkt wieder style und js Attribute im HTML angewendet werden, also wird keine Sicherheitslücke mehr geschlossen.
      Dazu habe ich in den Dokus noch nix gefunden bzg. blop und data und meine Frage ist eben halt wie ich den Header entsprechend anpassen kann um erwähnte Probleme zu beheben.

      Kommentar


      • #4
        Zitat von Paykoman Beitrag anzeigen
        Ich habe z.B. Fancybox3 eingebunden, diese erstellt neue DOM-Elemente mit style Attribute was vom Browser geblockt wird weil die Art und Weise wohl nicht optimal ist.
        Dann darfst du solche Zusätze eben nicht verwenden. Wir weisen hier auch immer wieder darauf hin dass es schlechter Stil ist Inline CSS zu verwenden. Zur Trennung von Markup und Darstellung gehört es eben, dass CSS und Javascipt im Markup nichts verloren hat und in Dateien gehört
        Jetzt weisst du wenigstens warum wir das ständig sagen.

        Zitat von Paykoman Beitrag anzeigen
        Einer meiner Fragen war ob es nicht möglich ist Dateien die als sicher gelten wieder stinknormal vollen Zugriff zu gewähren (wer weiß was später noch so auf ploppt das ich bugfixen muss weil inline nicht geht).
        Keine Ahnung, aber wenn du das willst, dann brauchst du auch kein Sicherheitskonzept a la CSP.

        Zitat von Paykoman Beitrag anzeigen
        Der andere Header (oben) war von eBay, diese setzten bei style/script-src 'self' 'unsafe-inline' aber wenn ich die Parameter so setzte kann ich doch direkt auf CSP verzichten weil eben direkt wieder style und js Attribute im HTML angewendet werden, also wird keine Sicherheitslücke mehr geschlossen.
        Mein Reden, dann wird das Sicherheitskonzept eigentlich aufgehoben.

        Kommentar


        • #5
          Zitat von protestix Beitrag anzeigen
          Dann darfst du solche Zusätze eben nicht verwenden. Wir weisen hier auch immer wieder darauf hin dass es schlechter Stil ist Inline CSS zu verwenden. Zur Trennung von Markup und Darstellung gehört es eben, dass CSS und Javascipt im Markup nichts verloren hat und in Dateien gehört
          Nun aber genau das ist doch das Problem, fancybox ist ja nicht inline eingebettet, es wird über fancybox.css/.js eingebunden.
          Diese wird mit nonce als sicher geflagt, diese muss entsprechend doch den Dom wieder frei manipulieren können ansonsten katapultieren wir uns zurück zu statische Webseiten die nur einmal bei der Anfrage geparst und ausgegeben werden wo keine weitere Änderungen möglich sind.

          Zudem ist eben das verwunderliche das ich oben ja aufgezeigt habe das es durch aus möglich ist die Blockierung zu umgehen, wenn ich mit JQ dem Element style über $('#element').css({'top': '10px'}); setzte funktioniert es wenn man aber direkt .style() nutzt eben nicht..

          Zitat von protestix Beitrag anzeigen
          Keine Ahnung, aber wenn du das willst, dann brauchst du auch kein Sicherheitskonzept a la CSP.
          Vllt. liegt auch da mein Problem, das ich etwas übersehe aber ich versuch es noch mal zu erklären welche Sicht ich habe.
          • CSP = blockierung von Inlinecodes (<script>, onload="", <style>, style="", etc..) weil diese Durch XSS hinzu manipuliert werden können und dann ausgeführt werden.
          • XSS kann NICHT Dateien verändern die in die Seite eingebunden werden solange Inlinecode blockiert wird (da Funktionen etc. nun mal nicht überschrieben werden können wenn das Dokument sich aufbaut).
          • In einer User zu User Anwendung (Chat), könnte dann natürlich über eine als sicher geflagte Datei Schadcode eingebunden werden da diese nach meinen Wünschen Inline ausführen würde und den Userinput ins Dom packen würde (hier sehe ich dann aber auch den Entwickler in der Pflicht den Input zu validieren und ggf. die Chatfunktion so zu schreiben das diese Funktion keine Attribute/scripts hinzufügen kann, erwartet wird ggf. ja Text oder ein Link dementsprechent kann man das ja behandeln).

          Nun bisher habe ich nach wie vor mein nonce-Tokken in verwendung und bisher läuft ja auch alles wieder!
          Ich habe aber schon wieder ein Problem, ich wollte nun eine Datei mit $.getScript() nachladen, was dann wieder nicht klappt.

          Daher würde ich gern noch mal auf die Konfigurationsmöglichkeiten zurück kommen, hatte ja schon angefragt ob es ggf. möglich ist 2 Regeln zu definieren.
          Das Dateien von meinem definierten host zugelassen sind (nicht alle https urls eben nur meine z.B. https://domain.de/keine/uploads/bereich/*) und alle anderen Scripts/Dateien einen tokken benötigen.

          :: EDIT ::
          Sekunde habe da glaube ich was...

          Kommentar


          • #6
            Du arbeitest für SEDO ??
            https://www.domain.de/impressum/impressum.php

            Kommentar


            • #7
              Zitat von tomBuilder Beitrag anzeigen
              Und was ist das jetzt wieder? Selbst verständlich ist es als dummy zu verstehen -,-


              Naja gut ich habe meinen Header jetzt so gesetzt:
              Code:
              header("content-security-policy: default-src 'nonce-{$nonceTokken}' 'self' https: 'unsafe-eval' 'unsafe-inline' ;");
              im Grunde funktioniert es so wie ich es gedacht hatte, inline das sich direkt in HTML befindet also <script> & <style> benötigen einen nonce tokken ansonsten wird es geblockt.
              Attribute wie style und onclick/onload-Attribute werden eben falls geblock, daher ist die XSS Manipulation i.d.R. geblockt.

              Was mich jedoch wieder verwundert ist das Dateien aus beliebige Quellen eingebunden werden können, sollte 'self' nicht die origin als auch ip/port berücksichtigen und fremde Quellen blocken (diese hätten doch eig. ein nonce brauchen sollen)?
              Auf der anderen Seite ist das mit den Quellen garnicht mehr relevant da der Angreifer ja nciht dazu kommt Quellen hinzufügen zu können.
              Echt verzwicktes Thema.

              Kommentar


              • #8
                Zitat von Paykoman Beitrag anzeigen
                Und was ist das jetzt wieder? Selbst verständlich ist es als dummy zu verstehen -,-
                https://www.php.de/forum/webentwickl...95#post1500895

                wieso auch an Gepflogenheiten halten ?
                Könntest ja auch mal ...
                ach was, egal.

                Kommentar


                • #9
                  Wie war das mit der eigenen Haustüre?
                  Und was hat denn der verlinkte Thread mit meinem zu tun? Iwie nichts wie ich finde.
                  Und wieder läuft ein Thread ins Offtopic dank Sinnfreie Beiträge,
                  ach was, egal.

                  Kommentar


                  • #10
                    Post, verlinkte Post .....

                    Kommentar


                    • #11
                      Paykoman
                      Verwende einfach als Beispiel-Domain für dieses Forum immer example.com und keine Fantasiedomains.

                      Jetzt klarer.

                      Das Thema CSP sehe ich übrigens als erledigt an.

                      Kommentar

                      Lädt...
                      X