Caso de uso de defensa CSRF
Tiene un dispositivo integrado que admite la interfaz de usuario web basada en HTTP a través de una dirección IP privada.
¿Tiene sentido implementar la defensa CSRF sobre HTTP (no HTTPS)?
Respuestas
Si una solicitud HTTP puede cambiar de estado, es posible que necesite protección CSRF. Si la solicitud está encriptada o no en la capa de transporte tiene poca o ninguna relación con esto.
Sin la protección CSRF, un atacante que lo convenza de visitar su sitio web o incluso un solo recurso puede enviar solicitudes a su dispositivo integrado y tomar el control, si el navegador de la víctima está debidamente autorizado o si la autenticación es insuficiente o está rota. Esto sucede independientemente de si se usa HTTP o HTTPS.
Sí, idealmente todo sería a través de HTTPS. Sin embargo, la "mejor" opción para la mayoría de los proveedores en este momento es enviar dispositivos integrados con certificados autofirmados que, además de ser buenos para la confianza en el primer uso y frustrar el rastreo pasivo, no son mucho mejores que HTTP simple en muchos escenarios. A menudo, el usuario aún recibirá una advertencia de certificado y hará clic en él. Hasta que se resuelva este problema, la perspectiva de HTTPS en los dispositivos integrados sigue siendo sombría.
(Abordando sus ediciones ahora eliminadas) De hecho, XSS pasa por alto las mitigaciones de CSRF. Sin embargo, el modelo de amenaza parece un poco diferente aquí, ya que es menos probable que un adversario pueda explotar un XSS en su dispositivo integrado que un problema de CSRF, ya que tendrían que llegar al dispositivo en el primer caso.
Sin la defensa CSRF, un atacante podría falsificar un correo electrónico (tal vez con una dirección falsificada decentemente dirigida) con una alerta de monitoreo, diciéndole que revise porque hay un problema crítico. Dentro del correo electrónico, podría haber un enlace a http://yourswitch/factory_reset.
Los vectores de ataque pueden variar.
A menos que utilice un FQDN predeterminado o una dirección IP (por ejemplo, el omnipresente 192.168.1.1) para ese dispositivo, este tipo específico de ataque sería bastante específico. Un atacante tendría que crear una solicitud para el conmutador que realmente haga algo "interesante" (esto requiere conocer el FQDN/IP y el proveedor/modelo para obtener una ruta útil) y enviarle este enlace de una manera que no genere demasiados ingresos. tus cejas (el correo electrónico de Internet sería extraño. ¿Tal vez algo falsificando un correo electrónico de monitoreo de no respuesta que usas?).
Como de costumbre, se trata de comprender su modelo de amenaza y el costo frente al beneficio de sus contramedidas.
Sí.
En el caso de un conmutador de red o un enrutador, los ataques típicos que podría sufrir serían la reconfiguración del dispositivo (como reenviar un puerto interno al exterior), cambiar los DNS que proporciona a otros maliciosos, etc. Estas acciones deberían necesitar autenticación, pero debe tener en cuenta que también podría estar usando una contraseña predeterminada sin cambios.
(y sí, este tipo de cosas suceden en la naturaleza)
El hecho de que se base en una dirección privada.http://192.168.1.1no brinda protección, ya que el ataque sería por parte de una página web maliciosa, enviando a través del navegador de un usuario dentro de la red una solicitud maliciosa que -aceptada por la falta de protección CSRF- desconfiguraría el conmutador.
Mozilla Firefox ha tenido abierto el error 354493 durante 14 años, lo que evitaría ataques de direcciones que no sean RFC-1918 a direcciones RFC 1918, pero hasta ahora no se ha implementado.