Como o crawler inofensivo ignorou a autenticação do WebForms e seqüestrou a sessão de um usuário?
Ontem à noite, um cliente ligou, frenético, porque o Google tinha em cache versões de informações de funcionários particulares. As informações não estão disponíveis, a menos que você faça o login.
Eles fizeram uma pesquisa no Google por seu domínio, por exemplo:
site:example.com
e notou que o Google havia rastreado e armazenou algumas páginas internas.
Olhando para as versões em cache das páginas eu mesmo:
Este é o cache do Google dehttps://example.com/(F(NSvQJ0SS3gYRJB4UUcDa1z7JWp7Qy7Kb76XGu8riAA1idys-nfR1mid8Qw7sZH0DYcL64GGiB6FK_TLBy3yr0KnARauyjjDL3Wdf1QcS-ivVwWrq-htW_qIeViQlz6CHtm0faD8qVOmAzdArbgngDfMMSg_N4u45UysZxTnL3d6mCX7pe2Ezj0F21g4w9VP57ZlXQ_6Rf-HhK8kMBxEdtlrEm2gBwBhOCcf_f71GdkI1))/ViewTransaction.aspx?transactionNumber=12345. É um instantâneo da página como apareceu em 15 set 2013 00:07:22 GMT
Eu estava confuso com a longa URL. Ao invés de:
https://example.com/ViewTransaction.aspx?transactionNumber=12345
havia um longo fio inserido:
https://example.com/[...snip...]/ViewTransaction.aspx?transactionNumber=12345
Demorei alguns minutos para lembrar: isso pode ser umsintoma de ASP.net"sessões sem cookies". Se o seu navegador não suportarSet-Cookie, o site incluirá um cookie no URL.
Exceto nosso site não usa isso.
E mesmo se o nosso sitefez as sessões sem cookie foram detectadas automaticamente, e o Google conseguiu persuadir o servidor da Web a entregar uma sessão na URL. Como isso assumiu a sessão de outro usuário?
Sim,Google um bot não mal intencionado sequestrou uma sessãoO site foi rastreado por bots por anos. E no passado dia 29 de maio não foi diferente.
O Google geralmente inicia seu rastreamento verificando orobots.txt arquivo (não temos um). Mas ninguém está autorizado a preparar nada no site (incluindorobots.txt) sem primeiro ser autenticado, por isso falha:
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 esse tempo o Google estava procurando por um arquivo robots.txt. Nunca conseguiu um. Em seguida, ele retorna para tentar rastrear a raiz:
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
E outra verificação de robots.txt no site 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
E então a folha de estilo na página de login:
Time Uri Port User Name Status
======== ======================= ==== ================ ======
1:33:04 GET /Styles/Site.css 443 200
E é assim que todos os rastreamentos do GoogleBot, do msnbot e do BingBot funcionam. Robôs, login, seguro, login. Nunca chegar a lugar nenhum, porque não pode passarAutenticação de WebForms. E tudo está bem com o mundo.
Até um dia; do nadaAté que um dia, o GoogleBot aparece, com um cookie de sessãoem mão!
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
O usuário,[email protected] não estava logado há mais de um dia. (Eu esperava que o IIS tivesse o mesmo identificador de sessão para dois visitantes simultâneos, separados por uma reciclagem de aplicativo). E o nosso site (web.config) não está configurado para permitir cookies sem sessão. E o servidor (machine.config) não está configurado para permitir cookies sem sessão.
Assim:
Como o Google conseguiu um cookie sem sessão?como o Google conseguiu umválido cookie sem sessão?como o Google conseguiu umválido cookie sem sessão que pertencia a outro usuário?Recentemente, em 1º de outubro (4 dias atrás), o GoogleBotainda aparecendo, cookie em mãos, fazendo login como usuário, rastreando, armazenando em cache e publicando alguns de seus detalhes privados.
Como éGoogle um rastreamento não-malicioso do rastreador da WebWebForms autenticação?
IIS7, Windows Server 2008 R2, servidor único.
TeoriasO servidor não está configurado para fornecer sessões sem cookies. Mas, ignorando esse fato, como o Google pode ignorar a autenticação?
O GoogleBot está visitando o site e tentando nomes de usuários e senhas aleatórios(provavelmente, os logs não mostram tentativas de login)O GoogleBot decidiu inserir uma sessão aleatória sem cookies na sequência de URL, e ela coincidiu com a sessão de um usuário existente(não é provável)O usuário conseguiu descobrir como fazer com que um site da Web do IIS retornasse um URL sem cookies(não é provável), em seguida, colou esse URL em outro site(não é provável), onde o Google encontrou o URL sem cookies e o rastreouO usuário está executando por meio do proxy móvel(que eles não são). O servidor proxy não suporta cookies, portanto, o IIS cria uma sessão sem cookies. Isso (por exemploOpera Mobile) servidor de cache foi violado(não é provável) e todos os links em cache postados em um fórum de hackers. O GoogleBot rastreou o fórum de hackers e começou a seguir todos os links. incluindo nosso[email protected] url de sessão cookieless.O usuário tem um vírus, que consegue convencer qualquer servidor web IIS a devolver um URL sem cookies. Esse vírus então informa a sede. Os URLs são postados em um recurso de acesso público que o GoogleBot rastreia. O GoogleBot, em seguida, aparece no nosso servidor com o URL sem cookies.Nada disso é realmente plausível.
Como podeGoogle um web-crawler não-maleável ignora a autenticação WebForms e seqüestra uma sessão existente do usuário?
O que você está perguntando?Eu nem seicomo Um site da Web da ASP.net, que não está configurado para distribuir sessões sem cookies, poderia fornecer uma sessão sem cookies. É possível converter umID de sessão baseada em cookie para dentro a ID de sessão baseada em cookieless? Eu poderia citar o relevante<sessionState> Seção deweb.config emachine.config, e mostrar que não há presença de
<sessionState cookieless="true">
Como o servidor web decide que o navegador não suporta cookies? Tentei bloquear cookies no Chrome e nunca recebi um identificador de sessão sem cookies. Posso simular um navegador que não suporta cookies, a fim de verificar se meu servidor não oferece sessões sem cookies?
O servidor decide sessões cookieless porAgente de usuário corda? Se assim for, eu poderia definir o Internet Explorer com um UA falsificado.
A identidade da sessão no ASP.net depende exclusivamente do cookie? Alguém pode, de qualquer IP, com o cookie-URL, acessar essa sessão? O ASP.net não, por padrão, também leva em consideração?
Se ASP.netfaz empate endereço IP com a sessão, isso não significaria que a sessão não poderia ter se originado do funcionário em seu computador de casa? Porque, quando o rastreador do GoogleBot tentou usá-lo de um IP do Google, ele teria falhado?
Tem havido alguma instância em qualquer lugar (além da que eu liguei) do ASP.net dando sessões cookieless quando não está configurado para? Existe um problema do Microsoft Connect sobre isso?
A autenticação de formulários da Web é conhecida por ter problemas e não deve ser usada para segurança?
Leitura de bônusUm cara no StackOverflow que é servidor da Web às vezes está dando URLs sem cookies quando não está configurado paraEditar: Nome removido deGoogle o bot que ignorou o privilégio, já que as pessoas estão com as calças na cabeça retardadas; confusoGoogle o nome do rastreador para outra coisa. eu usoGoogle o nome do rastreador como um lembrete de que ele era um rastreador da Web não mal-intencionado que conseguiu rastrear o caminho até a sessão do WebForm de outro usuário. Isso é para contrastar isso com um rastreador malicioso, que estava tentando invadir a sessão de outro usuário. Nada como um pedante para expor o agravamento.