Quais são as práticas recomendadas para proteger a seção administrativa de um site? [fechadas]


92

Eu gostaria de saber o que as pessoas consideram a prática recomendada para proteger as seções Admin de sites, especificamente do ponto de vista de autenticação / acesso.

Claro que há coisas óbvias, como usar SSL e registrar todo o acesso, mas estou me perguntando onde, acima dessas etapas básicas, as pessoas consideram a barreira a ser definida.

Por exemplo:

  • Você está contando apenas com o mesmo mecanismo de autenticação que usa para usuários normais? Se não, o quê?
  • Você está executando a seção Admin no mesmo 'domínio de aplicativo'?
  • Quais etapas você executa para tornar a seção administrativa desconhecida? (ou você rejeita toda a coisa de 'obscuridade')

Até agora, as sugestões dos respondentes incluem:

  • Introduzir uma pausa artificial do lado do servidor em cada verificação de senha de administrador para evitar ataques de força bruta [Arte do desenvolvedor]
  • Use páginas de login separadas para usuários e admin usando a mesma tabela de banco de dados (para impedir o XSRF e o roubo de sessão que concede acesso às áreas administrativas) [Thief Master]
  • Considere também adicionar autenticação nativa do servidor da web à área administrativa (por exemplo, via .htaccess) [Thief Master]
  • Considere bloquear o IP de usuários após uma série de tentativas de login de administrador malsucedidas [Thief Master]
  • Adicionar captcha após falhas nas tentativas de login de administrador [Thief Master]
  • Fornece mecanismos igualmente fortes (usando as técnicas acima) para usuários e administradores (por exemplo, não trate os administradores de maneira especial) [Lo'oris]
  • Considere a autenticação de segundo nível (por exemplo, certificados de cliente, cartões inteligentes, cardspace, etc.) [JoeGeeky]
  • Permita apenas o acesso de IPs / domínios confiáveis, adicione a verificação ao pipeline HTTP básico (por exemplo, HttpModules) se possível. [JoeGeeky]
  • [ASP.NET] Bloqueie IPrincipal & Principal (torne-os imutáveis ​​e não enumeráveis) [JoeGeeky]
  • Federar Elevação de Direitos - por exemplo, enviar e-mail para outros administradores quando os direitos de algum administrador forem atualizados. [JoeGeeky]
  • Considere direitos refinados para administradores - por exemplo, em vez de direitos baseados em funções, defina direitos para ações indicativas por administrador [JoeGeeky]
  • Restrinja a criação de administradores - por exemplo, os administradores não podem alterar ou criar outras contas de administrador. Use um cliente 'superadmin' bloqueado para isso. [JoeGeeky]
  • Considere certificados SSL do lado do cliente ou keyfobs do tipo RSA (tokens eletrônicos) [Daniel Papasian]
  • Se usar cookies para autenticação, use cookies separados para páginas administrativas e normais, por exemplo, colocando a seção de administração em um domínio diferente. [Daniel Papasian]
  • Se for prático, considere manter o site de administração em uma sub-rede privada, fora da Internet pública. [John Hartsock]
  • Emita novamente tíquetes de autenticação / sessão ao alternar entre contextos de uso administrativo / normal do site [Richard JP Le Guen]

2
Apenas um pensamento, mas. Provavelmente, a melhor maneira de proteger a seção de administração é não tê-la na Internet pública. Você pode escolher manter o site de administração apenas em uma sub-rede privada.
John Hartsock de

1
Qual das ideias que você especificou não seria uma boa ideia aplicar a todos os usuários, não apenas aos administradores?
Vivian River

Você pode querer verificar WebLoginProject em webloginproject.com , é um sistema de login colaborativo projetado para ser seguro contra vulnerabilidades de XSS, injeção de SQL, fixação de sessão e CSRF. Tem código-fonte em ASP e PHP, é multilíngue e tem um visual legal. Muitos desenvolvedores estão trabalhando para consertar buracos, então isso é provavelmente o mais seguro possível.
stagas

-1 por incluir a sugestão de "senha forte" terrivelmente errada (que na verdade é uma senha muito fraca)
o0 '.

@Lohoris - Eu realmente não entendo porque você votou contra esta questão. Você está downvoting porque sumarizei a sugestão de alguém com a qual você não concorda? Talvez downvoting a resposta relacionada seja mais construtivo. : / Você pode esclarecer exatamente qual é o seu problema?
UpTheCreek

Respostas:


18

Todas essas são boas respostas ... Eu geralmente gosto de adicionar algumas camadas adicionais para minhas seções administrativas. Embora eu tenha usado algumas variações de um tema, elas geralmente incluem um dos seguintes:

  • Autenticação de segundo nível : pode incluir certificados de cliente (por exemplo, certificados x509), cartões inteligentes, espaço para cartões, etc ...
  • Restrições de domínio / IP : neste caso, apenas clientes provenientes de domínios confiáveis ​​/ verificáveis; como sub-redes internas; são permitidos na área administrativa. Os administradores remotos costumam passar por pontos de entrada VPN confiáveis ​​para que sua sessão seja verificável e, muitas vezes, também é protegida com chaves RSA. Se estiver usando ASP.NET, você pode realizar facilmente essas verificações no Pipeline HTTP por meio de módulos HTTP, o que evitará que seu aplicativo receba solicitações se as verificações de segurança não forem satisfeitas.
  • Autorização baseada em IPrincipal & Principal bloqueada : Criar princípios personalizados é uma prática comum, embora um erro comum seja torná-los modificáveis ​​e / ou enumeráveis ​​por direitos. Embora não seja apenas um problema de administrador, é mais importante, pois é aqui que os usuários provavelmente têm direitos elevados. Certifique-se de que são imutáveis ​​e não enumeráveis. Além disso, certifique-se de que todas as avaliações para autorização sejam feitas com base no Principal.
  • Elevação de direitos federados : Quando qualquer conta recebe um número selecionado de direitos, todos os administradores e o oficial de segurança são imediatamente notificados por e-mail. Isso garante que, se um invasor elevar os direitos, saberemos imediatamente. Esses direitos geralmente giram em torno de direitos privilegiados, direitos de ver informações protegidas por privacidade e / ou informações financeiras (por exemplo, cartões de crédito).
  • Emita direitos com moderação, até mesmo para administradores : finalmente, e isso pode ser um pouco mais avançado para algumas lojas. Os direitos de autorização devem ser tão discretos quanto possível e devem envolver comportamentos funcionais reais. Abordagens típicas de Segurança Baseada em Funções (RBS) tendem a ter uma mentalidade de Grupo . Do ponto de vista da segurança, este não é o melhor padrão. Em vez de ' Grupos ' como ' Gerenciador de usuários ', tente dividi-los ainda mais (por exemplo, criar usuário, autorizar usuário, elevar / revogar direitos de acesso, etc ...) Isso pode representar um pouco mais de sobrecarga em termos de administração, mas oferece a flexibilidade de atribuir apenas direitos que são realmente necessários para o grupo maior de administradores. Se o acesso for comprometido, pelo menos eles podem não obter todos os direitos. Eu gosto de envolver isso em permissões de segurança de acesso a código (CAS) suportadas por .NET e Java, mas isso está além do escopo desta resposta. Mais uma coisa ... em um aplicativo, os administradores não podem gerenciar a alteração de outras contas de administrador ou tornar um usuário um administrador. Isso só pode ser feito por meio de um cliente bloqueado, que apenas algumas pessoas podem acessar.

19

Se o site requer um login para atividades regulares e administradores, por exemplo, um fórum, eu usaria logins separados que usam o mesmo banco de dados de usuário. Isso garante que o XSRF e o roubo de sessão não permitirão que o invasor acesse áreas administrativas.

Além disso, se a seção admin estiver em um subdiretório separado, proteger aquele com a autenticação do servidor web (.htaccess no Apache, por exemplo) pode ser uma boa ideia - então alguém precisa dessa senha e da senha do usuário.

Obscurecer o caminho do administrador quase não produz ganho de segurança - se alguém souber os dados de login válidos, provavelmente também será capaz de descobrir o caminho da ferramenta de administração, já que ele fez o phishing ou keyloged você ou conseguiu através da engenharia social (o que provavelmente revelaria o caminho também).

Uma proteção de força bruta, como bloquear o IP do usuário após 3 logins com falha ou exigir um CAPTCHA após um login com falha (não para o primeiro login, pois isso é extremamente irritante para usuários legítimos) também pode ser útil.


8
  • Eu rejeito a obscuridade
  • Usar dois sistemas de autenticação em vez de um é um exagero
  • A pausa artificial entre as tentativas deve ser feita também para os usuários
  • O bloqueio de IPs de tentativas malsucedidas também deve ser feito para os usuários
  • Senhas fortes também devem ser usadas pelos usuários
  • Se você considera captchas ok, adivinhe, você também pode usá-los para usuários

Sim, depois de escrevê-lo, percebi que esta resposta poderia ser resumida como "nada de especial para o login de administrador, são todos recursos de segurança que devem ser usados ​​para qualquer login".


6
Obrigado pela resposta. Pessoalmente, tendo a discordar, por exemplo: um usuário ficaria feliz com senhas como 'ksd83,' | 4d # rrpp0% 27 & lq (go43 $ sd {3> '? E, não é redefinir bloqueios de IP que usuários válidos acionaram por ser esquecido de gerar trabalho desnecessário de administração / atendimento ao cliente? Pessoalmente, acho que os diferentes níveis de risco justificam abordagens diferentes
UpTheCreek

1
A senha do administrador deve ser complexa, mas não excessivamente complexa, caso contrário, mesmo o administrador não se lembrará dela e a anotará em algum lugar (você o estaria forçando a desafiar todas as regras de segurança). Bloquear IPs temporariamente com falha na tentativa é bastante normal, vbulletin faz isso, phpbb faz IIRC, os usuários estão acostumados com isso.
o0 '.

Eu realmente não quero olhar para phpbb ou vbulletin para melhores práticas de segurança;)
UpTheCreek

