Nós temos um aplicativo da web (Apache / PHP) que atualmente usa autenticação de nome de usuário / senha e está atualmente acessível de qualquer lugar. Possui SSL do lado do servidor ativado.
Nosso programa cliente é uma versão do FireFox que modificamos e renomeamos. Este cliente do firefox modificado destina-se apenas a conectar-se ao nosso servidor de aplicativos da web. Os usuários devem usar este programa cliente para se conectar ao serviço da Web.
Além da autenticação do usuário, gostaríamos de bloquear o acesso no nível do servidor a qualquer pessoa que não esteja usando nosso programa cliente *. Portanto, se um usuário digitar um URI usando um navegador comum, ele será negado imediatamente.
Para conseguir isso, o programa cliente precisa se identificar com o servidor para que o servidor saiba que o programa cliente está sendo usado e não um navegador da web ou bot.
* O objetivo real é garantir que eles sejam funcionários autorizados de nossa empresa antes de poderem tentar um login. Incorporar essa "prova de emprego" no programa cliente parece ser a maneira mais fácil de fazer isso, já que o aplicativo só é dado para pessoas que precisam usá-lo ..
Até agora, tive algumas ideias sobre como realizar isso.
1.) Incorporar uma tolken no aplicativo cliente que é enviado quando o cliente faz um login (o login é feito por uma interface chrome / XUL). Isso não bloquearia no nível do servidor, apenas no nível do aplicativo. A chave pode ser roubada tão facilmente quanto uma senha, mas não é adivinhada pela força bruta com a mesma facilidade, pois pode ser de qualquer tamanho ou complexidade.
1a.) Adicione um parâmetro tolken especial ao cabeçalho do navegador do cliente em todas as solicitações. Isso é mais como segurança através da obscuridade, mas certamente poderia retardar um invasor tentando usar senhas de força bruta se o login sempre falhar (mesmo com a senha correta) quando a string mágica estiver faltando na requisição.
2.) Incorporar um certificado SSL do cliente no programa cliente. Isso parece ser uma boa solução, mas boa documentação sobre o SSL do cleint é quase inexistente. Nós NÃO queremos assinar um certificado para cada usuário, nem queremos que o usuário tenha que criar um certificado ou ser incomodado com diálogos de segurança. A chave privada teria de estar embutida no navegador e seria uma chave compartilhada entre todos os programas clientes e distribuída por instalação em nosso navegador personalizado.
3.) Verifique a string do agente do usuário. Eu acho que o Apache pode restringir com base nisso. Mas parece uma medida fraca na melhor das hipóteses. Eu provavelmente faria isso além de outras medidas.
Espero ter uma ideia melhor de como fazer isso?
Incluir um certificado SSL de cliente com o navegador modificado seria mais fácil e provavelmente mais seguro.
Se você estiver usando a mesma chave para todos, perderá muitas das vantagens dos certificados de cliente, mas será melhor do que verificar useragent. E suponho que você ainda precisará de um nome de usuário e senha para fazer o login.
Você já pensou em VPN? Isso parece exatamente o que você realmente quer.
Tags security apache-2.2