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

        Lädt...
        X