@UpTheCreek é claro, eu concordo! Eu estava questionando isso "Não redefinir bloqueios de IP que usuários válidos acionaram por serem esquecidos gerará trabalho desnecessário de administração / atendimento ao cliente" <- Não acho que seria um problema, porque os usuários já estão acostumados para tal recurso.
o0 '.

3

Se você usar apenas um único login para usuários que têm privilégios de usuário normal e privilégios de administrador, gere novamente seu identificador de sessão (seja em um cookie ou um parâmetro GET ou qualquer outro ...) quando houver uma mudança no nível de privilégio ... no mínimo.

Então, se eu logar, faço um monte de coisas normais de usuário e, em seguida, visitar uma página de administração, regenerar meu ID de sessão. Se eu navegar de uma (s) página (s) de administração para uma página de usuário normal, gere novamente meu ID.


Você poderia explicar o que isso alcança?
Denis Pshenov


Eu acredito que isso não vai ajudar tanto quanto você pensa. Porque se o invasor for capaz de obter seu id de sessão atual na página normal do usuário, ele poderá usá-lo para acessar a página de administração e gerar para si mesmo um novo id de sessão. Corrija-me se eu estiver errado.
Denis Pshenov

1
Mas o invasor não pode acessar a página de administração sem uma senha. Não há mudança no nível de privilégio até depois da autenticação. A falha em regenerar o ID da sessão significa que eles podem reutilizar uma sessão criada de forma insegura para contornar a autenticação.
Richard JP Le Guen

