Respuestas JSON puede ser explotado mediante la invalidación de la Matriz de constructores o si hostiles de los valores de cadena de JavaScript-escapó.

Vamos a suponer que ambos vectores son abordados en forma normal. Google famoso trampas de respuesta JSON abastecimiento directo con el prefijo de todos JSON con algo como:

throw 1; < don't be evil' >

Y, a continuación, el resto de las JSON de la siguiente manera. Así que el Dr. Malo, no puede, utilizando el tipo de aprovechamiento que se discuten aquí http://sla.ckers.org/forum/read.php?2,25788 conseguir tu cookie (suponiendo que usted ha iniciado sesión) por poner lo siguiente en su sitio:

<script src="http://yourbank.com/accountStatus.json"> 

Como para la cadena de escapar de las reglas, y si estamos usando comillas dobles, necesitamos agregar un prefijo a cada uno de ellos con una barra diagonal inversa y cada barra diagonal inversa con otra barra diagonal inversa etc.

Pero mi pregunta es, ¿qué pasa si usted está haciendo todo esto?

Burpsuite (automatizado herramienta de seguridad) detecta incrustado XSS intentos que se devuelven unHTML-escaparon en una respuesta JSON y se reporta como una vulnerabilidad de XSS. Tengo un informe de que mi aplicación contiene vulnerabilidades de este tipo, pero yo no estoy convencido. Yo lo he probado y no puedo hacer un exploit de trabajo.

Así que no creo que esto es correcto, pero te pido que StackOverflow de la comunidad, a pesar de.

Hay un caso específico, el de IE tipo MIME oler que creo que podría resultar en un exploit. Después de todo, es decir, 7 todavía tenía la «función» que las etiquetas de script incrustado en la imagen de los comentarios fueron ejecutados independientemente del encabezado de Tipo de Contenido. También vamos a salir de tan claramente estúpido comportamiento de un lado a primera.

Seguramente el JSON que sería analizado por los nativos de JavaScript parser (de la Ventana.JSON en Firefox) o por un eval() como por el viejo defecto de jQuery comportamiento. En ninguno de los casos sería el siguiente resultado de la expresión en la alerta de que se está ejecutando:

{"myJSON": "legit", "someParam": "12345<script>alert(1)</script>"}

Estoy en lo cierto o estoy equivocado?

