obtener ejemplos devolver datos con ajax json facebook

ejemplos - obtener datos ajax jquery



¿Qué hace una respuesta de llamada Ajax como ''para(;;);{json data} ''significa? (5)

Bueno, el for(;;); es un bucle infinito (puede usar la consola de JavaScript de Chrome para ejecutar ese código en una pestaña si así lo desea, y luego ver cómo el uso de la CPU en el administrador de tareas recorre el techo hasta que el navegador la destruye).

Entonces sospecho que tal vez se está poniendo ahí para frustrar a cualquiera que intente analizar la respuesta usando eval o cualquier otra técnica que ejecute los datos devueltos.

Para explicar con más detalle, solía ser bastante común analizar un poco de datos con formato JSON utilizando la función eval() JavaScript, haciendo algo como:

var parsedJson = eval(''('' + jsonString + '')'') ;

... esto se considera inseguro, sin embargo, como si, por alguna razón, sus datos con formato JSON contengan código ejecutable de JavaScript en lugar de (o además de) los datos con formato JSON, ese código será ejecutado por el eval() . Esto significa que si está hablando con un servidor que no es de confianza, o si alguien compromete un servidor de confianza, entonces puede ejecutar un código arbitrario en su página.

Debido a esto, el uso de cosas como eval() para analizar datos con formato JSON generalmente está mal visto, y el for(;;); La declaración en el Facebook JSON evitará que las personas analicen los datos de esa manera. Cualquiera que lo intente obtendrá un bucle infinito. Básicamente, es como si Facebook intentara imponer que las personas trabajen con su API de una manera que no las deje vulnerables a futuros ataques que intenten secuestrar la API de Facebook para usarla como un vector.

Posible duplicado:
¿Por qué la gente pone código como "lanzar 1; <no seas malo> ”y“ para (;;); ”delante de las respuestas de json?

Encontré este tipo de sintaxis que se usa en Facebook para las llamadas Ajax. Estoy confundido en el for (;;); parte en el comienzo de la respuesta. ¿Para qué se usa esto?

Esta es la llamada y respuesta:

GET http://0.131.channel.facebook.com/x/1476579705/51033089/false/p_1524926084=0

Respuesta:

for (;;);{"t":"continue"}


Esto parece un hack para prevenir un ataque CSRF . Hay formas específicas de cada navegador para enlazar con la creación de objetos, por lo que un sitio web malintencionado podría hacer eso primero y luego tener lo siguiente:

<script src="http://0.131.channel.facebook.com/x/1476579705/51033089/false/p_1524926084=0" />

Si no hubiera un bucle infinito antes de JSON, se crearía un objeto, ya que JSON puede ser eval() como javascript, y los enganches lo detectarían y rastrearían a los miembros del objeto.

Ahora, si visita ese sitio desde un navegador, mientras está conectado a Facebook, puede acceder a sus datos como si fuera usted, y luego enviarlo de vuelta a su propio servidor a través de, por ejemplo, una publicación de AJAX o javascript.


Facebook tiene un montón de desarrolladores que trabajan internamente en muchos proyectos, y es muy común que alguien cometa un pequeño error; ya sea algo tan simple y serio como no poder escapar de los datos insertados en una plantilla HTML o SQL o algo tan intrincado y sutil como usar eval (a veces ineficiente y posiblemente inseguro) o JSON.parse (una extensión compatible pero no implementada universalmente) de un "bien conocido" decodificador JSON, es importante descubrir formas de hacer cumplir fácilmente las mejores prácticas en esta población de desarrolladores.

Para hacer frente a este desafío, Facebook recientemente ha hecho "todo lo posible" con proyectos internos diseñados para aplicar con gracia estas mejores prácticas, y para ser sincero, la única explicación que realmente tiene sentido para este caso específico es precisamente eso: alguien decidió internamente que todo JSON el análisis debe pasar por una implementación única en su biblioteca central, y la mejor manera de hacer cumplir eso es que cada respuesta API se obtenga for(;;); Apuntado automáticamente en la parte delantera.