Tenho agora. Eu estava pensando que você descreveu um cenário em que o usuário não precisa fazer login novamente quando alterna entre o contexto normal / admin.
Denis Pshenov

1

Tenha uma boa senha de administrador.

Não, "123456"mas uma sequência de letras, dígitos e caracteres especiais longos o suficiente, digamos, 15-20 caracteres. Gosto "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

Adicione uma pausa para cada verificação de senha para evitar ataques de força bruta.


você poderia explicar um pouco o que seria uma 'pausa'? Você está se referindo a fazer algo como Thread.Sleep (5000) apenas para matar o tempo?
terráqueo

5
isso é estúpido: uma senha muito complexa para ser lembrada será escrita em algum lugar (ou salva), tornando as coisas muito piores do que se você permitisse uma senha MUITO boa (ou seja, uma senha que será digitada porque você se lembra dela em vez de copiar e colar )
o0 '.

3
Oh, eu gostaria de poder votar nessa merda até a idade da pedra, é tão estúpido, tão errado ... Eu odeio pessoas espalhando desinformação como esta.
o0 '.

1
@ Lo'oris: Do que exatamente você discorda?

2
Eu escrevi em ... tipo ... o comentário acima?
o0 '.

1

Aqui estão algumas outras coisas a serem consideradas:

  1. Uma opção a ser considerada, especialmente se você gerencia os computadores do administrador ou se eles são tecnicamente competentes, é usar algo baseado em certificados SSL para autenticação de cliente. Keyfobs RSA e outros enfeites também podem ser usados ​​para aumentar a segurança.
  2. Se estiver usando cookies - talvez para um token de autenticação / sessão - você provavelmente deseja garantir que os cookies sejam enviados apenas para as páginas de administração. Isso ajuda a mitigar os riscos impostos ao seu site pelo roubo de cookies, por comprometimento da camada 1/2 ou XSS. Isso pode ser feito facilmente tendo a parte administrativa em um nome de host ou domínio diferente, bem como definindo o sinalizador seguro com o cookie.
  3. Restringir por IP também pode ser inteligente e, se você tiver usuários em toda a Internet, ainda poderá fazer isso, se houver uma VPN confiável à qual eles possam entrar.

1

