2008-08-26 14 views
172

JavaScript necesita acceso a las cookies si se utiliza AJAX en un sitio con restricciones de acceso basadas en cookies. ¿Funcionarán las cookies HttpOnly en un sitio AJAX?¿Cómo funcionan las cookies de HttpOnly con las solicitudes de AJAX?

Editar: Microsoft creó una forma de evitar los ataques XSS al no permitir el acceso de JavaScript a las cookies si se especifica HttpOnly. FireFox luego adoptó esto. Entonces mi pregunta es: si está utilizando AJAX en un sitio, como StackOverflow, ¿son las cookies de Http-Only una opción?

Edición 2: Pregunta 2. Si el propósito de HttpOnly es para evitar el acceso a las cookies de JavaScript, y todavía se puede recuperar las galletas a través de JavaScript a través del objeto XMLHttpRequest, ¿cuál es el punto de HttpOnly?

Datos 3: Aquí es una cita de Wikipedia:

Cuando el navegador recibe una cookie tal, que se supone que lo utilizan como es habitual en los siguientes intercambios HTTP, pero no para que sea visible a los scripts del lado del cliente. [32] El indicador HttpOnly no forma parte de ningún estándar y no está implementado en todos los navegadores. Tenga en cuenta que actualmente no hay prevención de leer o escribir la cookie de sesión a través de XMLHTTPRequest. [33].

Entiendo que document.cookie está bloqueado cuando utiliza HttpOnly. Pero parece que todavía puede leer valores de cookies en el objeto XMLHttpRequest, lo que permite XSS. ¿Cómo HttpOnly te hace más seguro que? ¿Al hacer que las cookies sean esencialmente de solo lectura?

En su ejemplo, no puedo escribir en su document.cookie, pero aún puedo robar su cookie y publicarla en mi dominio utilizando el objeto XMLHttpRequest.

<script type="text/javascript"> 
    var req = null; 
    try { req = new XMLHttpRequest(); } catch(e) {} 
    if (!req) try { req = new ActiveXObject("Msxml2.XMLHTTP"); } catch(e) {} 
    if (!req) try { req = new ActiveXObject("Microsoft.XMLHTTP"); } catch(e) {} 
    req.open('GET', 'http://stackoverflow.com/', false); 
    req.send(null); 
    alert(req.getAllResponseHeaders()); 
</script> 

Editar 4: Lo sentimos, quería decir que usted podría enviar el XMLHttpRequest para el dominio Stackoverflow, y luego guardar el resultado de getAllResponseHeaders() en una cadena, la expresión regular a cabo la cookie, y luego puesto que a un dominio externo. Parece que Wikipedia y ha.ckers coinciden conmigo en esto, pero me encantaría ser re-educado ...

edición final: Ahh, al parecer, ambos sitios están mal, esto es en realidad un bug in FireFox. IE6 & 7 son en realidad los únicos navegadores que actualmente son totalmente compatibles con HttpOnly.

Reiterar todo lo que he aprendido:

  • HttpOnly restringe el acceso a todos los document.cookie en IE7 y Firefox & (no estoy seguro acerca de otros navegadores)
  • HttpOnly elimina información de la cookie de las cabeceras de respuesta en XMLHttpObject.getAllResponseHeaders() en IE7.
  • Los XMLHttpObjects solo se pueden enviar al dominio del que se originaron, por lo que no se publican cookies entre dominios.

editar: Esta información probablemente no esté más actualizada.

+0

Lancé su ejemplo en un script de greasemonkey y parece que FF ya no muestra cookies. Excelente investigación y ejemplo. –

+0

Tal vez con la misma política de origen, no puede realizar una solicitud http a un dominio que no sea el mismo en el que se ejecuta el script; sin embargo, creo que podría pasar fácilmente las cookies redireccionando al usuario a una página mediante window.location y pasar toda la información a través de los parámetros de la cadena de consulta. –

Respuesta

3

No necesariamente, depende de lo que quiera hacer. Podrías elaborar un poco? AJAX no necesita acceso a cookies para trabajar, puede realizar solicitudes por sí mismo para extraer información, la solicitud de la página que hace que la llamada AJAX pueda acceder a los datos de la cookie & la transfiere al script de llamadas sin que Javascript tenga que acceder directamente al galletas

0

no, la página que las peticiones de llamada AJAX tiene acceso a las cookies también & eso es lo que comprueba si está conectado.

usted puede hacer otra autenticación con el Javascript, pero yo no confiar en ella , Siempre prefiero poner cualquier tipo de verificación de autenticación en el back-end.

