¿El encabezado de la Política de seguridad de contenido proporciona una falsa sensación de seguridad si una página se sirve a través de HTTP sin cifrar?

  

Entonces le da al desarrollador una falsa sensación de seguridad ...

Tu comprensión del problema es correcta. Pero si esto le da al desarrollador una falsa sensación de seguridad, depende del conocimiento del desarrollador.

Un desarrollador con la formación adecuada debe saber que con un ataque MITM exitoso todo puede cambiarse en el tráfico. Esto no solo se limita a modificar el CSP o para la inyección de anuncios, sino que, de hecho, todo el contenido y el código de la página se pueden reemplazar por algo completamente diferente. Eso es, en lugar de buenos gatitos suaves, podría servir un poco de malware feo.

Tu entendimiento es correcto.

Cualquier cosa que no esté autenticada, encriptada y sin verificar su integridad es insegura. Parada completa Puede hacer que el atacante trabaje un poco más por las cosas, pero al final del día, el atacante puede interponerse entre el usuario y el servidor, y después de eso, todas las apuestas se desactivan.

Algo así como inyectar anuncios ya requiere estar en una posición MITM, así que sí, pueden eliminar sus encabezados de CSP. Un ataque masivo que no está personalizado en absoluto podría no ser lo suficientemente inteligente como para hacerlo todavía, pero no tomará mucho tiempo. La seguridad de extremo a extremo, como TLS, es la única manera de ir.

Para lo que vale la pena, si absolutamente debe usar conexiones no seguras y desea algunas protecciones en su autenticación (es decir, resistente a cualquier cosa excepto un MITM), eche un vistazo al resumen de autenticación. Nunca envía la contraseña real, o cualquier otra contraseña equivalente, a través del cable. También tiene al menos algo de resistencia a los ataques de repetición. También puede implementar algo en JS, utilizando criptografía asimétrica o SRP o similar. Eso ofrece la ventaja de poder transmitir los datos cifrados, aunque aún es vulnerable a que un atacante simplemente inyecte JS que roba los datos de texto sin formato tan pronto como su JS los desencripta.

Al final del día, sin embargo, eso es más esfuerzo que TLS, por una seguridad significativamente menor. Hay muy pocas situaciones en las que absolutamente no puedes usar TLS. Incluso los certificados autofirmados pueden importarse a un navegador o agregar una excepción para ese sitio, y luego el usuario estará seguro r de lo contrario, ya que el atacante deberá presentar su propio certificado ( lo que no tiene una excepción) y activará otra advertencia en el navegador.

Una buena pregunta. CSP controla el comportamiento del navegador DESPUÉS del contenido HTTP que ya llegó al navegador. Por ejemplo, desde qué imágenes de dominio se pueden cargar. Proporciona protección a nivel de aplicación. Por otro lado, los ataques Man-in-the-middle (MiTM) ocurren en el nivel de transporte, lo que permite al atacante cambiar el contenido, incluidos los encabezados HTTP ANTES que llegan al navegador.

Esto significa que la protección que proporciona el encabezado de CSP se puede negar si el contenido se sirve a través de HTTP simple. Sin embargo, los ataques MiTM requieren acceso especial a la ruta de comunicación entre el navegador y el servidor. Si este acceso no existe, por ejemplo porque el atacante es remoto, elimina los ataques MiTM de la ecuación. Sin embargo, todavía deja la aplicación abierta a la inyección de HTML, inyección de anuncios, inyección de guiones, etc. a través de la entrada de contenido generado por el usuario en la página a través de medios normales. Por lo tanto, CSP aún proporciona una capa de protección contra atacantes remotos.