1. Princípio do ataque
A falsificação de cookies usa principalmente a prática insegura de armazenar informações de login de usuários em cookies na rede atual.
Sabemos que um sistema de usuário baseado em cookies geral armazenará pelo menos duas variáveis em cookies: nome de usuário e nível de usuário, onde o nome de usuário é o nome de usuário e o nível do usuário é o nível do usuário. Quando nosso navegador acessa a página ASP, ele emitirá algo como
Get /.../file.asp http 1.0
...
Cookies: Nome de usuário = Usuário e UserLevel = 1
...
Então, enquanto conhecemos o nome de usuário e os valores de nível de usuário do administrador (assumindo o administrador e 5 respectivamente), podemos transferi -lo
Get /.../file.asp http 1.0
...
Cookies: nome de usuário = admin & userLevel = 5
...
Para obter permissões de administrador. Muito simples, certo? No entanto, antes que a vulnerabilidade fosse descoberta, quase todos os sistemas de gerenciamento de usuários se baseavam em cookies.
2. Armazene com segurança as informações do usuário
Como os cookies são inseguros e devemos armazenar informações de login de usuários, onde eles devem ser armazenados?
Percebemos que, no ASP, além dos cookies, também há uma sessão que pode armazenar informações. A sessão é armazenada no servidor e não pode ser alterada pelo cliente à vontade, por isso tem segurança extremamente alta. Dessa forma, todos podem alterar o código de todos os cookies para sessão.
3. Informações do usuário da loja por um longo tempo
A sessão é usada para salvar informações de login de usuários. Método descrito nesta seção é gerado.
Existem duas variantes deste método. Forneça -o de acordo com os cookies. O código para implementar este método é o seguinte:
VBS:
<%
Dim Nome de usuário, senha
nome de usuário = sessão (nome de usuário)
Se nome de usuário = então
'Não há informações de login de usuário na sessão
nome de usuário = request.cookies (nome de usuário)
senha = request.cookies (senha)
'Preste atenção ao nome de usuário e senha obtidos nas duas frases acima para impedir a vulnerabilidades de injeção de SQL (ou seja, filtrar as citações únicas'), omitidas aqui
Se nome de usuário = ou senha = então
'O usuário não está conectado
...
outro
'Aqui é assumido que os objetos Conn e RS foram criados
Rs.Open Selecione Top 1 * FROM [Usuário] WHERE WHERE UserName = '& Nome de usuário &' e Senha = '& Senha &', Conn, 1, 3
Se rs.eof então
'As informações nos cookies são ilegais
...
outro
'As informações nos cookies são legais e efetuadas automaticamente
Sessão (nome de usuário) = nome de usuário
...
final se
final se
outro
'As informações do usuário já existem na sessão e são lidas diretamente
...
final se
%>
JS:
<%
VAR nome de usuário, senha;
nome de usuário = sessão (nome de usuário) +;
if (nome de usuário == || nome de usuário == indefinido) {
// Não há informações do usuário na sessão
nome de usuário = request.cookies (nome de usuário) +;
senha = request.cookies (senha) +;
// preste atenção ao nome de usuário e senha obtidos nas duas frases acima para impedir a vulnerabilidades de injeção de SQL (ou seja, filtrar as citações únicas '), omitidas aqui
if (nome de usuário == || nome de usuário == indefinido || senha == || senha == indefinido) {
// o usuário não está conectado
...
}
outro {
// aqui é assumido que os objetos Conn e RS foram criados
rs.open (selecione Top 1 * do [usuário] onde o nome de usuário = ' + nome de usuário +' e senha = ' + senha +', Conn, 1, 3);
if (rs.eof) {
// as informações nos cookies são ilegais
...
}
outro {
// As informações em cookies são legais e efetuadas automaticamente
Sessão (nome de usuário) = nome de usuário +;
...
}
}
}
outro {
// As informações do usuário já existem na sessão e são lidas diretamente
...
}
%>
No entanto, esse método não é muito seguro para os usuários, porque o navegador transmitirá cookies toda vez que visitar a página, e a conta do usuário será roubada assim que os cookies que contêm a senha forem obtidos por outras. Para este caso, aparece um segundo método, ou seja, adicione um código de verificação de campo ao banco de dados de informações do usuário. O valor do código é adicionado. Ao verificar as informações do usuário em cookies, apenas o nome de usuário e o código verificado são verificados. A vantagem desse método é que, mesmo que os cookies do usuário sejam obtidos por um hacker, ele só pode usar esse código de verificação temporário para fazer login e não pode obter a senha do usuário. Enquanto esse usuário efetuar login com o nome de usuário e a senha novamente, o valor verificadoCode alterará e o hacker não poderá fazer login através do código de verificação original.
A implementação desse método requer apenas pequenas alterações no código do método mencionado acima. Primeiro, em seu programa de login, você precisa adicionar um parágrafo onde a verificação passa para armazenar informações do usuário:
VBS:
<%
Response.Cookies (VerifyCode) = int (RND * 2100000000)
%>
JS:
<%
Response.Cookies (VerifyCode) = Math.Floor (Math.random () * 2100000000);
%>
Em seguida, no código de verificação fornecido acima, altere a verificação de cookies (senha) para a verificação de cookies (verifique o código).
4. Conclusão
Através de nossa análise e processamento, a vulnerabilidade dos cookies foi completamente resolvida e, desde então, nossos programas ASP se tornaram mais seguros.
2007-08-05 20:37 A escrita começa
2007-08-05 21:14 A primeira edição foi concluída