4 Comentarios

  1. 26

    Esta potencial vulnerabilidad de xss puede evitarse mediante el uso de la correcta Content-Type. Basado en RFC-4627 todas las respuestas JSON debe utilizar el application/json tipo. El código siguiente es no vulnerables a xss, anímate a probarlo:

    <?php
    header('Content-type: application/json'); 
    header("x-content-type-options: nosniff");
    print $_GET['json'];
    ?>

    La nosniff encabezado se utiliza para deshabilitar contenido-sniffing en versiones antiguas de Internet Explorer. Otra variante es la siguiente:

    <?php
    header("Content-Type: application/json");
    header("x-content-type-options: nosniff");
    print('{"someKey":"<body onload=alert(\'alert(/ThisIsNotXSS/)\')>"}');
    ?>

    cuando el código de arriba es visualizada por un navegador, el usuario se le pedirá que descargue un archivo JSON, el JavaScript no fue ejecutado en las modernas versiones de Chrome, FireFox e Internet Explorer. Este sería un RFC violación.

    Si puedes usar JavaScript para eval() el JSON arriba o escribir la respuesta a la página, a continuación, se convierte en Basadas en DOM XSS. Basadas en DOM XSS con el parche en el cliente desinfectar el JSON antes de actuar en este tipo de datos.

    • OK, así que supongo que me podría haber hecho más claro, pero la respuesta JSON que estoy hablando es definido por la presencia de el encabezado Content-Type con el valor «application/json». Así que parece que usted está confirmando que no hay explotar. No puede el código puede ser explotado por el abastecimiento directo en un ambiente hostil, de dominio, que es el uso de la etiqueta de script y parametising la fuente de incluir código que se ejecutará en el contexto del dominio es de? En el caso de que el dominio de las cookies podrían ser accesibles y pueden ser capturados por la llamada a la página del documento.escribir. A la derecha?
    • Mountford la inyección de JavaScript no se ejecuta porque el servidor está diciendo que el navegador no demasiado. Piensa en ello de esta manera, lo que si había JavaScript en una .exe? Esta podría conducir Basadas en Dom XSS, pero podrían hacerlo otros diseños. Basadas en Dom xss se ejecuta con la misma política que se ejecuta desde. La única manera que esto puede ser un problema para usted es si usted está eval()ing el código en tu propio sitio.
    • A mi entender, JSON se eval()’d muy comúnmente en el pasado, al menos por defecto en jQuery (como he dicho). Sin embargo, estoy interesado no en inyección de JavaScript, pero en la inyección de código HTML en JSON que conduce a la ejecución de JavaScript. Puede usted comentar sobre eso? También, como he dicho, es decir, los últimos como v7 me han confirmado, puede IGNORAR el encabezado de Tipo de Contenido bajo ciertas circunstancias. Sí, este es un error en IE pero Microsoft argumentó no (independientemente de la RFC) y en la final, por seguridad ,solo importa lo que los navegadores no lo que la especificación dice.
    • Mountford El término «js inyección» es muy malo y no me lo han utilizado, siempre XSS y ese es el término correcto. Es posible eval() código y han js pegados como los datos, por ejemplo var test='<script>alert(/not_xss/)</script>', si el atacante puede inyectar una sola cita, a continuación, él puede salir y ejecutar javascript. Si IE es la ejecución de JavaScript .los archivos exe u otros en application data, a continuación, se les debe expedir un número CVE. Si usted puede probar este comportamiento voy a ayudarle a presentar una Bugtraq post.
    • Gracias por que. Para el registro, creo inyección de javascript es un excelente término a desambiguar por un lado el uso de la comilla simple para un escape en situaciones como esta (que no estén específicamente excluidos de mi pregunta original) y por otro lado, la inserción de etiquetas html para entrar en un bloque de secuencia de comandos.
    • La torre, yo no lo he leído en detalle todavía, así que me perdone si he leído mal o soy simplemente es gruesa, pero yo creo que esta entrada del blog, proporcionada por @anon a continuación, se describe un ataque por el que Internet Explorer puede ser hecho para tratar de respuestas con application/json tipo de Contenido como si estuvieran en el HTML, permitiendo de XSS reflejado en los ataques a pesar de la cabecera. Si yo estoy entendiendo todo esto correctamente, significa que su respuesta es incorrecta. Tal vez le gustaría echar un vistazo a esto?
    • Amery Sí, usted se equivoca. JSON análisis no entran en juego, el navegador, no se evaluará el código ejecutable en el JSON cuerpo para cualquier cross-site request. Pero no tome mi palabra para ella, esto es muy fácil de probar y de hecho me han facilitado el código fuente para realizar este test! No probar su propia seguridad es la fuente de todas las vulnerabilidades.
    • Usted ha desestimado el post demasiado temprano. El poco acerca de eval fue en una intro pasaje anteriormente vulnerabilidades conocidas, y, obviamente, sólo se aplica si la respuesta JSON que se está analizando en algún lugar de usar eval. Si sigues leyendo, la real vulnerabilidad que está siendo descrito se inicia después de la línea que dice hemos descubierto una manera para representar respuestas JSON en IE directa de navegación. he publicado mi respuesta describir a este (a pesar de la dolorosa nivel de detalle es para el bien de las personas que no están familiarizadas con XSS – sé que no es necesario para usted!)

  2. 7

    Burpsuite (automatizado herramienta de seguridad) detecta incrustado XSS intentos
    que se devuelven unHTML-escaparon en una respuesta JSON y se informa de que
    como una vulnerabilidad de XSS.

    Tal vez se trata de evitar la vulnerabilidad descrita en el la regla 3.1 de OWASP XSS Hoja de Trucos.

    Dan el siguiente ejemplo de código vulnerable:

    <script>
        var initData = <%= data.to_json %>;
    </script>

    Incluso si las comillas dobles, barras y las nuevas líneas son escapado apropiadamente, usted puede salir de JSON si es incrustado en HTML:

    <script>
        var initData = {"foo":"</script><script>alert('XSS')</script>"};
    </script>

    jsFiddle.

    to_json() función puede evitar este problema mediante el prefijo de cada barra con una barra diagonal inversa. Si JSON se utiliza en el atributo HTML, toda la cadena JSON debe ser HTML-se escapó. Si se usa en un href="javascript:" atributo, debe ser la URL de escape.

    • Esta es una muy básica error en el php (supongo que es php). Usted no debe en línea manchada de datos en HTML HTML sin escape. Pero como he indicado en mi pregunta, yo no estoy haciendo esto. Mientras que es posible que Burpsuite puede estar tratando de evitar este problema, el enfoque es equivocado.
    • ¿Qué enfoque es equivocado? – No te entiendo. Como para «no debe en línea manchada de datos en HTML sin HTML escapar.», adivinen qué, usted no debería en línea incluso sin ceder datos sin escapar.
    • La cuestión de lo que usted puede en línea está completamente fuera del alcance de esta pregunta. Usted puede, sin duda, en línea libre de corrupción de datos si los datos se compone de HTML. De hecho, si tienes HTML y en línea CON el escape, usted terminará para arriba con doble escapó de salida, que, aunque no es un fallo de seguridad, es un error. El enfoque que yo describo como equivocada, es el intento de «evitar la vulnerabilidad descrita en la regla 3.1 de OWASP XSS Hoja de Trucos» que sugieren como Burpsuite la intención. Si su sugerencia acerca de Burpsuite es cierto, entonces están equivocados.
  3. 0

    Si nos limitamos a nuestro alcance para IE (todas las versiones), suponga que usted está ejecutando un sitio web basado en PHP o ASP.NET y omitir la IE anti-filtro xss, entonces usted está equivocado: los usuarios son vulnerables. La configuración de ‘Content-type: application/json» no ayuda, tampoco.

    Esto es debido a que (como usted menciona), es decir el contenido de la detección de comportamiento, que va más allá de olfateo para las etiquetas HTML en el cuerpo de la respuesta para incluir el análisis de URI.

    Este blog lo explica muy bien:

    http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html

    • OK, pero el URI es todavía totalmente bajo el control del servidor.
    • Veo que el examen del comportamiento de internet explorer crea múltiples vectores de ataque posible, pero la modificación de la ruta de acceso de información no es posible en mi aplicación. También, por fin puedo poner este oler problema para descansar, ya que versión de IE 8+ se apagará MIME oler el uso de este: X-Content-Type-Opciones: nosniff Para alguien que esta leyendo esto, creo que he establecido que JSON puede llevar de forma segura los valores contaminadas entrada del usuario mientras se JSON valor codificado y, por supuesto, nunca debe ser conectado a un DOM de HTML sin el lado del cliente de codificación html.
    • Para aclarar, me refiero a que no hay oportunidad para los atacantes que elegir su propio camino info. Esto significa que mi aplicación no tiene ninguna vulnerabilidad en esa categoría. También, en mi pregunta original, me dijo que me quería poner a un lado la cuestión de la IE del examen de MIME, porque quería concentrarse en otras categorías (tenía una solución para IE del examen de MIME ya).
  4. 0

    Para el registro, aunque he aceptado una respuesta, para el exacto literal de la pregunta que yo estoy pidiendo, yo tenía razón y no había vulnerabilidad debido a la presencia de no-HTML-escapó sin embargo, correctamente JSON-escape HTML dentro de JSON valores. Podría ser un bug ahí si que el valor se inserta en el DOM sin el lado del cliente escapar pero Burpsuite tiene pocas posibilidades de saber si eso iba a suceder con sólo mirar el tráfico de la red.

    En el caso general de la determinación de lo que es una vulnerabilidad de seguridad en estas circunstancias, es interesante reconocer que, aunque no se puede sentir como el buen diseño, la respuesta del contenido de un JSON valor podría ser legítimamente sabe que ciertamente no contienen ninguna entrada de usuario y estar destinado a ser renderizado de HTML, que se puede insertar en el árbol DOM, sin escape. Para escapar de ella sería una (no de seguridad) error como mencioné en otro comentario.

Dejar respuesta

Please enter your comment!
Please enter your name here