JSON a través del script src =, ¿cómo se obtiene el objeto JS en la página deshonesta?

2

El otro día expliqué el ataque a una API de REST JSON (en la vida real, en el trabajo, no aquí), y descubrí que no entiendo parte del vector de ataque.

Lo siento, si esta es una pregunta bastante básica, no estoy bien con JavaScript.

Una forma común en que ocurre este ataque es que tiene una API en, digamos http://myfavouritebank.com/api/account/ que devuelve lo siguiente en una solicitud GET:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: ...

{ "customer name": "Bob",
  "account number": 123,
  "balance" : 123.56
}

Esto se devolverá cuando el usuario haya iniciado sesión (por ejemplo, utilizando una autenticación basada en cookies). Cuando el usuario no ha iniciado sesión, simplemente devuelve 403.

Luego, una página roja, contiene:

<script src="http://myfavouritebank.com/api/account/"/>

YlapáginamaliciosacargaráelobjetoJSON(dadoqueelusuarioestáactualmenteregistradoenelsitiowebdelbanco).

Perolapreguntaes

¿Cómohaceusolapáginaroguedeeseobjeto?Essolounobjetohuérfanodentrodelentornodescript,¿cómopuedeasignarseaunavariable,porejemplo?

Enotraspalabras,medicuentadequenuncaentendícómosedesarrollaesteataquedesdeaquí.

Hayvariasrespuestasgenialesen cómo prevenir CSRF en una API REAST que explica el envío de datos como JSON. Estoy tratando de entender cómo se construye la página rogue para recuperar los datos de un JSON de este tipo, con esta información puedo explicar mejor el ataque.

    
pregunta grochmal 03.09.2016 - 02:50
fuente

2 respuestas

2

Ver esta pregunta para más detalles, pero en resumen, manipular los prototipos de Objeto y Array puede permitirle leer el contenido de cualquier objeto a medida que se crea. Así que un atacante documenta los prototipos, document.write es la etiqueta del script, y aunque el objeto JSON no se guarda, la instrumentación del atacante recibe una notificación ya que cada propiedad está configurada y puede hacer una copia.

    
respondido por el Reid Rankin 03.09.2016 - 15:21
fuente
1

Un ataque CSRF generalmente implica inducir un cambio en la cuenta de las víctimas, bajo la custodia del sitio vulnerable, en lugar de extraer información sobre la cuenta de las víctimas. Es decir, el ataque se centra en los detalles de implementación del sitio vulnerable, en lugar de los detalles de datos de la víctima. No es necesario conocer o extraer información sobre la víctima.

Un sitio vulnerable tiene un punto final, como / transfer-funds /, que toma parámetros que indican qué cuenta a qué fondos deben transferirse, una cantidad a transferir, y realiza la transferencia desde la cuenta de usuarios autenticados. ¿Tener sentido?

Si la cuenta de los usuarios autenticados fue identificada por la cookie emitida por el sitio vulnerable, un atacante simplemente tuvo que construir un formulario en una página que controlara las POST al punto final vulnerable y luego inducir al usuario a hacer clic en un botón que dispara ENVIAR.

El navegador incluiría las cookies en la solicitud a pesar de que la solicitud se inició desde un sitio diferente y, al enviarse, los fondos se transferirían mágicamente y, lamentablemente, como si la víctima hubiera iniciado la solicitud.

Este envío de datos entre sitios con credenciales, con muchas variaciones en el escenario específico ingenuo anterior, se permitió de forma predeterminada durante mucho tiempo, y sigue siendo un patrón común en la web. Los ataques han tenido que ser específicamente bloqueados o defendidos, en lugar de un uso válido específicamente permitido.

Mucho ha cambiado desde que se identificó por primera vez el ataque para aumentar el nivel de seguridad de línea de base, pero a costa de aumentar dramáticamente la carga de configuración y la complejidad involucrada en mantener la seguridad en todos los escenarios conocidos.

    
respondido por el Jonah Benton 03.09.2016 - 03:25
fuente

Lea otras preguntas en las etiquetas