Eu tenho um aplicativo móvel (atualmente IOS e logo Android), que fala com um serviço da web. Não há login e os dados não são privados. Basicamente, o aplicativo envia um marcador (lon, lat) e GETs os 25 marcadores mais próximos para exibir em um mapa.

É um aplicativo muito trivial e não consigo imaginar ninguém fazendo um grande esforço para abusar do serviço da web. No entanto, posso ver que há diversão para alguém no POSTing de muitos marcadores. O que mais me preocupa é alguém que esteja executando um script que envie muitas solicitações (usando uma largura de banda cara e fazendo bobagens com os dados do meu aplicativo).

Estou lentamente chegando à conclusão de que isso não pode ser seguro. A melhor resposta é "não faça isso". Não forneça um serviço da web sem autenticação. Não há muitos serviços tão abertos. A API do You Tube do Google está aberta, mas a maioria não está. Infelizmente não tenho escolha. Então, depois de dias de olhar para este aqui está meu pensamento. Esteja ciente de que estou muito longe de um especialista em segurança e estou confiante de que minha abordagem poderia ser aprimorada. Mas isso pode apontar você na direção certa. Espero que alguém mais experiente possa falar e corrigir / melhorar isso. eu encontreiEste artigo e comentários particularmente úteis.

Segurança no nível de mensagem

Vou proteger as msgs com uma criptografia de hash. Os clientes e o serviço da web retêm uma cópia de um segredo compartilhado que é usado como um salt para criar um hash da URL e todos os argumentos do POST. O hash é passado como um argumento adicional e o hash é reconstruído e comparado no outro extremo (usando a chave compartilhada como um sal). Isso é muito bom até você entender que qualquer código de cliente móvel pode ter engenharia reversa em minutos. Em que ponto esta linha de defesa é totalmente inútil.

Medidas do Cliente

O cliente inclui a limitação de taxa de mensagens como uma medida para restringir o número de mensagens enviadas por usuários honestos. Mais uma vez, isso é inútil contra um invasor que jailbreak o dispositivo móvel.

Segurança do lado do servidor

Portanto, o lado do servidor deve ter o máximo de medidas de segurança possíveis, para ficar sozinho, supondo que o seu cliente (e o segredo compartilhado) esteja comprometido. Aqui está o que eu tenho:

Uma msg arg é uma hora UTC que é usada para limitar os ataques de repetição. Isso deve impedir que um invasor ative a mesma msg no servidor repetidamente.

O servidor realiza a limitação de taxa por IP. Sim, IPs são facilmente falsificados e troca de proxy é brincadeira de criança, mas tudo ajuda quando você tem tão pouco.

Obviamente, o servidor valida estritamente todos os argumentos, usa consultas parametizadas e não retorna exceções.

Segurança em nível de transporte

Infelizmente, estou bastante confiante de que não é possível emitir certificados SSL de cliente individuais sem um processo de registro. E como estou usando a verificação de hash msg (e meus dados não são particulares), não tenho certeza absoluta do que o SSL traz para a tabela. No entanto, provavelmente usarei o SSL (com um certificado de aplicativo inteiro) porque ele adiciona outro nível de segurança que é implementado de maneira fácil e barata (embora com um custo de tempo de conexão adicional para cada msg).

O Grande Buraco Grande Na Minha Abordagem

Sou avisado que o aplicativo deve se tornar popular se alguém comprometer o segredo compartilhado no cliente. Só porque eles podem e eles provavelmente vão postar na internet. Então, realmente tudo se resume ao lado do servidor. Infelizmente,Não tenho como identificar e bloquear um invasor. Isso eu amaria muito.

Um apelo final

Depois de dias de pesquisa, isso é tudo que tenho. Mas eu quero mais. Eu particularmente aprecio todas as idéias para reforçar o lado do servidor. Então, eu coloquei todos os meus pontos SO como uma recompensa. Sim senhor, todos os 97 pontos!