Sin embargo, todavía sería posible alterar los datos en la pantalla en
formas inesperadas, y posible crear una estafa de Phishing convincente por
proporcionando un enlace a otro sitio web.
¿Esto es correcto o los enlaces externos también son prohibibles?
Sí, es preciso con una advertencia: la gente en su sitio ejecuta navegadores modernos. Por este motivo exacto, mi equipo considera que XSS sin inyección de contenido real (por ejemplo, la inyección en un contexto de atributo de etiqueta no citado) tiene una prioridad más baja que un error de inyección de contenido en sí debido a la CSP. Tenemos la suerte de no tener prácticamente usuarios en los navegadores que no admitan algún tipo de CSP fuerte .
¿Cuál es el alcance de un posible ataque XSS con la presencia de un
¿CSP apretado?
Perdóneme aquí si esto suena a jabón, pero su pregunta no define "CSP estricto", así que permítame explicarme algunas cosas que muchos pasan por alto.
En aras del argumento, digamos que esta es una política propuesta (se agregan saltos de línea para mayor claridad, esto no es un encabezado válido):
Content-Security-Policy:
default-src 'self';
img-src https: data:;
connect-src paypal.com api.example.com;
script-src 'self' ajax.googleapis.com;
style-src 'self' 'unsafe-inline'
Nota : eliminar unsafe-inline de style-src no es práctico hoy.
Esa es una política bastante buena con algunos defectos obvios y no tan obvios, pero no está permitido el script en línea. Hay muchas más advertencias a considerar con CSP, no se trata solo de deshabilitar el script eval y inline (sí se incluyen los controladores de eventos javascript: y on* ).
El bloqueo de terceros para limitar XSS en realidad
- Los "Bypasses de CSP" son una cosa. H5SC Minichallenge 3: "Sh * t, es
¡CSP! ". Permitimos un cdn de terceros que abre XSS.
-
CSP: omitiendo la acción de formulario reflejada
XSS
form-action no está cubierto por default-src 'self' ya que no es una "directiva de búsqueda".
- Exfiltración de datos a través de etiquetas de contenido inyectado (por ejemplo,
img , style , etc ) donde las políticas tienden a ser más relajadas. Permitimos exfil a través de la etiqueta de imagen.
Tantos otros vectores aún existen
El viaje de CSP de GitHub contiene muchos puntos sobre cómo se ajustó la política para evitar ciertos ataques.
Todo lo de abajo se puede abusar con la política propuesta.
- Eliminando
'self' de script-src para evitar XSS a través de JSONP
- Extracción de tokens CSRF a través de las etiquetas
img y form
- Mover los archivos flash alojados a un origen diferente en lugar de
'self' porque flash arruina todo.
- Usar políticas dinámicas para evitar el uso inesperado de API que solo deben usarse desde un conjunto específico de páginas.
- Uso limitado de
'self' para frame-src / child-src
- Abusando de la etiqueta
base .
A veces, el CSP simplemente no se aplica.
Es posible eludir la CSP por completo. Consulte rastreo del tipo de contenido PDF para ver un ejemplo donde los datos controlados por el usuario en una página realmente pueden desordenar las cosas.
Literalmente, no hay nada que podamos hacer al respecto desde la perspectiva de CSP.
Y a veces, internet te hace llorar.
Consulte Robando el pastel sin tocar el alféizar donde CSS se puede usar para robar Y exfiltrar datos en una página sin javascript.
Como eliminar 'unsafe-inline' no es práctico, este ataque es posible. Sin embargo, este ataque es difícil de ejecutar.