En mi lugar de trabajo, muchas personas creen que AJAX es fundamentalmente inseguro. Tengo la impresión de que AJAX es exactamente tan seguro como cualquier otra carga de página, depende de cómo codifique la llamada / página.
¿Existe un error de seguridad fundamental en AJAX? ¿En qué se diferencia la superficie de ataque de la clase AJAX (independientemente de XML o JSON) de una aplicación web sincrónica estándar?
Respuesta corta: Usted es correcto, depende de cómo codifique la página.
Respuesta un poco más larga:
No hay nada intrínsecamente inseguro en AJAX, en su mayor parte es susceptible a la mayoría de las mismas amenazas y ataques que las páginas web normales.
Sin embargo, también hay algunos ataques que son específicos de AJAX, pero nuevamente depende de cómo se codifique. Pero eso no lo hace "fundamentally insecure" .
Sin embargo, a menudo hay un problema diferente y sutil en el juego: mientras que (la mayoría) los programadores finalmente asimilaron el hecho de que cualquier cosa "oculta" en la página web, o en la comunicación entre el navegador y el servidor, no está protegida del usuario ( aunque tomó mucho tiempo para que el grokking se generalizara, sigue siendo una idea popular de que las llamadas AJAX son de alguna manera "especiales". Por lo tanto, a menudo se usarán mal ... Por ejemplo, todavía veo muchos sitios con SSL en todas las páginas regulares, pero los datos confidenciales reales fluyen libremente sobre AJAX sobre HTTP no cifrado.
En resumen, hasta cierto punto, las opiniones de tus cowirkers también son parcialmente culpables aquí, esperando que AJAX sea de alguna manera "especial".
La respuesta depende de los activos que intenta proteger y su modelo de amenaza.
Si le preocupa que el usuario ataque su contenido de la página web y el código AJAX en él y descubra algo en la página que no quería que supieran, entonces es cierto que AJAX es inseguro, ya que el usuario tiene acceso físico al entorno en el que se ejecuta la página web. Un ejemplo de esto es el ejemplo de juego que Thomas describe en una de las otras respuestas. Si la página implementa una interfaz de juego e incluye información sobre dónde están otros jugadores, entonces el usuario puede entender todo eso y "ver a través de las paredes" y podría hacer trampa.
Por otra parte, si está preocupado por el usuario que ataca su servidor , y asume que el usuario puede modificar cualquier cosa en la página web y el código asociado, y toma las precauciones adecuadas para proteger su servidor contra cualquier cosa que el usuario pueda hacer en esas circunstancias, entonces, como otros han señalado, AJAX es tan seguro como cualquier otra buena técnica de programación, y depende principalmente del código del lado del servidor, como siempre. Actualización : pero hacerlo puede ser complicado y, como apunta @iivel, una página OWASP explica las diversas cosas que debe tener en cuenta: Pruebas de vulnerabilidades de AJAX (OWASP-AJ-001)
Todo esto se aplica a otras técnicas del lado del cliente como Flash o applets de Java o Silverlight, etc. Heck, también se aplica a Word o PDF, si coloca contenido allí (como metainformación sobre quién es el autor o el propietario del el software es, o el contenido que se "borra" superponiéndolo con un apagón digital) que no creas que la gente verá o que ni siquiera recuerdas que se incluye automáticamente, entonces te sentirás decepcionado cuando usuario experto mira los bits.
Es realmente importante pensar detenidamente acerca de su modelo de amenaza y si sus herramientas lo abordan.
AJAX significa: "una página web con algún código, y lo digo en serio". No existe una distinción clara entre AJAX y una página "normal", ya que las páginas normales también pueden tener elementos de secuencias de comandos. AJAX es más una forma de afirmar que tiene la intención de insertar algunas partes de su aplicación en el navegador del cliente.
Una aplicación basada en web se ejecuta a través de la unión del servidor y el cliente. Es tentador que el cliente haga algo más que mostrar las páginas enviadas por el servidor, porque:
Se puede hacer una analogía con los juegos en línea, por ejemplo, Con los juegos de FPS. Varios usuarios disparan entre sí. El servidor realiza un seguimiento de dónde está todo el mundo y quién mata a quién. Para tales juegos, la reactividad de la interfaz es de suma importancia; por lo tanto, es completamente inimaginable que el servidor calcule todo y simplemente envíe marcos para mostrar al cliente. En su lugar, los clientes deben hacer el trabajo pesado de renderizado 3D, y el servidor simplemente envía mapas de nivel y actualizaciones de posición del jugador.
En ese momento, la seguridad entra en juego, debido a la regla fundamental:
En la analogía de los juegos, esto significa que el servidor debe confiar en el código del cliente: para la representación 3D, el cliente debe conocer el mapa de nivel y la posición de todos los demás jugadores. Sería fácil, para un cliente modificado, mostrar el mapa al jugador e identificar a los otros jugadores. En realidad, hay muchos tramposos por ahí, y los motores de juego utilizan sofisticadas técnicas de ofuscación de código para tratar de disuadir a la mayoría de ellos (porque los tramposos matan la diversión y, sin la diversión, los jugadores se van).
Esto ilustra lo que tiene la seguridad de AJAX: ya que es un código que se ejecuta en el lado del cliente, el servidor no puede confiar en lo que hace, incluso si el usuario está debidamente autenticado (sabiendo que who sí no lo hace automáticamente legítimo). Por lo general, esto no es un problema para las interacciones relacionadas con la GUI, a menos que haya problemas de seguridad en la GUI, como la función de "visualización del mapa de nivel" en la analogía de los juegos. La forma correcta de analizar la seguridad de las aplicaciones basadas en la Web es asumir que cada byte que emite el servidor es conocido por el cliente y que cada byte del cliente es potencialmente malicioso.
Como un ejemplo aproximado, considere la inyección SQL. Una forma de evitar los ataques de inyección de SQL es asegurarse de que el elemento de datos que inserta en su solicitud no tenga un carácter especial sin escapar. Este paso de validación DEBE se debe realizar en el servidor. No puede hacer eso de forma segura en AJAX, ya que cualquier cosa que haga AJAX puede ser omitida por el cliente.
OWASP tiene un buen artículo sobre este tema. El principal problema es que AJAX es una superficie de ataque más amplia, junto con algunos ataques que solo son realistas en las aplicaciones AJAX (hacks JSON o piratería de eventos del cliente).
Pruebas de vulnerabilidades de AJAX (OWASP-AJ-001)
enlace
Por la naturaleza asincrónica de la aplicación y, por lo tanto, los servicios requeridos, se pueden atacar más áreas. Las estructuras de datos y los métodos de eventos en sí también son más susceptibles de ser atacados que lo que normalmente sería un viaje de ida y vuelta por correo.
Lea otras preguntas en las etiquetas web-application appsec ajax