Como prevenir melhor os ataques de hackers, gostaria de dar a minha opinião pessoal! Primeiro, programas gratuitos não devem ser usados gratuitamente. Como você pode compartilhar o código original, os invasores também podem analisá-lo. Se você prestar atenção aos detalhes, a segurança do seu site melhorará muito. Mesmo que ocorra uma vulnerabilidade como SQL Injection, é impossível para um invasor derrubar seu site imediatamente.
Devido à conveniência e facilidade de uso do ASP, cada vez mais programas em segundo plano de sites usam a linguagem de script ASP. No entanto, como o próprio ASP tem algumas vulnerabilidades de segurança, os hackers podem tirar vantagem disso se não tomarem cuidado. Na verdade, a segurança não é uma questão apenas dos administradores de rede, os programadores também devem prestar atenção a certos detalhes de segurança e desenvolver bons hábitos de segurança, caso contrário, isso trará enormes riscos de segurança aos seus sites. Atualmente, a maioria dos programas ASP em sites possui falhas de segurança de um tipo ou de outro, mas se você prestar atenção ao escrever programas, elas ainda poderão ser evitadas.
1. Nome de usuário e senha são quebrados.
Princípio de ataque: Nome de usuário e senha são frequentemente os que mais interessam aos hackers. Se o código-fonte for visto de alguma forma, as consequências serão graves.
Habilidades de prevenção: Programas que envolvem nomes de usuário e senhas são melhor encapsulados no lado do servidor e aparecem o menos possível em arquivos ASP. Nomes de usuário e senhas que envolvem conexões de banco de dados devem receber permissões mínimas. Nomes de usuário e senhas que aparecem com frequência podem ser gravados em um arquivo de inclusão oculto. Se envolver conexão com o banco de dados, o ideal é conceder permissão apenas para executar procedimentos armazenados. Nunca dê permissão direta ao usuário para modificar, inserir ou excluir registros.
2. Verificação ignorada
princípio de ataque: A maioria dos programas ASP que precisam ser verificados agora adicionam uma declaração de julgamento ao cabeçalho da página, mas isso não é suficiente. É possível que os hackers ignorem a verificação e entrem diretamente.
Habilidades de prevenção: as páginas ASP que precisam ser verificadas podem rastrear o nome do arquivo da página anterior. Somente as sessões transferidas da página anterior podem ler esta página.
3. Problema de vazamento de arquivo Inc
Princípio de ataque: Quando a página inicial com ASP está sendo produzida e não foi finalizada antes da depuração, ela pode ser adicionada automaticamente como objeto de pesquisa por alguns mecanismos de pesquisa. Se alguém usar um mecanismo de busca para pesquisar essas páginas da web neste momento, obterá a localização dos arquivos relevantes e poderá visualizar os detalhes da localização e estrutura do banco de dados no navegador, revelando assim o código-fonte completo.
Dicas de prevenção: Os programadores devem depurar completamente as páginas da web antes de publicá-las. Os especialistas em segurança precisam proteger os arquivos ASP para que usuários externos não possam vê-los; Primeiro, criptografe o conteúdo do arquivo .inc. Em segundo lugar, você também pode usar o arquivo .asp em vez do arquivo .inc para que os usuários não possam visualizar diretamente o código-fonte do arquivo no navegador. O nome do arquivo inc não deve usar o padrão do sistema ou um nome com significado especial que seja fácil de ser adivinhado pelos usuários. Tente usar letras inglesas irregulares.
4. Princípio do ataque de download de backup automático
: Em algumas ferramentas para edição de programas ASP, ao criar ou modificar um arquivo ASP, o editor cria automaticamente um arquivo de backup. Por exemplo, o UltraEdit fará backup de um arquivo .bak se você criar ou modificar o After. modificando some.asp, o editor irá gerar automaticamente um arquivo chamado some.asp.bak. Se você não excluir este arquivo bak, o invasor poderá baixar diretamente o arquivo some.asp.bak, para que o programa fonte de some.asp. será baixado.
Dicas de prevenção: Verifique seu programa cuidadosamente antes de carregá-lo e exclua documentos desnecessários. Tenha especial cuidado com arquivos com o sufixo BAK.
5.
Princípio do ataque de caracteres especiais: A caixa de entrada é alvo de hackers. Eles podem causar danos ao cliente do usuário ao inserir linguagem de script; se a caixa de entrada envolver consulta de dados, eles usarão instruções de consulta especiais para obter mais dados do banco de dados; ou até mesmo a mesa inteira. Portanto, a caixa de entrada deve ser filtrada. No entanto, se a verificação de validade de entrada for realizada apenas no cliente para melhorar a eficiência, ela ainda poderá ser ignorada.
Habilidades de prevenção: Em programas ASP que lidam com caixas de entrada, como quadros de mensagens e BBS, é melhor bloquear instruções HTML, JavaScript e VBScript. Se não houver requisitos especiais, você poderá limitar a entrada de letras e números apenas a letras e números. números e bloquear caracteres especiais. Ao mesmo tempo, o comprimento dos caracteres de entrada é limitado. E não apenas a verificação de validade de entrada deve ser realizada no lado do cliente, mas verificações semelhantes devem ser realizadas no programa do lado do servidor.
6.
Princípio do ataque de vulnerabilidade de download de banco de dados: Ao usar o Access como banco de dados de back-end, se alguém souber ou adivinhar o caminho e o nome do banco de dados Access do servidor por meio de vários métodos, ele também poderá baixar o arquivo de banco de dados Access, o que é muito perigoso . de.
Dicas de prevenção:
(1) Dê ao seu arquivo de banco de dados um nome complexo e não convencional e coloque-o em vários diretórios. O chamado "não convencional", por exemplo, se existe um banco de dados que deseja salvar informações sobre livros, não dê o nome "book.mdb", mas dê um nome estranho, como d34ksfslf. e coloque-o em vários diretórios, como ./kdslf/i44/studi/, para que seja ainda mais difícil para os hackers obterem seu arquivo de banco de dados do Access adivinhando.
(2) Não escreva o nome do banco de dados no programa. Algumas pessoas gostam de escrever DSN no programa, por exemplo:
DBPath = Server.MapPath("cmddb.mdb")
conn.Open "driver={Microsoft Access Driver (*.mdb)};dbq=" & DBPath
Se alguém obtiver o programa de origem, o nome do seu banco de dados Access ficará visível rapidamente. Portanto, é recomendável definir a fonte de dados em ODBC e, em seguida, escrever isto no programa:
conn.open "shujiyuan"
(3) Use o Access para codificar e criptografar o arquivo de banco de dados. Primeiro, selecione o banco de dados (como: funcionário.mdb) em "Ferramentas → Segurança → Criptografar/Descriptografar banco de dados" e, em seguida, clique em OK. Em seguida, a janela "Salvar como do banco de dados criptografado" aparecerá. .mdb".
Deve-se observar que a ação acima não define uma senha para o banco de dados, mas apenas codifica o arquivo do banco de dados. O objetivo é evitar que outras pessoas utilizem outras ferramentas para visualizar o conteúdo do arquivo do banco de dados.
Em seguida, criptografamos o banco de dados. Primeiro, abra o Employee1.mdb codificado. Ao abrir, selecione o modo "exclusivo". Em seguida, selecione "Ferramentas → Segurança → Definir senha do banco de dados" no menu e digite a senha. Dessa forma, mesmo que outra pessoa obtenha o arquivo Employee1.mdb, ela não poderá ver o conteúdo de Employee1.mdb sem a senha.
7. Prevenir ataques de injeção remota.
Esse tipo de ataque deveria ser um método de ataque relativamente comum no passado, como o ataque POST. O invasor pode alterar o valor dos dados a serem enviados à vontade para atingir o objetivo do ataque. Falsificação de COOKIES, que vale mais a pena. Isso chama a atenção do programador ou webmaster. Não use COOKIES como método de autenticação do usuário. Caso contrário, você está deixando a chave para um
ladrão
.
uname"))=" fqy" e Request.cookies("upwd") ="fqy#e3i5.com" então
……..mais…………
Fim se
eu achar que todos os webmasters ou amigos que gostam de escrever programas não devem cometer esse tipo de erro. É realmente imperdoável. Temos forjado COOKIES há muitos anos. senha. Envolve Quando se trata de senhas de usuário ou login de usuário, é melhor usar session, que é o mais seguro. Se você quiser usar COOKIES, adicione mais uma informação aos seus COOKIES, SessionID. Seu valor aleatório é. 64 bits. Você precisa adivinhar, impossível. Exemplo:
se não (rs.BOF ou rs.eof), então.
login = "verdadeiro"
Sessão("nomedeusuário"&sessionID) = Nome de usuário
Sessão("senha"& sessionID) = Senha
'Response.cookies("nome de usuário")= Nome de usuário
'Response.cookies("Password") = Password
Vamos falar sobre como evitar ataques de injeção remota. O ataque geral é arrastar o arquivo de envio de formulário único para o local e apontar o Form ACTION="chk.asp" para o seu servidor.
processamento. Arquivos de dados são suficientes. Se toda a sua filtragemde
dados estiver em uma única página da tabela, parabéns, você terá sido atacado por um script.
segue: Corpo do programa (9)
＜%
server_v1=Cstr(Request.ServerVariables("HTTP_REFERER"))
server_v2=Cstr(Request.ServerVariables("SERVER_NAME"))
se mid(servidor_v1,8,len(servidor_v2))＜＞servidor_v2 então
resposta.write "＜br＞＜br＞＜centro>"
resposta.write " "
response.write "O caminho que você enviou está errado. O envio de dados de fora do site é proibido. Por favor, não altere os parâmetros!"
resposta.write "
"
resposta.fim
terminar se
%>
'Pessoalmente, sinto que a filtragem de código acima não é muito boa. Alguns envios externos ainda podem chegar abertamente, então escrevi outro
'Este efeito de filtragem é muito bom, é recomendado usar
if instr(request
..servervariables("http_referer" )," http://"&request.servervariables("host ") )<1 then response.write "Ocorreu um erro no servidor ao processar a URL.
Se você estiver atacando o servidor por qualquer meio , então você deve ter sorte porque todas as suas operações foram registradas pelo servidor. Notificaremos o Departamento de Segurança Pública e o Departamento de Segurança Nacional o mais rápido possível para investigar seu IP "
response.end
.
terminar se
O corpo do programa (9)
achou que tudo ficaria bem com isso, e adicionou algumas restrições na página do formulário, como maxlength, etc... Mas Deus é tão cruel, quanto mais você tem medo de alguma coisa, mais provável é que isso aconteça. será. Não se esqueça, o autor do ataque pode ultrapassar o limite do comprimento da caixa de entrada durante os ataques de injeção de SQL. Escreva um programa SOCKET para alterar o HTTP_REFERER? Eu não vou. Tal artigo foi publicado online:
------------len.reg-----------------
Editor de registro do Windows versão 5.00
[HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMenuExtExtensões]
@="C:Documents and SettingsAdministradorDesktoplen.htm"
"contextos"=dword:00000004
----------fim---------------------
----------len.htm------------------
----------fim--------------------------
Uso: Primeiro importe len.reg para o registro (observe o caminho do arquivo)
e em seguida, copie len.htm para o local especificado no registro.
Abra a página da web, coloque o cursor na caixa de entrada onde o comprimento deve ser alterado e clique com o botão direito. Se você vir uma opção chamada extensão,
clique em Concluído! : O mesmo pode ser feito.
Como lidar
com scripts que restringem o conteúdo de entrada ?Nossas limitações foram poupadas e todos os nossos esforços desperdiçados? Não, segure o teclado e diga não. Voltemos à filtragem de caracteres de script. A injeção que eles realizam nada mais é do que ataques de script. Vamos colocar toda a nossa energia nas páginas após ACTION. Na página chk.asp, filtramos todos os caracteres ilegais. Apenas demos um tiro falso na nossa frente e pedimos que alterassem o registro. Só quando terminarem as alterações é que perceberão que o que fizeram foi em vão.
8.
Já falamos sobre o cavalo de Tróia ASP aqui e gostaria de lembrar a todos os webmasters do fórum que tenham cuidado ao enviar arquivos: Por que o host também é ocupado por invasores depois que o programa do fórum é quebrado? A razão é...certa! Trojan ASP! Uma abominação absoluta. Vírus? Não. Basta colocar o arquivo no programa do seu fórum e você sempre poderá procurá-lo. Seria estranho não vomitar sangue. Como podemos evitar que Trojans ASP sejam carregados no servidor? O método é muito simples. Se o seu fórum suporta upload de arquivos, defina o formato de arquivo que deseja enviar. Não concordo com o uso de formatos de arquivo alteráveis. completo. Sim, deixar mais comodidade para você também deixará mais comodidade para os invasores. Como determinar o formato? Coletei um aqui e modifiquei um. Você pode dar uma olhada:
Corpo do programa (10)
'Julgue se o tipo de arquivo é qualificado.
dim upload do fórum
Fórumupload="gif,jpg,bmp,jpeg"
Forumupload=dividir(Forumupload,",")
para i=0 para ubound(Forumupload)
se lcase(fileEXT)=lcase(trim(Forumupload(i))) então
CheckFileExt = verdadeiro
função de saída
outro
CheckFileExt=falso
terminar se
próximo
Função final
'Verifique a legalidade do conteúdo do arquivo
definido MyFile = server.CreateObject ("Scripting.FileSystemObject")
set MyText = MyFile.OpenTextFile (sFile, 1) ' Ler arquivo de texto sTextAll = lcase(MyText.ReadAll): MyText.close
'Determinar operações perigosas em arquivos de usuário sStr = "8 .getfolder .createfolder .deletefolder .createdirectory
.deletediretório"
sStr = sStr & ".saveas wscript.shell script.encode"
sNoString = divisão(sStr," ")
para i = 1 para sNoString(0)
se instr(sTextAll, sNoString(i)) ＜＞ 0 então
sFile = Upl.Path & sFileSave: fs.DeleteFile sFile
Response.write "＜center＞＜br＞＜big＞"& sFileSave &"O arquivo contém comandos relacionados a diretórios operacionais, etc."&_
"＜br＞＜font color=red＞"& mid(sNoString(i),2) &"＜/font＞, por motivos de segurança, ＜b＞ não pode ser carregado. ＜b＞"&_"＜/big＞＜ /centro＞＜/html＞"
Resposta.fim
terminar se
PróximoAdicione-
e
a segurança do seu programa de upload será bastante melhorada.
Você ainda está preocupado? Crie seu trunfo e peça ajuda ao seu provedor de serviços de hospedagem na web. Faça login no servidor e renomeie ou exclua os itens "shell.application" e "shell.application.1" no ID do PROG. Em seguida, renomeie ou exclua o item "WSCRIPT.SHELL" e "WSCRIPT.SHELL.1". Haha, posso dizer com ousadia que provavelmente mais da metade dos hosts virtuais na China não mudaram. Só posso ficar feliz que seus usuários sejam muito cooperativos, caso contrário... vou deletar, vou deletar, vou deletar, deletar, deletar...