¿Las cookies HTTPOnly se envían a través de XmlHTTPRequest with withCredentials = True?

3

Tengo una pregunta de dos partes aquí.

Tengo una aplicación web javascript que accede a puntos finales REST privilegiados. Me gustaría protegerme contra CSRF.

Actualmente, tengo un sistema de inicio de sesión que devuelve una cookie de inicio de sesión que contiene una carga útil cifrada (cifrar y luego MAC). Estoy razonablemente seguro de que los contenidos de la cookie no pueden ser manipulados o falsificados sin mi conocimiento.

Sé que el uso de dicha cookie para proteger mis puntos finales es vulnerable a CSRF, ya que la cookie es enviada automáticamente por el navegador con cualquier solicitud. También creo que se desaconseja el patrón de Double Submit Cookie porque requiere establecer el valor HTTPOnly de la cookie en False, lo que aumenta el riesgo de ciertos ataques.

Lo que me gustaría hacer es configurar la cookie de autenticación (utilizada para los inicios de sesión persistentes en el mediano plazo) en HTTPOnly and Secure. Luego, me gustaría que el cliente javascript realice una solicitud XHR GET a un punto final de token donde se pueda validar la cookie y se pueda emitir un token de corto plazo (que contiene un identificador que apunta a la información que he escondido en mi DB). al cliente, sin redirección de User Agent. El cliente javascript usaría el token de corto plazo para autorizar las llamadas a mis puntos finales REST.

Mi primera pregunta es, ¿hay fallas obvias con este flujo? Parece una adaptación razonable del Patrón de token del sincronizador para REST, pero me gustaría saber si hay fallas graves o si existen otras mejores prácticas en relación con el procedimiento.

He considerado la implementación del flujo OAuth 2.0 Implícito Grant, pero me gustaría que estuviera presente la cookie de autenticación para que pueda persistir los inicios de sesión durante un período de tiempo moderado.

La segunda pregunta es: ¿el navegador con mi XHR enviará la cookie HTTPOnly al punto final del token si configuro con Credenciales = Verdadero? Sé que HTTP solo restringe la capacidad del javascript para leer la cookie, pero ¿aparecerá la etiqueta de la cookie en la solicitud, invisiblemente para el cliente?

He buscado en google la respuesta y mi google-fu me ha fallado. Todo lo que pude encontrar fueron numerosos artículos sobre la lectura de cookies de HTTPOnly, pero no enviarlas.

¡Gracias de antemano por cualquier ayuda o consejo!

    
pregunta Hao Cheng 14.03.2014 - 07:48
fuente

2 respuestas

3
  

También creo que se desaconseja el patrón de Double Submit Cookie porque requiere establecer el valor HTTPOnly de la cookie en False

No requiere establecer HTTPOnly en falso. Esto es solo si tiene algún código JavaScript que establecerá el valor del campo de formulario oculto al mismo que la cookie. Es posible hacer esto sin JavaScript simplemente enviando el valor de la cookie al lado del servidor de la página (codificándolo correctamente, por supuesto, para evitar XSS).

  

Mi primera pregunta es, ¿existen fallas obvias en este flujo?

Esto parece estar bien porque un atacante no puede leer la solicitud GET debido a la misma política de origen. Sin embargo, si su información es altamente segura, puede ser una buena idea protegerse contra Secuestro JSON . Esto no ha sido un problema durante mucho tiempo (piense en Firefox 3), pero en caso de que se vuelvan a introducir fallas en cualquier navegador, podría tomar pasos básicos para proteger su sitio a un bajo costo. Por ejemplo, cambiando esto a un POST y agregando un cruft no analizable a la respuesta. Esto va en contra de los principios REST, pero eso es algo que tendrá que sopesar por sí mismo.

  

La segunda pregunta es: ¿el navegador con mi XHR enviará la cookie HTTPOnly al punto final del token si configuro con Credenciales = Verdadero?

Sí lo hará. HTTPOnly protege de JavaScript en el cliente, no afecta a las solicitudes HTTP.

    
respondido por el SilverlightFox 15.08.2014 - 11:19
fuente
0

Sí, se han enviado. Consulte la especificación del W3C .

HTTPOnly está diseñado para mitigar ataques como XSS, pero si un atacante tiene un XSS en su sitio, no necesita un CSRF. ¿Ha considerado el Patrón de token cifrado ?

    
respondido por el David 16.06.2014 - 06:34
fuente

Lea otras preguntas en las etiquetas