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.
Nun habe ich natürlich auch mal bei großen Seiten spioniert und fand folgendes:
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
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}'");
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:;");
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
Kommentar