it-swarm-es.com

¿Es AJAX fundamentalmente inseguro?

Posible duplicado:
¿Cómo hacer Ajax de forma segura?

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 codifica la llamada/página.

¿Existe una falla 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 síncrona estándar?

16
C. Ross

Respuesta corta: tienes razón, depende de cómo codifiques la página.

Respuesta un poco más larga:
No hay nada inherentemente inseguro sobre 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 lo codifique. Pero eso no lo hace "fundamentally insecure".

Sin embargo, a menudo hay un problema diferente y sutil en juego: mientras que (la mayoría) los programadores eventualmente 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ó demasiado tiempo para que el grokking se generalice), sigue siendo una idea popular que AJAX son de alguna manera "especiales". Por lo tanto, a menudo se usarán mal ... Por ejemplo, todavía vea muchos sitios con SSL en todas las páginas normales, pero los datos confidenciales reales fluyen libremente sobre AJAX sobre HTTP no encriptado.

En resumen, hasta cierto punto sus opiniones de cowirkers también son parcialmente culpables aquí, esperando que AJAX sea de alguna manera "especial".

8
AviD

La respuesta depende de qué activos está tratando de proteger y su modelo de amenaza.

Si le preocupa que el usuario ataque el contenido de su página web y el código AJAX) 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 resolver todo eso y "ver a través de las paredes" y podría hacer trampa.

Por otro lado, si le preocupa que el usuario ataque 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 de su código del lado del servidor, como siempre. Actualización : Pero hacerlo puede ser complicado, y como señala @iivel, una página de OWASP explica las diversas cosas que usted querrá tener cuidado con: Prueba de AJAX Vulnerabilidades (OWASP-AJ-001)

Todo esto se aplica a otras técnicas del lado del cliente como Flash o Java applets 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 software, o contenido que se "borra" superponiéndolo con un blanco digital) que no cree que la gente verá o que ni siquiera recordaba que se incluye automáticamente, entonces se sentirá tristemente decepcionado cuando un usuario inteligente mire los bits.

Es realmente importante pensar cuidadosamente sobre su modelo de amenaza y si sus herramientas lo abordan.

10
nealmcb

AJAX significa: "una página web con algún código, y lo digo en serio". No hay una distinción clara entre AJAX y una página "normal", ya que las páginas normales también pueden tener elementos de script. AJAX es más una forma de indicar 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 sobre la unión del servidor y el cliente. Es tentador que el cliente haga un poco más que solo mostrar páginas enviadas por el servidor, porque:

  • aumenta la reactividad de la interfaz (se mejora la experiencia del usuario);
  • puede reducir la carga de la red (muchas operaciones basadas en GUI se pueden realizar en el cliente sin hablar con el servidor);
  • puede reducir la carga informática (más trabajo para la máquina cliente, menos trabajo para el servidor).

Se puede hacer una analogía con los juegos en línea, p. con juegos de FPS. Varios usuarios se disparan el uno al otro. El servidor realiza un seguimiento de dónde están todos 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 solo envíe marcos para mostrar al cliente. En cambio, los clientes deben hacer el trabajo de renderizado 3D pesado, y el servidor simplemente envía mapas de nivel y actualizaciones de posición del jugador.

En ese punto, la seguridad entra en juego, debido a la regla fundamental:

  • Desde el punto de vista del servidor, el cliente es un villano.

En la analogía de los juegos, esto significa que el servidor debe confiar en el código del cliente: para la representación en 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 y señalar a los otros jugadores. En realidad, hay muchos tramposos por ahí, y los motores de juego usan técnicas sofisticadas de ofuscación de código para tratar de disuadir a la mayoría de los tramposos (porque los tramposos matan la diversión, y sin la diversión los jugadores se van).

Esto ilustra la cuestión de la seguridad AJAX: dado 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 who no lo hace automáticamente legítimo). Esto generalmente no es un problema para las interacciones relacionadas con la GUI, a menos que haya problemas de seguridad sobre la GUI, como la función de "visualización de mapa de nivel" en la analogía del juego 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 cada byte del cliente es potencialmente malicioso.

Como un ejemplo aproximado, considere la inyección de SQL. Una forma de evitar los ataques de inyección SQL es asegurarse de que el elemento de datos que conecte a su solicitud no tenga un carácter especial sin escape. Este paso de validación DEBE realizarse en el servidor. No puede hacerlo de forma segura en AJAX, ya que lo que sea AJAX) puede ser ignorado por el cliente.

9
Thomas Pornin

OWASP tiene un buen artículo sobre este tema. El principal problema con AJAX es una superficie de ataque más amplia, junto con algunos ataques que solo son realísticamente posibles en AJAX (pirateos JSON o pirateo de eventos del cliente)) .

Prueba para AJAX Vulnerabilidades (OWASP-AJ-001)
http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is.html

Por la naturaleza asincrónica de la aplicación, y por lo tanto los servicios requeridos, más áreas son susceptibles de ataque. Las estructuras de datos y los métodos de eventos en sí también son más susceptibles de ataque de lo que normalmente sería un viaje de ida y vuelta desde la publicación.

4
iivel