Aplicativo seguro para iPhone communication comunicação com o servidor

Qual seria a melhor abordagem para alcançar a comunicação privada entre meu aplicativo iOS e seu componente de servidor? Ter uma única "chave secreta" imutável inserida na fonte do aplicativo é suficiente ou preciso configurar gerações de tais chaves de "aperto de mão" dinamicamente de alguma forma?

O servidor, por si só, não tem acesso a dados confidenciais; portanto, mesmo que o usuário atinja alguns pontos de extremidade particulares, ele não os levará a lugar algum, mas eu quero que eles sejam ocultos ao público. Basicamente, quero ignorar todas as solicitações que atingem rotas específicas, a menos que sejam provenientes do meu aplicativo iOS.

O componente do servidor é executado no RoR, se isso é importante.

Você não pode rejeitar efetivamente as conexões, a menos que forneça a cada cliente uma chave privada que possa ser revogada individualmente. Mas isso provavelmente é um exagero. Você não precisa de uma solução à prova de balas se a maioria das pessoas não se incomodar em disparar uma bala.

É uma questão de segurança, então vamos descrever um modelo de ameaça e estratégias de mitigação.

Suponha que você tenha um URL atingido que possa incorrer em custos perceptíveis para você (por exemplo, custo de processamento) e que você deseja protegê-lo de um ataque simples de DoS e de aplicativos copiados.

Use o SSL para impedir que a conexão seja analisada facilmente. Use um número de porta que não seja óbvio, uma sequência de redirecionamento, uma troca de cookies para complicar um pouco a conexão antes de fazer a parte dispendiosa da solicitação. Use algum código secreto inserido no seu aplicativo para informar ao servidor que ele precisa aceitar a conexão.

Agora, alguém não pode aprender o URL caro a ser atingido simplesmente executando um farejador de pacotes ou examinando as strings semelhantes a URL no seu código. Um invasor em potencial precisa descompilar seu aplicativo.

Você realmente não pode proteger seu código de ser descompilado e / ou executado em um depurador. O atacante finalmente aprende a chave secreta e a sequência de conexão.

Você percebe que começa a receber solicitações de rouge no seu URL caro: na forma de um ataque ou na forma de um aplicativo de cópia que precisa acessar seu serviço para executar, ou talvez um código de exploração seja publicado publicamente. Você não pode diferenciar uma solicitação não autorizada de uma solicitação legítima.

Crie uma atualização secundária gratuita para o seu aplicativo, com uma chave secreta diferente. Ele deve atingir um URL caro diferente, que serve os mesmos dados que o URL caro comprometido. Por algum tempo, torne os dois URLs acessíveis.

Assista a sua base de usuários mudar para a versão atualizada. Acelere o URL caro comprometido e, eventualmente, 404. Você acabou de mitigar uma violação de segurança, sem perder muito. De volta à estaca zero.

Isenção de responsabilidade: não sou especialista em segurança.

Você tem um problema clássico que realmente não pode ser resolvido.

Para garantir uma privacidade simples (ou seja, garantir que seus dados não possam ser bisbilhotados ou alterados durante o transporte), você pode fazer tudo por SSL e fornecer ao servidor um certificado emitido corretamente por uma CA que o iPhone reconheça.

Para autorização, no entanto, não existe uma boa solução que garanta 100% que ninguém além do seu aplicativo possa acessar a API. Sua solução proposta iria funcionar, exceto:

• qualquer pessoa que baixou seu aplicativo necessariamente tem em seu poder a chave privada
• se eles conseguirem descompactar seu aplicativo e descompilá-lo, terão a chave privada em texto sem formatação
• depois que eles tiverem a chave privada em texto sem formatação, poderão usá-la para assinar suas próprias solicitações maliciosas.

Não há como contornar isso. Não quer dizer que você não possa adotar essa abordagem, mas entenda que não é à prova de falhas. É esse mesmo problema que torna o DRM completamente ineficaz .

É para isso que servem o TLS e o SSL . Qualquer um pode criar uma conexão segura sem a necessidade de uma chave secreta fixa. Leia a seção Descrição na página vinculada para saber como eles fazem isso.

Uma maneira eficaz de obter o benefício do TLS / SSL sem ter que fazer muito (qualquer) trabalho é fazer com que o servidor implemente um serviço da Web que o cliente acessa usando o protocolo HTTPS. O HTTPS é apenas HTTP através de uma conexão segura, e o sistema de carregamento de URL no iOS o implementa para você.