Al hacerlo, un desarrollador no puede ser "perezoso": notarán de inmediato si usan eval() , se preguntarán qué sucede y luego se darán cuenta de su error y utilizarán la API JSON aprobada.

Las otras respuestas que se proporcionan parecen caer en una de dos categorías:

  1. malentendido JSONP, o
  2. malentendido "secuestro JSON".

Aquellos en la primera categoría confían en la idea de que un atacante de alguna manera puede hacer una solicitud "utilizando JSONP" a una API que no la admite. JSONP es un protocolo que debe myFunction({"t":"continue"}) tanto en el servidor como en el cliente: requiere que el servidor devuelva algo parecido a myFunction({"t":"continue"}) manera que el resultado se pase a una función local. No puedes simplemente "usar JSONP" por accidente.

Aquellos en la segunda categoría están citando una vulnerabilidad muy real que se ha descrito permitiendo una falsificación de solicitud entre sitios a través de etiquetas a las API que no usan JSONP (como esta), permitiendo una forma de "secuestro JSON". Esto se hace cambiando el constructor Array / Object, que permite acceder a la información que se devuelve desde el servidor sin una función de ajuste.

Sin embargo, eso simplemente no es posible en este caso: la razón por la que funciona es que una matriz simple (un posible resultado de muchas API de JSON, como el famoso ejemplo de Gmail) es una declaración de expresión válida, que no es válida para una objeto desnudo

De hecho, la sintaxis para los objetos definidos por JSON (que incluye comillas alrededor de los nombres de los campos, como se ve en este ejemplo) entra en conflicto con la sintaxis de los bloques y, por lo tanto, no se puede usar en el nivel superior de un script.

js> {"t":"continue"} typein:2: SyntaxError: invalid label: typein:2: {"t":"continue"} typein:2: ....^

Para que este ejemplo sea explotable por medio de la reasignación del constructor del Objeto (), se requeriría que la API haya devuelto el objeto dentro de un conjunto de paréntesis, haciéndolo válido JavaScript (pero luego no JSON válido).

js> ({"t":"continue"}) [object Object]

Ahora, podría ser que esto for(;;); el truco de prefijo solo se muestra "accidentalmente" en este ejemplo, y de hecho lo devuelven otras API internas de Facebook que devuelven matrices; pero en este caso eso debería notarse, ya que esa sería la causa "real" de por qué for(;;); está apareciendo en este fragmento específico.


Llegué un poco tarde y TJ básicamente resolvió el misterio, pero pensé que compartiría un gran artículo sobre este tema en particular que tiene buenos ejemplos y brinda una visión más profunda de este mecanismo.

Estos bucles infinitos son una contramedida contra el "secuestro de Javascript", un tipo de ataque que llamó la atención del público con un ataque a Gmail que fue publicado por Jeremiah Grossman .

La idea es tan simple como hermosa: muchos usuarios tienden a iniciar sesión permanentemente en Gmail o Facebook. Entonces, lo que hace es configurar un sitio y, en el Javascript de su sitio malicioso, anula el objeto o el constructor de matriz:

function Object() { //Make an Ajax request to your malicious site exposing the object data }

luego incluye una etiqueta <script> en ese sitio, como

<script src="http://www.example.com/object.json"></script>

Y finalmente, puede leer todo sobre los objetos JSON en los registros de su servidor malicioso.

Según lo prometido, el enlace al paper .


Sospecho que la razón principal es que hay control. Te obliga a recuperar los datos a través de Ajax, no a través de JSON-P o similar (que usa etiquetas de script y, por lo tanto, fallaría porque el bucle es infinito) y, por lo tanto, garantiza que se aplique la Política del mismo origen . Esto les permite controlar qué documentos pueden emitir llamadas a la API, específicamente, solo los documentos que tienen el mismo origen que la API, o aquellos a los que Facebook otorga acceso específicamente a través de CORS (en los navegadores que admiten CORS). Por lo tanto, debe solicitar los datos a través de un mecanismo en el que el navegador impondrá el SOP, y deberá conocer ese prefacio y eliminarlo antes de deserializar los datos.

Entonces sí, se trata de controlar (útil) el acceso a esos datos.