usando tokens temporales para una comunicación segura con IFRAME

0

Tengo preguntas sobre la arquitectura de seguridad de nuestra aplicación:

Una pieza crítica que no puede guardar el estado pero recopila y muestra información confidencial se presenta en un IFRAME dentro de un marco web más moderno que controlaría el inicio de sesión, la sesión, etc.

La aplicación IFRAME y el padre están en el mismo dominio. Tanto IFRAME como el padre utilizarán https.

Cuando el usuario inicia sesión en la aplicación web externa, se genera un formulario iframe-ed que contiene información confidencial y luego se pone a disposición dentro de IFRAME a través de una URL única (por ejemplo, hxxps: //example.com/myapp/form/a8ba8b8dsf8sdfasfsd0sfd/ ) e inmediatamente expiró para que una solicitud posterior con el mismo token de url no pueda acceder a los datos confidenciales. El formulario contiene un token de envío único y sensible al tiempo (como un token csrf) que protege contra el envío de formularios no autorizados.

Estoy pensando que el riesgo de que un usuario malintencionado juegue con la url iframe es casi inexistente debido a los tokens de una sola vez.

  1. ¿Qué riesgos de seguridad tiene esta arquitectura?

  2. ¿Existe una mejor manera para que una aplicación de envoltorio se comunique con el ¿Aplicación IFRAME?

Supongo que la aplicación de envoltorio podría realizar solicitudes directamente a la aplicación secundaria y escribir la respuesta directamente a su propia página en lugar de utilizar un IFRAME. Todavía deberíamos generar tokens temporales porque el formulario resultante aún deberá enviarse a la aplicación "secundaria" que no puede mantener el estado. La ventaja de esto es que ahora la aplicación del contenedor es el único host autorizado para realizar solicitudes GET a la aplicación "secundaria" (se debe permitir al cliente realizar solicitudes POST, pero no podrán obtener información confidencial).

Este consejo de OWASP parece advertir contra este tipo de pensamiento, pero la caducidad inmediata de cada token parece mitigar sus preocupaciones.

  

Las aplicaciones altamente protegidas no deben usar la reescritura de URL para mantener el estado cuando las cookies están desactivadas en el cliente.

ACTUALIZACIÓN ::::::

la aplicación de envoltorio que realiza solicitudes directas a la solución de aplicación "secundaria" no funcionará para nosotros y vamos por el camino de IFRAME. ¿Mis conclusiones sobre el IFRAME son válidas?

    
pregunta mcgyver5 14.01.2015 - 19:54
fuente

1 respuesta

1

Puede realizar las solicitudes a la aplicación secundaria directamente desde el código del servidor del contenedor y descartar el uso del iframe. La aplicación secundaria solo debe permitir el acceso desde el servidor de aplicaciones principal.

Esto también daría como resultado una mejor experiencia de usuario, porque tendría un diseño mejor y más uniforme.

    
respondido por el Dinu S 14.01.2015 - 20:02
fuente

Lea otras preguntas en las etiquetas