security - existing - ¿Cómo el rastreador inofensivo omite la autenticación de WebForms y secuestra la sesión de un usuario?
windows authentication c# web application (2)
Aunque la pregunta hace referencia principalmente a identificadores de sesión, la longitud del identificador me pareció inusual.
Hay al menos dos tipos de operaciones de cookie / cookieless que pueden modificar la cadena de consulta para incluir una ID.
- Sesiones sin cookies
- Fichas de autenticación de formularios sin cookies
Son completamente independientes entre sí (por lo que puedo decir).
Estado de sesión
Una sesión sin cookies le permite al servidor acceder a los datos del estado de la sesión basándose en una ID única en la URL frente a una ID única en una cookie. Esto generalmente se considera una buena práctica, aunque ASP.Net reutiliza los identificadores de sesión, lo que lo hace más propenso a los intentos de reparación de la sesión (tema separado pero que vale la pena conocer).
¿La identidad de sesión en ASP.net depende únicamente de la cookie? ¿Puede alguien, desde cualquier IP, con la URL de cookie, acceder a esa sesión? ¿ASP.net no, por defecto, también tiene en cuenta?
El ID de sesión es todo lo que se requiere.
Lectura de seguridad de sesión general
Autenticación de formularios
Según la longitud de los datos de ejemplo, supongo que su URL realmente contiene un valor de autenticación de formularios, no un ID de sesión. El código fuente sugiere que el modo sin cookies no es algo que deba habilitar explícitamente.
/// <summary>ASP.NET determines whether to use cookies based on
/// <see cref="T:System.Web.HttpBrowserCapabilities" /> setting.
/// If the setting indicates that the browser or device supports cookies,
/// cookies are used; otherwise, an identifier is used in the query string.</summary>
UseDeviceProfile
Así es como se hace la determinación:
// System.Web.Security.CookielessHelperClass
internal static bool UseCookieless( HttpContext context, bool doRedirect, HttpCookieMode cookieMode )
{
switch( cookieMode )
{
case HttpCookieMode.UseUri:
return true;
case HttpCookieMode.UseCookies:
return false;
case HttpCookieMode.AutoDetect:
{
// omitted for length
return false;
}
case HttpCookieMode.UseDeviceProfile:
if( context == null )
{
context = HttpContext.Current;
}
return context != null && ( !context.Request.Browser.Cookies || !context.Request.Browser.SupportsRedirectWithCookie );
default:
return false;
}
}
Adivina cuál es el valor predeterminado? HttpCookieMode.UseDeviceProfile . ASP.Net mantiene una lista de dispositivos y capacidades. Esta lista es generalmente una cosa muy mala; por ejemplo, IE11 da un falso positivo por ser un navegador de bajo nivel a la par con Netscape 4.
Causas
Creo que la explicación de Gene es muy probable; Google encontró la URL de alguna acción del usuario y la rastreó.
Es completamente concebible que se considere que el bot de Google no es compatible con las cookies. Pero esto no explica el origen de la URL, es decir, ¿qué acción del usuario provocó que Google viera una URL con una ID ya en ella? Una explicación simple podría ser un usuario con un navegador que se considera que no es compatible con las cookies. Dependiendo del navegador, todo lo demás podría verse bien para el usuario.
El momento, es decir, la duración de la validez parece largo, aunque no estoy tan familiarizado con el tiempo durante el cual los tickets de autenticación son válidos y bajo qué circunstancias podrían renovarse. Es completamente posible que ASP.Net continúe emitiendo / renovando tickets como lo haría para un usuario activo de manera continua.
Soluciones posibles
Estoy haciendo muchas suposiciones aquí, pero si estoy en lo cierto:
- Primero, reproduce el comportamiento en tu entorno.
Deshabilite explícitamente el comportamiento sin
HttpCookieMode.UseCookiesutilizandoHttpCookieMode.UseCookies.web.config :
<authentication mode="Forms"> <forms loginUrl="~/Account/Login.aspx" name=".ASPXFORMSAUTH" timeout="26297438" cookieless="UseCookies" /> </authentication>
Si bien esto debería resolver el comportamiento, puede investigar la extensión del módulo HTTP de autenticación de formularios y agregar una validación adicional (o al menos el registro / diagnóstico).
Anoche, un cliente llamó frenéticamente porque Google había guardado versiones de la información privada de los empleados. La información no está disponible a menos que inicie sesión.
Habían hecho una búsqueda en Google para su dominio, por ejemplo:
site:example.com
y notó que Google había rastreado y almacenado en caché algunas páginas internas.
Mirando las versiones en caché de las páginas yo mismo:
Esta es la caché de Google de https://example.com/(F(NSvQJ0SS3gYRJB4UUcDa1z7JWp7Qy7Kb76XGu8riAA1idys-nfR1mid8Qw7sZH0DYcL64GGiB6FK_TLBy3yr0KnARauyjjDL3Wdf1QcS-ivVwWrq-htW_qIeViQlz6CHtm0faD8qVOmAzdArbgngDfMMSg_N4u45UysZxTnL3d6mCX7pe2Ezj0F21g4w9VP57ZlXQ_6Rf-HhK8kMBxEdtlrEm2gBwBhOCcf_f71GdkI1))/ViewTransaction.aspx?transactionNumber=12345 . Es una instantánea de la página tal como apareció el 15 de septiembre de 2013, a las 00:07:22 GMT
Estaba confundido por el largo url. Más bien que:
https://example.com/ViewTransaction.aspx?transactionNumber=12345
había una larga cadena insertada:
https://example.com/[...snip...]/ViewTransaction.aspx?transactionNumber=12345
Me tomó unos minutos recordar: ese podría ser un síntoma de las "sesiones sin cookies" de ASP.net. Si su navegador no es compatible con Set-Cookie , el sitio web incorporará una cookie en la URL.
Excepto que nuestro sitio no usa eso.
E incluso si nuestro sitio tuviera sesiones sin cookies detectadas automáticamente, y Google lograra convencer al servidor web para que le entregara una sesión en la url, ¿cómo se hizo cargo de la sesión de otro usuario?
Sí, Google un bot no malicioso secuestró una sesión
El sitio ha sido rastreado por los robots durante años. Y el pasado 29 de mayo no fue diferente.
Por lo general, Google comienza su rastreo revisando el archivo robots.txt (no tenemos uno). Pero a nadie se le permite preparar nada en el sitio (incluido el robots.txt ) sin primero ser autenticado, por lo que falla:
Time Uri Port User Name Status
======== ======================= ==== ================ ======
1:33:04 GET /robots.txt 80 302 ;not authenticated, see /Account/Login.aspx
1:33:04 GET /Account/Login.aspx 80 302 ;use https plesae
1:33:04 GET /Account/Login.aspx 443 200 ;go ahead, try to login
Todo ese tiempo Google buscaba un archivo robots.txt. Nunca tuvo uno. Luego vuelve a intentar rastrear la raíz:
Time Uri Port User Name Status
======== ======================= ==== ================ ======
1:33:04 GET / 80 302 ;not authenticated, see /Account/Login.aspx
1:33:04 GET /Account/Login.aspx 80 302 ;use https plesae
1:33:04 GET /Account/Login.aspx 443 200 ;go ahead, try to login
Y otra comprobación de robots.txt en el sitio seguro:
Time Uri Port User Name Status
======== ======================= ==== ================ ======
1:33:04 GET /robots.txt 443 302 ;not authenticated, see /Account/Login.aspx
1:33:04 GET /Account/Login.aspx 443 200 ;go ahead, try to login
Y luego la hoja de estilo en la página de inicio de sesión:
Time Uri Port User Name Status
======== ======================= ==== ================ ======
1:33:04 GET /Styles/Site.css 443 200
Y así es como funciona cada rastreo desde GoogleBot, msnbot y BingBot. Robots, login, seguro, login. Nunca llegar a ningún lado, porque no puede pasar la autenticación de WebForms . Y todo está bien con el mundo.
Hasta que un día; de la nada
Hasta que un día, aparece GoogleBot, ¡con una cookie de sesión en la mano !
Time Uri Port User Name Status
======== ========================= ==== =================== ======
1:49:21 GET / 443 [email protected] 200 ;they showed up logged in!
1:57:35 GET /ControlPanel.aspx 443 [email protected] 200 ;now they''re crawling that user''s stuff!
1:57:35 GET /Defautl.aspx 443 [email protected] 200 ;back to the homepage
2:07:21 GET /ViewTransaction.aspx 443 [email protected] 200 ;and here comes the private information
El usuario, [email protected] no había iniciado sesión durante más de un día. (Esperaba que IIS hubiera dado el mismo identificador de sesión a dos visitantes simultáneos, separados por un reciclado de la aplicación). Y nuestro sitio ( web.config ) no está configurado para habilitar cookies sin sesión. Y el servidor ( machine.config ) no está configurado para habilitar cookies sin sesión.
Asi que:
- ¿Cómo consiguió Google una cookie sin sesión?
- ¿Cómo consiguió Google una cookie válida sin sesión?
- ¿Cómo consiguió Google una cookie válida sin sesión que pertenecía a otro usuario?
Recientemente, el 1 de octubre (hace 4 días), GoogleBot seguía apareciendo, cookie en mano, iniciando sesión como este usuario, rastreando, almacenando en caché y publicando, algunos de sus detalles privados.
¿Cómo es Google un rastreador web no malicioso que pasa por alto la autenticación de WebForms ?
IIS7, Windows Server 2008 R2, servidor único.
Teorias
El servidor no está configurado para dar sesiones sin cookies. Pero ignorando ese hecho, ¿cómo puede Google eludir la autenticación?
- GoogleBot está visitando el sitio web e intenta usar nombres de usuario y contraseñas al azar (no es probable que los registros no muestren ningún intento de inicio de sesión)
- GoogleBot decidió insertar una sesión aleatoria sin cookies en la cadena de URL y coincidió con la sesión de un usuario existente (no es probable)
- El usuario logró averiguar cómo hacer que un sitio web de IIS devuelva una url sin cookies (no es probable) , luego la pegó en otro sitio web (no es probable) , donde Google encontró la url sin cookies y la rastreó
- El usuario está ejecutando a través de proxy móvil (que no lo son) . El servidor proxy no admite cookies, por lo que IIS crea una sesión sin cookies. Ese servidor de almacenamiento en caché (por ejemplo, Opera Mobile ) fue violado (no es probable) y todos los enlaces en caché se publicaron en un foro de hackers. GoogleBot rastreó el foro de hackers y comenzó a seguir todos los enlaces; Incluyendo nuestra
[email protected]sesión sin[email protected][email protected]. - El usuario tiene un virus, que logra engatusar a los servidores web de IIS para que devuelvan una URL sin cookies. Ese virus luego informa a la sede. Las direcciones URL se publican en un recurso de acceso público, que rastrea GoogleBot. GoogleBot luego aparece en nuestro servidor con la URL sin cookies.
Ninguno de estos es realmente plausible.
¿Cómo puede Google un rastreador web no maléxico omitir la autenticación de WebForms y secuestrar la sesión existente de un usuario?
¿Que estas preguntando?
Ni siquiera sé cómo un sitio web ASP.net, que no está configurado para dar sesiones sin cookies, podría dar una sesión sin cookies. ¿Es posible volver a convertir un identificador de sesión basado en cookies en un identificador de sesión basado en cookies ? Podría citar la sección <sessionState> relevante de web.config y machine.config , y mostrar que no hay presencia de
<sessionState cookieless="true">
¿Cómo decide el servidor web que el navegador no admite cookies? Intenté bloquear las cookies en Chrome y nunca me dieron un identificador de sesión sin cookies. ¿Puedo simular un navegador que no admite cookies, para verificar que mi servidor no está ofreciendo sesiones sin cookies?
¿El servidor decide sesiones sin cookies por cadena User-Agent ? Si es así, podría configurar Internet Explorer con un UA falsificado.
¿La identidad de sesión en ASP.net depende únicamente de la cookie? ¿Puede alguien, desde cualquier IP, con la URL de cookie, acceder a esa sesión? ¿ASP.net no, por defecto, también tiene en cuenta?
Si ASP.net vincula la dirección IP con la sesión, ¿no significaría eso que la sesión no pudo haberse originado desde el empleado en la computadora de su casa? Porque entonces, cuando el rastreador GoogleBot intentó usarlo desde una IP de Google, ¿habría fallado?
¿Ha habido instancias en algún lugar (además de la que vinculé) de ASP.net que da sesiones sin cookies cuando no está configurado? ¿Hay un problema de Microsoft Connect en esto?
¿Se sabe que la autenticación de Web-Forms tiene problemas y no se debe utilizar para seguridad?
Lectura de bonos
Edición : Se eliminó el nombre de Google del bot que evitó el privilegio, ya que las personas tienen los pantalones en la cabeza con retraso; Confundiendo a Google el nombre del rastreador por otra cosa. Utilizo el nombre del rastreador de Google como recordatorio de que fue un rastreador web no malintencionado que logró rastrear su camino hacia la sesión de WebForm de otro usuario. Esto es para contrastarlo con un rastreador malintencionado que intentaba ingresar a la sesión de otro usuario. Nada como un pedante para poner de manifiesto la agravación.
Pediste pensamientos, así que daré algunos. Ninguna garantía expresa o implícita.
Renuncie a la idea de que su sitio está configurado para no codificar información de sesión en URI. Con muy alta probabilidad lo hizo. O está equivocado acerca de la configuración o (lo más probable) hay un error que lo causó.
Eso deja la pregunta central: ¿cómo obtuvo Google la URI de sesión?
No dijiste nada sobre la base de clientes. Aquí hay una conjetura:
Un cliente inició sesión en el sistema de una manera que produjo una codificación URI de la sesión, luego lo envió por correo electrónico usando una cuenta de gmail a otra persona. Google analizó el correo electrónico y proporcionó el URI al robot rastreador.
Hay otras formas similares en que un cliente cuyo cliente produjo el URI podría entregarlo inadvertidamente a Google. Documento de Google Drive. Publicación de Google Plus. Etc.
Google no puede ser malo, pero sin embargo están en todas partes. Su acuerdo de uso les permite mover los enlaces a través de los límites del producto, en este caso, el correo (etc.) para buscar.
La pregunta real en la que debería pensar es por qué su sitio no está protegido contra la falsificación de solicitudes entre sitios. La gente de Rails lo explica muy bien . El mecanismo de Rails protect_from_forgery hubiera evitado el problema reportado.
Una pregunta relacionada es por qué la cookie codificada (aparentemente) nunca caduca. Debería ser fácil hacer que las sesiones contengan marcas de tiempo para que esto sea así.