¿Pueden los parches XHR evitar los efectos secundarios de XSS?

Navega tus respuestas
9

XSS & Aplicaciones de una sola página

Estoy investigando sobre seguridad web, y he visto que autenticación basada en token es buena para la prevención de CSRF, las arquitecturas de sistemas distribuidas y el rendimiento de procesamiento.

Pero otro problema es XSS. No específicamente hablando de la inyección en sí, sino de las bibliotecas. Con las aplicaciones de una sola página, los desarrolladores normalmente incluyen cientos de módulos diferentes en su código, que luego podrían ejecutarse de manera maliciosa cuando la aplicación está en producción.

Aplicación de parches XMLHttpRequest

Así que tuve la idea de parchear la propiedad XMLHttpRequest y tomar el control de la función original "código nativo", evitando que el código de terceros realice solicitudes ajax. 

(function () {
  // my code
  let XHR = window.XMLHttpRequest
  window.XMLHttpRequest = null
})()

// load third-party code after...

Probé esto en la consola con facebook y youtube ... todo su contenido cargado de ajax deja de funcionar.

Ejemplo malicioso

Un ejemplo de comportamiento malicioso no detectado es un código que solo se ejecuta en producción al verificar si la ubicación de window es algo así como "app.x.com", por lo que el desarrollador no se da cuenta de las solicitudes de ajax durante el desarrollo.

Al parchar la propiedad XMLHttpRequest se evitaría esto, y teniendo en cuenta que se tomaron todas las demás medidas para evitar XSS (desinfección), esto cerraría la brecha final y le permitiría tomar control de las solicitudes de red, evitando que el código malicioso robe la autenticación fichas.

Duda final

¿Hay alguna advertencia a este enfoque? (seguridad)

    
pregunta Hadrian 05.06.2016 - 06:49
fuente

2 respuestas

8
  

¿Hay alguna advertencia a este enfoque? (seguridad)

Sí, no es muy exhaustivo, puede obtener una nueva instancia del constructor de un nuevo objeto de ventana en su lugar: 

XMLHttpRequest = null;

var iframe = document.createElement('iframe');
iframe.style.display = 'none'; // optional
document.body.appendChild(iframe);
var XHR = iframe.contentWindow.XMLHttpRequest;
console.log(new XHR());

Tendrías que sobrescribir mucho más cosas para asegurarte de que no se pueda acceder a XMLHttpRequest , esa es solo una forma de hacerlo.

Para la protección XSS, solo use una Política de seguridad de contenido y solo use bibliotecas de confianza de fuentes confiables.

    
respondido por el Alexander O'Mara 05.06.2016 - 08:24
fuente
2

Incluso si esto funcionara y usted pudiera bloquear JavaScript para que no realice las solicitudes de XMLHttpRequests, lo que, como lo muestra @Alexander, no es el caso (ActiveXObject sería otra alternativa), realmente no limita los peligros de XSS.

Un atacante todavía tiene varias posibilidades:

  • Defacement
  • Phishing : por ejemplo, agregue un formulario de inicio de sesión que envíe los datos ingresados a un servidor controlado por un atacante
  • Extracción de datos : si bien un atacante no puede enviar los datos adquiridos a través de XMLHttpRequest, puede forzar una redirección a través de la actualización de etiquetas meta y enviar los datos de esa manera.
  • CSRF : el token se puede adquirir como se describe anteriormente, luego se puede crear un formulario y enviarlo a través de JavaScript.
  • Solicitudes de red : el ejemplo de formulario de arriba también muestra cómo se pueden realizar las solicitudes de red sin utilizar XMLHttpRequests.

Realmente no hay una buena manera de evitar todos estos puntos (al menos, deberías evitar cualquier cambio en el DOM, lo que no creo que sea posible).

Debe confiar en las bibliotecas de JavaScript de terceros que utiliza.

Si no confía en el proveedor, debe reproducir la funcionalidad usted mismo.

    
respondido por el tim 05.06.2016 - 10:12
fuente

Lea otras preguntas en las etiquetas

¿Qué factores debe tener en cuenta al decidir si los usuarios deben ser informados de una prueba de penetración? ¿Vale la pena aumentar / entrop / random entropía en el software?