joself
¿Es posible configurar Content-Security-Policy para no bloquear nada en absoluto? Estoy impartiendo una clase de seguridad informática y nuestro proyecto de piratería web tiene problemas en las versiones más nuevas de Chrome porque, sin ningún encabezado CSP, bloquea automáticamente ciertos ataques XSS.
lluvia
Para las personas que aún quieren publicaciones aún más permisivas, porque las otras respuestas simplemente no fueron lo suficientemente permisivas, y deben trabajar con Google Chrome para lo cual * simplemente no es suficiente:
default-src * data: blob: filesystem: about: ws: wss: 'unsafe-inline' 'unsafe-eval' 'unsafe-dynamic';
script-src * data: blob: 'unsafe-inline' 'unsafe-eval';
connect-src * data: blob: 'unsafe-inline';
img-src * data: blob: 'unsafe-inline';
frame-src * data: blob: ;
style-src * data: blob: 'unsafe-inline';
font-src * data: blob: 'unsafe-inline';
frame-ancestors * data: blob: 'unsafe-inline';
-
Para una política que permita en línea, pero no desde cualquier host, los comodines ( * ) podrían cambiarse a “self”.
-Rob Breidecker
15 de enero de 2020 a las 0:01
-
Chrome ahora dice que no sabe y lo ignorará
'unsafe-dynamic'–Anatol Bivol
15 de abril de 2021 a las 14:16
-
@AnatoliiBivol interesante, supongo que puedes eliminarlo para evitar advertencias, si Chrome es lo único que te importa
– Rainb
15/04/2021 a las 18:33
-
También necesitaba agregar frame-ancestros desarrollador.mozilla.org/en-US/docs/Web/HTTP/Headers/…
–Jonathan Parker
18 de abril de 2021 a las 12:19
-
@AhmedEl-Atab al momento de escribir, Chrome requería definir cada entrada explícitamente.
– Rainb
28 de diciembre de 2021 a las 17:56
cerologiko
No es seguro en absoluto, pero como punto de partida el real permitir todas las políticas es:
default-src * 'unsafe-inline' 'unsafe-eval'; script-src * 'unsafe-inline' 'unsafe-eval'; connect-src * 'unsafe-inline'; img-src * data: blob: 'unsafe-inline'; frame-src *; style-src * 'unsafe-inline';
Ver: https://content-security-policy.com/ y esta guía de migración de CSP.
-
Blob y datos perdidos, ejemplo: default-src * data: blob: ‘unsafe-inline’ ‘unsafe-eval’;
– albahaca
15 de julio de 2019 a las 9:06
-
Te perdiste font-src: * ‘unsafe-inline’;
–Jonathan Parker
18 de abril de 2021 a las 12:06
-
Genial. ahorra mi tiempo
– Dat Ho
11 de junio de 2021 a las 3:32
La mejor manera sería no aplicar ninguna política.
Pero para responder a su pregunta, una “política de permitir todo” probablemente sería:
default-src * 'unsafe-inline' 'unsafe-eval' data: blob:;
Nota: no probado
-
Desafortunadamente, sin ninguna política implementada, Chrome agrega proactivamente algunas protecciones XSS propias, por lo que no tener nada es peor. ¡Pero gracias!
– joshlf
14/03/2016 a las 20:36
Aquí está el código htaccess para permitir todo en CSP
Header add Content-Security-Policy "default-src * data: blob: filesystem: about: ws: wss: 'unsafe-inline' 'unsafe-eval' 'unsafe-dynamic'; script-src * data: blob: 'unsafe-inline' 'unsafe-eval'; connect-src * data: blob: 'unsafe-inline'; img-src * data: blob: 'unsafe-inline'; frame-src * data: blob: ; style-src * data: blob: 'unsafe-inline'; font-src * data: blob: 'unsafe-inline';"
DESCARGO DE RESPONSABILIDAD/ADVERTENCIA: Considere escribir un CSP adecuado. La siguiente configuración permite cualquier conexión y no es proporcionar ningún beneficio de seguridad. El encabezado Content-Security-Policy-Report-Only lo ayuda a archivar el objetivo de un CSP adecuado en dos pasos/sin bloqueo.
Dado que el comportamiento predeterminado es que cada política recurra a default-src (según MDN), el encabezado CSP más simple que permite cualquier cosa debería ser este:
default-src * data: mediastream: blob: filesystem: about: ws: wss: 'unsafe-eval' 'wasm-unsafe-eval' 'unsafe-inline';
la explicacion por que * no coincide con “todo” es que el asterisco solo permite todas las fuentes de host, pero, por ejemplo, las fuentes de esquema, en línea o eval no son fuentes de host. Por lo tanto, este tipo de fuentes deben especificarse explícitamente.