domain - jquery ajax set cookie

¿Cómo funcionan las cookies de HttpOnly con las solicitudes de AJAX?

Question

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?

Editar: Microsoft creó una forma de evitar 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 evitar el acceso de JavaScript a las cookies, y aún puede recuperar las cookies a través de JavaScript a través del Objeto XmlHttpRequest, ¿cuál es el sentido de HttpOnly ?

Edición 3: Aquí hay una cita de Wikipedia:

Cuando el navegador recibe dicha cookie, se supone que debe usarla como de costumbre en los siguientes intercambios HTTP, pero no para hacerla visible en 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 usa 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 siento, quise decir que podría enviar XMLHttpRequest al dominio de StackOverflow, y luego guardar el resultado de getAllResponseHeaders () en una cadena, eliminar la cookie y publicarla en un dominio externo. Parece que Wikipedia y los hackers están de acuerdo conmigo en esto, pero me encantaría que me reeduquen ...

Edición final: Ahh, aparentemente ambos sitios están equivocados, esto es realmente un error en Firefox . IE6 y 7 son en realidad los únicos navegadores que actualmente son totalmente compatibles con HttpOnly.

Para reiterar todo lo que he aprendido:

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

editar: esta información probablemente ya no esté actualizada.

Answer 1

Por lo tanto, supongo que JavaScript necesita acceso a sus cookies.

Todas las solicitudes 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 formulada: "¿Necesita JavaScript acceso a las cookies si se usa 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.

Answer 2

Como aclaración: desde la perspectiva del servidor, la página solicitada por una solicitud 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.

Answer 3

Hay un poco más para esto.

Ajax no exige estrictamente cookies, pero pueden ser útiles como 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 que no proporcione la cookie en las respuestas de XMLHTTP.

En general, creo que HTTPOnly debería 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 que se origina desde otro sitio, usando formularios de publicación simples, sin el uso de XMLHTTP, y la cookie aún activa de su navegador autenticará 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 más 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.

Answer 4

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.

Answer 5

No necesariamente, depende de lo que quieras 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 la llamada AJAX podría acceder a los datos de la cookie y pasarla al script de llamadas sin que Javascript tenga que acceder directamente al galletas

Answer 6

No, la página a la que las llamadas AJAX también tienen acceso a las cookies y eso es lo que verifica si estás conectado.

Puedes hacer otra autenticación con Javascript, pero no confiaría en eso, siempre prefiero poner cualquier tipo de verificación de autenticación en el back-end.

Answer 7

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

En el caso de , 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 de control de "votación".

De manera más general, las cookies no son necesarias 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 realizará solicitudes de dominios cruzados (exactamente por el tipo de razones por las 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 .com en el lado del servidor, no podrá robar mi cookie.

Edit 2: Question 2. Si el propósito de Http-Only es evitar el acceso de JavaScript a las cookies, y aún puede recuperar las cookies a través de JavaScript a través del objeto XmlHttpRequest, ¿cuál es el punto de Http-Only?

Considera este escenario:

• Encuentro 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 tu pregunta.
• Como él 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 entiende el punto.

Con las cookies HTTP-Only, el segundo paso sería imposible y, por lo tanto, se vencería mi intento de XSS.

Editar 4: Lo siento, quise decir que podría enviar XMLHttpRequest al dominio de , y luego guardar el resultado de getAllResponseHeaders () en una cadena, eliminar la cookie y publicarla en un dominio externo. Parece que Wikipedia y los hackers están de acuerdo conmigo en esto, pero me encantaría que me reeduquen ...

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 corta con éxito los ataques XSS que se basan en la modificación de las cookies del cliente (no poco común).

Todo se reduce al hecho de que a) ninguna mejora individual resolverá todas las vulnerabilidades yb) ningún sistema será completamente seguro. 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ías con eliminar la restricción.

Answer 8

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 aún permiten el 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 usar 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.

Answer 9

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.

Los scripts no tienen que preocuparse por lo que dice la cookie de sesión: siempre que esté autenticado, cualquier solicitud al servidor iniciada por un usuario o el script 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 only, 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 encantan las cookies HTTP solamente: es una de esas extensiones propietarias de navegador que fue una idea realmente clara.