La gente ama las películas de “atraco”. Estamos fascinados por la trama de un crimen sofisticado contra un objetivo poderoso por parte de tomadores de riesgos creativos que reciben la misma patada al vencer al sistema que al obtener el botín. Esta es la forma de abordar la seguridad cibernética desde la cima, desde la perspectiva mental (e incluso emocional) del hacker del “sombrero negro”. ¿Qué está tratando de lograr en los términos más generales y cómo lo haría, también en los términos más generales? Ponte dentro de la cabeza de tu enemigo desde el minuto uno y diviértete con él. De ninguna otra manera, el laberinto de amenazas superpuestas y alternativas tecnológicas, confundido por la jerga más oscurantista imaginable, comenzará a tener sentido para usted, y puede comenzar a compartir la creatividad intelectual del juego. Porque este es, de hecho, el juego del siglo XXI.
El tipo específico de pirata informático con el que el desarrollador web debe preocuparse es, sobre todo, alguien que quiere que su JavaScript se ejecute dentro de su sitio web / aplicación web , aunque el objetivo final es obtener acceso a los datos del servidor. Datos del usuario, como contraseñas o información de tarjetas de crédito, u otros datos confidenciales accesibles con sus credenciales. Una vez que empiezas a pensar como un hacker en estos términos más amplios, estás preparado para darle sentido a las cosas.
La mayor parte de la piratería de sitios web / aplicaciones web implica explotar realidades sorprendentes sobre cómo funciona un navegador y cómo se realizan las solicitudes http que probablemente ni siquiera se les ocurriría a un desarrollador experimentado, y puede ser irritantemente difícil de asimilar incluso cuando se explican. Esto se debe a que un desarrollador piensa de manera inherente en las tecnologías relevantes (HTML, JavaScript, HTTP, etc.) tal como fueron diseñadas para ser utilizadas. Pero vayamos a los casos.
- ¿Se puede crear un sitio web dinámico utilizando solo HTML, CSS y JavaScript?
- ¿Cuáles son algunos buenos libros para aprender HTML, CSS, PHP, MySQL y JavaScript con ejercicios prácticos para que pueda practicar lo que aprendo en cada capítulo?
- ¿Hay algún tutorial de desarrollo web que combine todos los aspectos centrales del desarrollo web?
- ¿Hay una herramienta disponible que nos diga (lego) si un sitio web está disponible para respondernos o no? ¿O puedo escribir un guión simple para eso?
- ¿Existe algún estándar profesional y tarifario para desarrolladores y programadores de sitios web ya que estoy agotado en mi búsqueda de uno confiable?
En el caso típico relevante para el desarrollador web, un malvado busca las credenciales de un usuario existente para acceder a una base de datos del lado del servidor a través de un navegador, y utilizará JavaScript en el navegador de ese usuario para llegar allí. Pero, ¿cómo puede alguien ejecutar su JavaScript en su aplicación? ¿Cómo es posible inyectar JavaScript en el navegador del usuario de un sitio web o aplicación web de fuentes que el desarrollador no proporcionó explícitamente?
Bueno, la forma ideal sería plantar la solicitud para descargar el malvado JavaScript en el contenido de la base de datos que el usuario necesariamente está descargando. Por ejemplo, como badguy, es posible que desee una solicitud para que aparezca el código maligno en los comentarios extraídos de una base de datos, comentarios que se muestran para cada usuario que solicita la página adecuada (como Quora responde aquí, para dar una instancia pertinente). Esto podría lograrse mediante la publicación de un comentario que incluya una etiqueta de script que apunte al malvado JavaScript, porque una etiqueta de script con un atributo “src” es simplemente un medio de generar una solicitud HTTP GET a la fuente indicada. Si esta etiqueta de script ingresa a la base de datos como parte del texto del comentario, el comentario llevará la etiqueta de script a cada página que muestre ese comentario.
Y aquí está el truco que un desarrollador no tiene razón para pensar. El DOM no mostrará la etiqueta del script (con su atributo “src”). Sin embargo, el script se descargará y tratará como cualquier JavaScript legítimo que el desarrollador esté buscando incluir a través de etiquetas de script, como bibliotecas de proveedores. En otras palabras, será descargado y luego ejecutado por el tiempo de ejecución de JavaScript a pesar de que la etiqueta del script se anidó peculiarmente dentro de las etiquetas de “visualización” HTML normales, como
o
. (Tenga en cuenta que ni siquiera intenté poner una etiqueta de script en esta respuesta de Quora. Quora sabe lo que están haciendo).
El malvado JavaScript puede obtener la autorización del usuario de una cookie en la memoria del navegador y enviarla al servidor de badguy en una solicitud HTTP POST, para que se registre en un archivo o se almacene en una base de datos. A partir de ahí, las carreras son libres, porque una vez que puede iniciar sesión como usuario, nuestro malvado puede hacer todo lo que el usuario podría haber hecho.
Este enfoque denominado “persistente” es ideal porque el ataque se aplica de manera transparente a todos los que usan el sitio web / aplicación web, sin requerir ninguna acción especial por parte del usuario. Y sigue funcionando hasta que se descubre el código malicioso en la base de datos y se elimina.
Una forma menos ideal, pero generalmente más viable de introducir JavaScript malicioso en el navegador, implica engañar a un usuario individual para que realice alguna acción que parezca inocua . Aquí tienes que seguir la pelota que rebota un poco más cuidadosamente porque hay “ingeniería social” (interacción social) involucrada en esto, así como en la codificación. Más como un atraco al cine.
Las búsquedas en el sitio web generalmente muestran la cadena de búsqueda enviada por el usuario cuando el servidor devuelve los resultados. Como aspirantes a ser malos, ya hemos aprendido que si una etiqueta de script de alguna manera ingresa al DOM del usuario, como con los comentarios anteriores, no se mostrará, pero solicitará el JavaScript especificado. Podemos probar esto escribiendo una etiqueta de script que apunte a un archivo .js en el cuadro de búsqueda, y cuando la búsqueda regrese sin éxito, la pantalla debería decir algo como “has buscado …” sin mostrar el texto de la etiqueta de script. Pero aún deberíamos poder determinar si nuestro malvado JavaScript fue descargado y ejecutado, tal vez por una simple declaración de registro impresa en la consola del navegador.
Así que ahora nos ponemos furtivos y enviamos a los usuarios del sitio web / aplicación web de destino un enlace atractivo en un mensaje de correo electrónico, invitándolos a mirar algún contenido específico en este sitio, un sitio que ya conocen y en el que ya son usuarios registrados. El enlace contiene un parámetro de consulta de búsqueda que incluye la etiqueta del script que apunta al malvado JavaScript, pero es probable que el usuario promedio no se alarme por esto, si es que lo nota. Una vez que hace clic en el enlace, el resultado es el mismo que si el usuario visitara el sitio y escribiera la etiqueta del script en la entrada de búsqueda (tal como lo hicimos en nuestra prueba), lo que desencadenó el proceso de recuperar esa etiqueta del script de forma invisible en el página de respuesta de búsqueda. Sin embargo, debido a que la etiqueta del script, aunque no se procesa, entra en el DOM, el malvado JavaScript se descarga, ejecuta y, como antes, la información de autorización del usuario (quizás una ID de sesión) se envía al servidor del badguy en una solicitud HTTP POST. Una vez más, se va a las carreras.
A diferencia del enfoque “persistente” anterior, donde el enlace al código JavaScript se ha inyectado en la base de datos del lado del servidor, este último enfoque se “refleja”. Se engañó al usuario para que, sin saberlo, enviara las etiquetas de script al servidor, que lo “reflejó” (lo devolvió) para que se mostrara en la página de resultados de búsqueda. La característica común es que, en ambos casos, nosotros, los malos, hemos hecho que el usuario descargue etiquetas de script para el malvado JavaScript desde el servidor de confianza que entrega el sitio web / aplicación web en sí.
Todo esto es bastante inteligente, y si los desarrolladores no lo anticipan y lo contrarrestan (por ejemplo, asegurándose de que las etiquetas de script estén identificadas y deshabilitadas según sea necesario) resuelve la pregunta inicialmente desconcertante de cómo JavaScript no deseado podría entrar en su aplicación web . (Se llama scripting entre sitios o XSS).
Nos detendremos aquí, aunque apenas hayamos arañado la superficie. La conclusión clave es que los piratas informáticos han descubierto una forma de obtener JavaScript malicioso en el navegador al hacer que el sitio web / aplicación web lo solicite. Esto implica comprender que las etiquetas de script se pueden ejecutar utilizando cualquier truco para ingresarlas al DOM, aunque como desarrolladores nunca se nos ocurrirá colocar etiquetas de script en el contenido destinado a la visualización . No están destinados a la visualización, sino a poner código en la memoria de JavaScript, y por lo tanto, toda la idea suena absurda desde el punto de vista del desarrollador y no se adhiere a su cerebro. Pero es una realidad y, por lo tanto, puede explotarse si se piensa desde el otro lado del espejo.
