Situación inicial:
Un servicio web RESTful se defiende contra los ataques CSRF mediante el uso del enfoque de cookies de doble envío. Esto significa que el token de autenticación se envía dos veces y se verifica en el lado del servicio.
Problema / Amenaza de seguridad:
El elemento WebView de las plataformas Android e iOS permite crear un navegador web malicioso que descubre y modifica las cookies de sesión. webView.loadUrl("javascript:document.cookie=’’;");. Si el atacante ya descubrió cómo se ve la cookie enviada dos veces (en este caso, es el token de autenticación), puede crear un RESTBrowser malicioso. Por lo tanto, agrega el CSRFToken ya conocido al modelo de objeto del documento y, por lo tanto, omite la contramedida CSRF. ¿Es así hasta ahora?
Posibles prevenciones:
Hasta ahora no tengo idea de cómo puedo evitar que un atacante cree y publique una aplicación móvil maliciosa, así como evitar que se acceda al servicio a través de aplicaciones móviles maliciosas. Conozco la existencia del User-Agentencabezado y que el servicio puede usar esta información para rechazar solicitudes de otros navegadores que no sean específicos. Pero estoy seguro de que también este encabezado se puede manipular dentro de WebView.
¿Cuáles son las contramedidas efectivas contra CSRF en el contexto de aplicaciones móviles maliciosas?
¿Un WebView de Android malicioso rompe la contramedida DoubleSubmittCookie contra CSRF?
Respuesta corta: no.
Respuesta larga: CSRF explota la confianza que un sitio tiene en el navegador de un usuario. La protección CSRF no está destinada a proteger el servidor de un agente de usuario malicioso o de un usuario no confiable. El usuario es responsable de elegir un navegador confiable.
ce4
miente ryan