1

Las cookies son manejadas automáticamente por el navegador cuando realiza una llamada AJAX, por lo que no es necesario que su Javascript juegue con las cookies.

1

Por lo tanto estoy asumiendo JavaScript necesita tener acceso a las cookies.

Todas las peticiones HTTP de su navegador transmiten su información de cookies para el sitio en cuestión. JavaScript puede establecer y leer cookies. Las cookies no son por definición necesarias para las aplicaciones Ajax, pero se requieren para la mayoría de las aplicaciones web para mantener el estado del usuario.

La respuesta formal a su pregunta como fraseada: "¿Necesita JavaScript acceso a las cookies si se utiliza AJAX?" - Por lo tanto, es "no". Piense en campos de búsqueda mejorados que usan solicitudes de Ajax para proporcionar opciones de sugerencia automática, por ejemplo. No hay necesidad de información de cookies en ese caso.

+0

XmlHttpRequest necesita cookies. La búsqueda mejorada que mencione podría estar detrás de una página de inicio de sesión. Pero si JavaScript necesita ser capaz de exponer el valor de la cookie a la VM es una pregunta diferente. –

1

Como aclaración: desde la perspectiva del servidor, la página solicitada por una solicitud de AJAX no es esencialmente diferente a una solicitud de obtención de HTTP estándar realizada por el usuario haciendo clic en un enlace. Todas las propiedades de solicitud normales: user-agent, ip, session, cookies, etc. se pasan al servidor.

55

Sí, las cookies HTTP-Only estarían bien para esta funcionalidad. Se les proporcionará la solicitud de XmlHttpRequest al servidor.

En el caso de Desbordamiento de pila, las cookies se proporcionan automáticamente como parte de la solicitud XmlHttpRequest. No conozco los detalles de implementación del proveedor de autenticación de desbordamiento de pila, pero es probable que los datos de cookie se utilicen automáticamente para verificar su identidad en un nivel inferior al método del controlador de "votación".

Más generalmente, las cookies son no requerido para AJAX. El soporte de XmlHttpRequest (o incluso si es remoto, en navegadores más antiguos) es todo lo que se requiere técnicamente.

Sin embargo, si desea proporcionar seguridad para la funcionalidad habilitada para AJAX, entonces se aplican las mismas reglas que con los sitios tradicionales. Necesita algún método para identificar al usuario detrás de cada solicitud, y las cookies casi siempre son el medio para ese fin.

En su ejemplo, no puedo escribir en su document.cookie, pero aún puedo robar su cookie y publicarla en mi dominio utilizando el objeto XMLHttpRequest.

XmlHttpRequest no hará solicitudes de dominios cruzados (exactamente por el tipo de razones que está tocando).

Normalmente, puede insertar una secuencia de comandos para enviar la cookie a su dominio utilizando iframe remoto o JSONP, pero luego HTTP-Only protege la cookie nuevamente ya que es inaccesible.

A menos que haya comprometido StackOverflow.com en el lado del servidor, no podrá robar mi cookie.

Edición 2: Pregunta 2. Si el propósito de Http-Sólo es para evitar el acceso a las cookies de JavaScript, y todavía se pueden recuperar los cookies a través de JavaScript a través del objeto XMLHttpRequest, ¿cuál es el punto de sólo HTTP?

Considere este escenario:

  • me parece una vía para inyectar código JavaScript en la página.
  • Jeff carga la página y mi JavaScript malicioso modifica su cookie para que coincida con la mía.
  • Jeff envía una respuesta estelar a su pregunta.
  • Porque lo envía con mis datos de cookies en lugar de los suyos, la respuesta será mía.
  • Usted vota "mi" respuesta estelar.
  • Mi cuenta real obtiene el punto.

Con las cookies HTTP-Only, el segundo paso sería imposible, con lo que se anularía mi intento de XSS.

Editar 4: Lo siento, significaba que se podía enviar el XMLHttpRequest para el dominio Stackoverflow, y luego guardar el resultado de getAllResponseHeaders() a una cadena, regex a cabo la cookie, y luego puesto que a un dominio externo . Parece que Wikipedia y los hackers están de acuerdo conmigo en esto, pero me encantaría que me reedulen ...

Eso es correcto. Todavía puedes secuestrar la sesión de esa manera. Sin embargo, reduce significativamente el rebaño de personas que pueden ejecutar con éxito incluso el ataque de XSS en tu contra.

Sin embargo, si vuelve a mi escenario de ejemplo, puede ver dónde HTTP-Only hace cortar con éxito los ataques XSS que se basan en la modificación de las cookies del cliente (no poco común).

