Prevención de CSRF / XSS en la API compartida de web / móvil

0

He heredado una base de código que incluye un dispositivo móvil & aplicación web que accede a la misma API y se ha encargado de solucionar algunos de los agujeros de seguridad que existen, desafortunadamente no estoy bien versado en el tema. Ahora entiendo que las vulnerabilidades que busco se aplican solo a la web, pero me gustaría minimizar los cambios requeridos en el extremo móvil, y dado que este servicio involucra a ambos, estoy en busca de un consejo situacional.

Ambos web y amp; los dispositivos móviles reciben un token de acceso almacenado en una cookie segura que utilizan para acceder a la API. Esto funciona perfectamente bien para el lado móvil, pero está abierto a CSRF en la web. Al usar el SOP y nuestra política de CORS, podemos impedir que otros orígenes lean datos, pero, por supuesto, aún pueden hacer cambios en el servidor (es decir, eliminar, actualizar).

Una solución que se ha presentado es cambiar al almacenamiento del token de acceso en el almacenamiento web para que no seamos vulnerables a los ataques CSRF (porque están bloqueados por el dominio). Por supuesto, esto nos abriría a las vulnerabilidades de XSS, pero según nuestro conocimiento, la aplicación web es segura en ese sentido (todas las entradas de los usuarios están saneadas y validadas, y ninguna entrada de usuario se envía directamente al DOM). Pero, me han dicho (no puedo encontrar referencias) que los complementos del navegador pueden insertar código en el DOM y que tendrían acceso gratuito a esos valores de almacenamiento, lo que hace que nuestra seguridad sea esencialmente discutible.

Otra solución sería utilizar una de las soluciones descritas en CSRF cheat sheet pero requeriría un estado adicional en el servidor y volver a escribir cómo los clientes móviles manejan sus cookies y solicitudes y no es ideal.

Por lo tanto, una solución mejor que la anterior sería separar la web & API móviles para permitir las soluciones de vulnerabilidad CSRF sin tener que realizar ajustes en las aplicaciones móviles.

Tengo curiosidad por saber qué sugeriría que fuera la mejor solución a este problema, o tal vez me esté perdiendo algo que podría ser una solución más simple (por ejemplo, CSP, no estoy seguro de si eso podría evitar ciertos casos de XSS). agujeros?).

    
pregunta Malcolm 04.04.2018 - 20:08
fuente

1 respuesta

1

Creo que su mejor solución sería mover el token de acceso de una cookie al almacenamiento local. Es simple y eficiente.

Entonces, ¿qué pasa con las preocupaciones que plantea? Tienes razón en que esto expone el token a XSS. Pero si tienes vulnerabilidades de XSS, es un juego efectivo de todos modos. La bandera HttpOnly es una molestia para un atacante, no es una defensa sólida. No elegiría un diseño más complicado solo para poder mantener el token lejos de JS. En su lugar, ¡pase el tiempo que ahorra en la búsqueda de vulnerabilidades reales de XSS!

En cuanto a los complementos maliciosos de los navegadores, no hay forma de defenderse contra ellos sin importar dónde guardes tus tokens. Si el cliente está infectado con malware, ya lo ha perdido. Por lo tanto, desde la perspectiva de un desarrollador de API, no tiene sentido intentar siquiera defender este escenario. Sus usuarios necesitan mantener sus máquinas limpias; si fallan, no hay nada que puedas hacer por ellos.

Dividir la API le brinda un mayor trabajo de mantenimiento en el futuro, y de alguna manera niega todo el beneficio de tener una API. Para mí, huele a una solución de emergencia fea de la que me mantendría alejado.

Finalmente, un CSP estricto siempre es una buena idea. No es una bala de plata, pero sin duda ayuda mucho.

    
respondido por el Anders 05.04.2018 - 15:04
fuente

Lea otras preguntas en las etiquetas