Estoy trabajando en una API RESTful para trabajar con mi aplicación AngularJS.
La autenticación funciona mediante la generación de un formulario de ASP.NET FormsAuthenticationTicket. Se almacena en una cookie utilizando FormsAuthentication.Encrypt . Este enfoque podría resultar en el robo de la cookie de autenticación, sin embargo, ese problema está fuera del alcance de esta pregunta.
La pregunta es sobre generar un token CSRF. Quiero generar el token basado en la cookie de autenticación, de esa manera cuando el usuario cierre la sesión (o cierre sesión y vuelva a iniciarla) el token se invalidará. El problema con la generación de un token para cada formulario es que el formulario podría caducar antes de que caduque la autenticación. Quiero que los formularios sigan siendo válidos mientras el usuario esté conectado.
Si la cookie de autenticación es secuestrada, toda la seguridad se pierde de todos modos. Por eso no veo ningún riesgo adicional para el token CSRF relacionado con la cookie de autenticación. El token se enviará al cliente como cookie y al servidor como encabezado.
Además, verificaré los encabezados de referencia / origen, pero eso está fuera del alcance de esta pregunta.
Algunos ejemplos:
# URL that doesn't require authentication
GET /api/security/session HTTP/1.1
HOST localhost:1234
HTTP/1.1 200 OK
Set-Cookie: .ASPXAUTH=SomeLongHexCodeHere; Expires=...; HttpOnly
Set-Cookie: CSRF-Token=TheToken; Expires=...;
# URL that does require authentication
GET /api/account/data
HOST localhost:1234
X-CSRF-Token: TheToken
Para generar el token CSRF, estaba pensando en generar un hash con sal a partir de la cookie .ASPXAUTH. ¿Sería esto suficiente en la protección contra CSRF, suponiendo que XSS esté bloqueado y que la cookie de autenticación no haya sido secuestrada?
Dos notas finales. Aunque mi código se ejecuta en la plataforma ASP.NET, no utiliza ninguna de las tecnologías ASP.NET (WebForms, WCF, MVC, WebAPI, etc.) y no puede usar sus métodos de protección CSRF. En segundo lugar, el sitio no usa SSL, y lamentablemente no usará SSL. Será vulnerable a los ataques MITM, y no hay mucho que pueda hacer al respecto.