que se reduce al hecho de que a) no solo mejora va a resolver todos los vulnerabilidades y b) Ningún sistema jamás sea completamente segura. HTTP-Only es una herramienta útil para apuntalar contra XSS.

Del mismo modo, aunque la restricción de dominio cruzado en XmlHttpRequest no es 100% exitosa en la prevención de todos los exploits XSS, nunca soñaría con eliminar la restricción.

+0

Muchos frameworks ponen 'csrf' [token en las cookies] (http://stackoverflow.com/q/20504846/781695). Supongo que la llamada AJAX que necesita una verificación 'csrf' no funcionará a menos que coloque el token csrf en un elemento HTML oculto para que el JS lo recupere. – Medorator

2

Sí, son una opción viable para un sitio basado en Ajax. Las cookies de autenticación no son manipuladas por los scripts, sino que el navegador las incluye simplemente en todas las solicitudes HTTP realizadas al servidor.

Las secuencias de comandos no necesitan preocuparse por lo que dice la cookie de sesión: siempre que esté autenticado, cualquier solicitud al servidor iniciada por un usuario o la secuencia de comandos incluirá las cookies apropiadas.El hecho de que los scripts no puedan conocer el contenido de las cookies no es relevante.

Para las cookies que se utilizan para fines distintos de la autenticación, estos se pueden establecer sin el indicador HTTP solo, si desea que el script pueda modificarlos o leerlos. Puede seleccionar y elegir qué cookies deben ser solo HTTP, por lo que, por ejemplo, cualquier elemento no confidencial, como las preferencias de la interfaz de usuario (orden de clasificación, colapso del panel izquierdo o no), se puede compartir en las cookies con los scripts.

Me gustan mucho las cookies HTTP solamente; es una de esas extensiones propietarias del navegador que fue una idea muy clara.

0

Sí, las cookies son muy útiles para Ajax.

Poner la autenticación en la URL de solicitud es una mala práctica. Hubo una noticia la semana pasada sobre cómo obtener los tokens de autenticación en las URL de la memoria caché de google.

No, no hay forma de prevenir ataques. Los navegadores antiguos todavía permiten un acceso trivial a las cookies a través de javascript. Puede omitir solo http, etc. Cualquier cosa que se le ocurra puede conseguirse con suficiente esfuerzo. El truco es hacer demasiado esfuerzo para que valga la pena.

Si desea que su sitio sea más seguro (no existe una seguridad perfecta) puede utilizar una cookie de autenticación que caduque. Luego, si la cookie es robada, el atacante debe usarla antes de que caduque. Si no lo hacen, entonces tiene una buena indicación de que hay actividad sospechosa en esa cuenta. Cuanto más corta sea la ventana de tiempo, mejor es para la seguridad, pero cuanto más carga pone en su servidor la generación y el mantenimiento de las claves.

2

Hay algo más en esto.

Ajax no exige estrictamente cookies, pero pueden ser útiles como lo han mencionado otros carteles. Marcar una cookie HTTPOnly para ocultarlo de las secuencias de comandos solo funciona parcialmente, porque no todos los navegadores lo admiten, pero también porque hay soluciones comunes.

Es extraño que los encabezados de respuesta XMLHTTP den la cookie, técnicamente el servidor no tiene que devolver la cookie con la respuesta. Una vez que está configurado en el cliente, permanece establecido hasta que caduque. Aunque hay esquemas en los que se cambia la cookie con cada solicitud para evitar su reutilización. Por lo tanto, puede evitar esa solución al cambiar el servidor para no proporcionar la cookie en las respuestas de XMLHTTP.

En general, creo que HTTPOnly debe usarse con cierta precaución. Hay ataques de scripts cruzados en el sitio donde un atacante organiza que un usuario envíe una solicitud tipo ajax originada desde otro sitio, usando formularios de publicación simples, sin el uso de XMLHTTP, y la cookie aún activa de su navegador autenticaría la solicitud.

Si desea asegurarse de que se autentica una solicitud AJAX, la solicitud en sí Y los encabezados HTTP deben contener la cookie. Por ejemplo, mediante el uso de scripts o entradas ocultas únicas. HTTPOnly obstaculizaría eso.

Por lo general, la razón interesante para querer HTTPOnly es evitar que el contenido de terceros incluido en su página web robe cookies. Pero hay muchas razones interesantes para ser muy cauteloso al incluir contenido de terceros y filtrarlo agresivamente.

Cuestiones relacionadas