Usamos Windows Authenticationpara acesso de administrador. Esta é a maneira mais prática de proteger as áreas administrativas enquanto mantém a autenticação separada do que se aplica aos usuários finais em geral. O administrador do sistema gerencia as credenciais de acesso do usuário Admin e impõe políticas de senha na conta do usuário de domínio.


-1

A maneira estrita é ter dois "farms" completos diferentes, incluindo bancos de dados, servidores e tudo e mover os dados de um farm para outro. A maioria dos sistemas modernos e de grande escala usa essa abordagem (Vignette, SharePoint, etc.). Normalmente é referido como tendo diferentes estágios "estágio de edição" -> "estágio de visualização" -> "estágio de entrega". Este método permite que você trate o conteúdo / configuração da mesma forma que você trata o código (dev-> qa-> prod).

Se você for menos paranóico, pode ter um único banco de dados, mas apenas sua seção de administração disponível nos servidores de "edição". Quer dizer, apenas os scripts / arquivos de edição são colocados no servidor de edição.

Naturalmente, a etapa de edição deve estar disponível apenas em uma intranet local e / ou por meio de VPN.

Isso pode parecer um exagero e pode não ser a solução mais fácil para todos os casos de uso, mas é definitivamente a maneira mais robusta de fazer as coisas.

Observe que coisas como "ter senhas de administrador fortes" são legais, mas ainda deixam seu administrador aberto a ataques inteligentes de todos os tipos.


Acho que isso realmente só seria útil / prático em situações puramente CMS / publicação em que você está empurrando conteúdo em vez de processar dados.
UpTheCreek

Talvez, mas eu conheci (e vi) situações em que isso é feito para processamento e entrada do usuário também. Para uma única fazenda com servidor de edição separado, é um acéfalo. Para várias fazendas, o que você faz é colocar a entrada do site em uma fila (banco de dados ou outro) e, usando um procedimento externo, está sendo processada e copiada para o servidor / banco de dados de "edição". Isso lhe dá mais controle sobre o que entra em seu sistema. No entanto, é complicado de implementar.
Nir Levy

-2

Depende muito do tipo de dados que você deseja proteger (requisitos legais e outros).

  • Muitas sugestões são sobre autenticação .. Acho que você só deve considerar o uso de autenticação OpenId / Facebook como login. (Eles provavelmente gastarão mais recursos em segurança de autenticação do que você)

  • Salve as alterações e atualize os valores no banco de dados. Dessa forma, você pode reverter as alterações do usuário X ou entre as datas X e Y.


1
Autenticação do Facebook para a seção administrativa de um site ... você realmente acha que é uma boa ideia? Para usuários gerais, sim ... mas para a seção de administração ? Parece um pouco perigoso para mim ...
Richard JP Le Guen

Não tenho certeza. mas acho que este site executa apenas autenticação openid. E eu não acho que haja qualquer grande (em teoria) diferença entre a autenticação do Facebook e openid. Mas eu não li nenhum contrato de licença ou algo parecido.
Carl Bergquist

1
Muito péssima ideia o openid para autenticação de admin, também o rollback na maioria das vezes é impossível, e o bandido está todo pronto dentro do seu sistema ... que rollback?
Aristos

Sinta-se à vontade para explicar por que você acha isso ruim. Bem, se o logon como administrador dá a você acesso total ao banco de dados e backup, com certeza é difícil reverter, mas nesse caso você está perdido. Minhas sugestões foram direcionadas ao site cmsisch.
Carl Bergquist

-3

Não percebi que ninguém mencionou armazenamento / validação da senha de administrador. Por favor, não armazene o PW em texto simples, e de preferência nem mesmo em algo que possa ser revertido - use algo como um hash MD5 com sal para que, pelo menos, se alguém recuperar a "senha" armazenada, eles não tenham qualquer coisa terrivelmente útil, a menos que eles também tenham seu esquema de sal.


1
-1 para md5. Você não quer um hash rápido para senhas, mesmo além dos outros problemas com md5ing. bcrypt seria uma opção melhor.
Kzqai

-4

Adicione um campo de senha e uma pergunta de segurança que o administrador saberá, por exemplo, qual era o nome da sua primeira namorada, ou randomize as perguntas sempre que visualizar o painel de administração.

Talvez você possa sempre colocar a seção de administração em um grande diretório, por exemplo

http://domain.com/sub/sub/sub/sub/sub/index.php

Mas isso não é realmente bom hah.

Talvez você possa incluir uma string de consulta na página inicial, como:

http://domain.com/index.php?display=true

Quando isso acontecer, o campo de nome de usuário e senha aparecerá.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.