Linhas padrão: como a FTC diz que o Credit Karma e as configurações de segurança iluminadas por Fandango SS
Imagine um porteiro corpulento em uma festa exclusiva. Quando alguém afirma ser um convidado, o porteiro verifica seu convite e o executa contra os nomes da lista. Se não corresponder, a pessoa não passará pela corda de veludo. Mas o que acontece se o porteiro não estiver fazendo seu trabalho? Seu lapso poderia permitir que uma campainha entrasse na festa se afaste os aperitivos e roubam os objetos de valor.
Não é uma analogia perfeita, é claro, mas os acordos da FTC com a empresa de informações de crédito Credit Karma e o site de ingressos de cinema Fandango demonstram os perigos quando as empresas substituem as configurações padrão dos sistemas operacionais projetados para autenticar e proteger as conexões usadas para transmitir informações confidenciais.
Veja como as coisas funcionam depois que um consumidor baixou um aplicativo em um dispositivo. Pense na camada de soquetes seguros (SSL), o protocolo padrão da indústria para estabelecer conexões criptografadas, como o porteiro. Quando um serviço on -line deseja se conectar a um aplicativo, o serviço apresenta um certificado SSL para atestar sua identidade. Depois que o aplicativo valida o certificado, o serviço on -line é permitido através da corda de veludo e estabelece uma conexão criptografada com o dispositivo para que o consumidor possa enviar informações. Este soco de uma validação por meio de um certificado SSL e criptografia cria uma maneira mais segura para as pessoas transmitirem dados confidenciais.
Mas os fraudadores são conhecidos por usar técnicas de falsificação para montar o que é chamado de ataques de homem no meio. Se o aplicativo não verificar o certificado SSL, um invasor poderá usar um certificado inválido para colocar o pé na porta e estabelecer uma conexão para interceptar informações enviadas entre o aplicativo e o serviço on -line. Nem a pessoa que usa o aplicativo nem o serviço on -line percebem o que está acontecendo.
A garantia da transmissão de informações pessoais contra ameaças como ataques de homem no meio é tão importante que os sistemas operacionais iOS e Android fornecem aos desenvolvedores interfaces de programação de aplicativos fáceis de usar-APIs-para implementar o SSL. Por padrão, esses APIs validam automaticamente os certificados SSL e rejeitam a conexão se o certificado for inválido.
A documentação do desenvolvedor para os sistemas operacionais iOS e Android usa linguagem particularmente forte para alertar contra desativar essas configurações de validação padrão. De acordo com a documentação do iOS, não validar os certificados SSL “elimina qualquer benefício que você possa ter obtido ao usar uma conexão segura. A conexão resultante não é mais segura do que enviar a solicitação por HTTP não criptografado, pois não fornece proteção contra a falsificação por um servidor falso. ” A documentação do Android também não mede palavras: um aplicativo que não valida os certificados SSL “também pode não estar criptografando a comunicação, porque qualquer um pode atacar usuários em um hot spot público Wi-Fi. . . (e) o invasor pode gravar senhas e dados pessoais. ”
De acordo com a FTC, o Credit Karma e o Fandango ignoraram esses avisos de “não vão lá”. Ao desenvolver seu aplicativo iOS, que permite que os consumidores obtenham suas pontuações de crédito e monitorem outros dados financeiros, o Credit Karma autorizou um provedor de serviços a usar o código que desativou a validação do certificado SSL para fins de teste. Mas a FTC diz que o Credit Karma deixa o aplicativo ir ao mercado sem ligar novamente as configurações padrão. Assim, entre 18 de julho de 2012 e, por volta de 1º de janeiro de 2013, o aplicativo iOS da empresa estava vulnerável a ataques de homem no meio, colocando em risco os números de previdência social dos usuários, datas de nascimento e dados do relatório de crédito.
Como o CreditKarma descobriu o problema? De acordo com a FTC, não através de suas próprias verificações e monitoramento internos. A denúncia alega que um usuário entrou em contato com o Credit Karma, levando os engenheiros da empresa a atualizar o aplicativo em janeiro de 2013 para restaurar as configurações padrão.
Mas esse não é o fim da história do Credit Karma. Pouco tempo depois, a equipe da FTC entrou em contato com o Credit Karma sobre o problema. Só então a equipe interna da empresa realizou uma revisão de segurança nas duas versões do aplicativo. Foi uma coisa complicada, cara e demorada? Não. De acordo com a FTC, levou apenas algumas horas e custou quase nada. E adivinhe o que revelou? Em fevereiro de 2013 – depois O Credit Karma foi informado sobre a vulnerabilidade do iOS – a empresa lançou a versão Android de seu aplicativo com exatamente o mesmo problema. A revisão também revelou outra falha de segurança: o aplicativo iOS estava armazenando tokens de autenticação e códigos de passagem no dispositivo de maneira insegura.
O processo da FTC contra Fandango acusa a empresa com lapsos semelhantes. De março de 2009 a março de 2013, a versão iOS do aplicativo de Fandango não validou os certificados SSL, substituindo os padrões de segurança do sistema. De acordo com a FTC, a Fandango não testou seu aplicativo antes da versão para garantir que ele estivesse validando os certificados SSL e transmitindo com segurança dados pessoais dos consumidores, incluindo números de cartão de crédito, datas de vencimento e códigos de segurança. Sim, Fandango encomendou algumas auditorias em 2011, dois anos completos após o lançamento do aplicativo. Mas, mesmo assim, limitou o escopo de incluir apenas ameaças colocadas quando o atacante tinha acesso físico ao dispositivo de um consumidor. Não testou a transmissão de dados seguros. Assim, Fandango perdeu a oportunidade de detectar a vulnerabilidade que havia introduzido substituindo os padrões.
A FTC diz que Fandango agravou o problema por não ter um canal eficaz para as pessoas relatarem problemas de segurança. De acordo com a denúncia, um pesquisador entrou em contato com a empresa em dezembro de 2012 através do único método prontamente disponível – um formulário da Web de atendimento ao cliente. Como a mensagem do pesquisador incluiu o termo “senha”, o sistema de atendimento ao cliente da Fandango o tratou como uma solicitação de redefinição de senha de rotina e respondeu com uma mensagem enlatada. O sistema então descartou o aviso de segurança como “resolvido”.
Quando Fandango finalmente resolveu o problema? De acordo com a denúncia, não foi até a empresa ouvir da equipe da FTC. Somente então o Fandango executou o teste simples que revelou que seu aplicativo não conseguiu validar os certificados SSL. Fandango também descobriu que a vulnerabilidade afetou um aplicativo de ingressos de cinema separado que hospedou para terceiros. Dentro de três semanas, o Fandango emitiu uma atualização de ambos os aplicativos iOS que restauraram as configurações padrão, conectando assim esse orifício de segurança.
Os acordos propostos com o Credit Karma e o Fandango exigem que as empresas estabeleçam programas de segurança abrangentes para lidar com riscos relacionados ao desenvolvimento e gerenciamento de produtos novos e existentes e proteger a segurança, a integridade e a confidencialidade das informações cobertas pela ordem. Consistente com outros assentamentos, o Credit Karma e o Fandango precisarão de auditorias de segurança de um profissional independente a cada dois anos nos próximos 20 anos. Obviamente, os termos dos acordos se aplicam apenas a essas empresas, mas as empresas experientes desejam ler os pedidos propostos para ver o que é exigido do Karma e Fandango. Você pode registrar um comentário sobre os assentamentos propostos até 28 de abril de 2014.
O que mais as empresas podem aprender com esses casos?
1. Exercite o cuidado extremo ao modificar os padrões de segurança. Se as empresas tivessem deixado bem o suficiente, os padrões de segurança dos sistemas operacionais teriam protegido as informações pessoais dos consumidores contra ataques de homem no meio. Obviamente, não estamos dizendo que é sempre ilegal modificar uma configuração padrão. De fato, existem maneiras de ir além da validação padrão do certificado SSL, implementando um método de autenticação ainda mais forte conhecido como “fixação de certificado”. Mas modificar os padrões de segurança é a cirurgia cerebral do desenvolvimento de aplicativos. As empresas precisam ter certeza de que sabem o que estão fazendo.
2. Teste seu aplicativo cuidadosamente antes de liberá -lo. Os carpinteiros têm um velho ditado: “Meça duas vezes, corte uma vez”. O Corolário para desenvolvedores de aplicativos: aproveite os métodos gratuitos ou de baixo custo para testar a segurança de seus aplicativos antes Você os coloca nas mãos dos consumidores.
3. Considere como as pessoas usarão seus aplicativos. Há uma razão pela qual o SSL é tão importante no ambiente móvel e por que a documentação do desenvolvedor do iOS e do Android faz um grande negócio: porque as pessoas geralmente usam aplicativos móveis em redes Wi-Fi públicas não garantidas. Como jogadores de xadrez, os desenvolvedores precisam pensar em alguns movimentos à frente. Antes de lançar um aplicativo, pense em como as pessoas provavelmente o usarão e protegê-lo com essas considerações do mundo real em mente.
4. Você é responsável pelo que os outros fazem em seu nome. De acordo com a denúncia, o Credit Karma autorizou um provedor de serviços a desativar o processo de validação de certificação SSL durante o teste de pré-lançamento, mas não viu que as configurações de segurança foram restauradas depois disso. A primeira preocupação: o teste poderia ter sido feito sem desligar os padrões. Mas, mesmo assim, é extremamente importante que as empresas garantem que tudo esteja de volta à ordem da Apple Pie antes que os consumidores obtenham o aplicativo.
5. Mantenha o ouvido no chão. Há uma comunidade de pesquisa ativa por aí que compartilha informações sobre possíveis vulnerabilidades de segurança. Mas, respondendo a um aviso grave com uma “carta de percevejo” padrão, Fandango perdeu a oportunidade de resolver os problemas. Tem uma pessoa experiente contatada seu Empresa recentemente sobre um risco potencial? E essa mensagem está definhando não lida em uma caixa de e -mail?
6. Consulte os recursos disponíveis. O folheto da FTC, desenvolvedores de aplicativos móveis: comece com segurança, oferece conselhos para as empresas sobre como proteger contra esse tipo de vulnerabilidade:
Para proteger os usuários, os desenvolvedores geralmente implantam SSL/TLS na forma de HTTPS. Considere o uso de HTTPs ou outro método padrão do setor. Não há necessidade de reinventar a roda. Se você usar o HTTPS, use um certificado digital e verifique se o seu aplicativo verifica corretamente. Um certificado digital sem frescuras de um fornecedor respeitável é barato e ajuda seus clientes a garantir que estejam se comunicando com seus servidores, e não com a de outra pessoa. Mas os padrões mudam, portanto, fique de olho nas tecnologias atuais e verifique se você está usando os melhores e mais recentes recursos de segurança.
Marque a página de privacidade e segurança da FTC e consulte outras fontes públicas para obter informações gratuitas sobre o desenvolvimento de aplicativos mais seguros.
