Solo quiero obtener información de personas que conocen. Estaba considerando las vulnerabilidades de CSRF, y el método aparentemente más popular que conozco para luchar contra él. Ese método es crear un token en el html devuelto y agregar una cookie con el mismo valor. Por lo tanto, si un script intenta hacer una publicación, lo haría have to guess the token thats embedded in the web page para que tenga éxito.CSRF vulnerabilidad/cookies pregunta
Pero si están dirigidas a un sitio web específico por qué no pueden simplemente utilizar un script que
- Pide un encuentro en la página (la cookie se volvió a pesar de que el guión no puede acceder a él)
- analiza el html y obtiene el token
- llama un post con esa señal en ella (la cookie que volvieron será enviado de vuelta)
- se ha sometido con éxito una forma sin el conocimiento del usuario
La secuencia de comandos no necesita saber el contenido de la cookie, solo está utilizando el hecho de que las cookies se envían de un lado a otro todo el tiempo.
¿Qué me falta aquí? ¿No es esto posible? Creo que esto es bastante aterrador si lo piensas bien.
Por debajo de esta línea no se requiere la lectura de responder a la pregunta :)
bancos esta vulnerabilidad en el hecho de que la autenticación se realiza basándose en las cookies, que creo que es la principal vía de autenticación se está produciendo actualmente.
Otra solución que puedo pensar es hacer que la autenticación sea a nivel de página. Entonces cuando inicien sesión en el html devuelto tendrá ese token en él. cada enlace que hacen clic contiene ese token, de modo que cuando el servidor web recibe una solicitud, tiene una forma de identificar al usuario/sesión. El problema es que si utilizan otra navegación que no sea 'no autenticadas' (por ejemplo, escriba una url), tampoco se ve bien en la url porque probablemente se vería así:
https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3
Pero entiendo que si la seguridad es más importante, entonces una bonita URL es el segundo lugar.
No sé todo sobre las cookies, pero ¿qué pasa si los agentes de usuario fueron un poco más cuidadosos con sus cookies?
Por ejemplo, ¿qué ocurre si las cookies enviadas dependen de la pestaña? Todos navegamos usando pestañas por ahora, ¿verdad? Entonces, ¿qué pasa si el alcance de la cookie es la pestaña? entonces si tengo mi sitio bancario abierto en la pestaña 1 y estoy navegando en la pestaña 2, las secuencias de comandos que obtengan/publiquen en pestaña 2 solo enviarán las cookies acumuladas en la pestaña 2.
O qué pasa si se almacenan las cookies/dominio Entonces, mientras estoy en example.com, las cookies que vuelven van a la colección de cookies de example.com. y luego, cuando estoy en www.mybankingsite.com, todas las cookies se ponen en la colección mybankingsite.com. Entonces, si voy a example.com y ejecuta un script que llama a un get/post, el agente de usuario solo enviará cookies de example.com. Esto es diferente a enviar las cookies del dominio solicitado. P.ej. si un script llama a get de mybankingsite.com dentro de una página web de example.com, el agente de usuario no enviará las cookies de mybankingsite.com.
Yo sé que no tengo control sobre lo que los agentes de usuario hacer, pero sólo estoy explorando posibilidades
bien, podrías evitar esto aceptando solo una acción de Http post en esa url, pero abre el hecho de que una secuencia de comandos tiene acceso a su DOM y si un elemento puede obtener información de otro sitio, entonces puedes estar en peligro – Jose