Uma informação recentemente divulgada sobre uma antiga praia de dados de mais de 500 milhões de usuários do Yahoo colocou o ponto de interrogação na venda multibilionária do Yahoo para a Verizon. Afinal, ninguém quer adquirir um passivo e não responder por todos os custos futuros envolvidos. Aplicativo de namoro online para trapaceiros de cônjuges, Ashley Madison teve que fechar depois que uma violação expôs suas informações de usuário e informações relacionadas ao faturamento levando a muitos divórcios, demissões e suicídios na vida real, incluindo o de um pastor. 600.000 contas do Facebook foram hackeadas diariamente em 2011, talvez mais hoje. O enorme hack da SONY Pictures levou à exposição de muitas informações confidenciais sobre seus projetos, detalhes pessoais dos principais executivos e reclamações de Hollywood. Também expôs números de segurança social e senhas de seus funcionários e cerca de 1 milhão de usuários, supostamente todos armazenados em um simples arquivo excel claramente marcado como 'Senhas.xls'. A famosa saga fappening expôs fotos nuas de muitas celebridades de Hollywood aconteceu quando um hacker escreveu um script para testar as contas da Apple das 500 senhas mais populares que foram aprovadas pela política de senhas da Apple (Caps, chars especiais e tudo mais). Muito recentemente, um ataque a um importante provedor de serviços DNS Dyn derrubou quase metade da internet dos Estados Unidos e grandes sites como The New York Times, Twitter, etc.
Onde as coisas dão errado? A maioria das façanhas são erros humanos que levam a uma oportunidade e foram atacados por um hacker mal-intencionado. Vamos voltar ao fluxo típico de um App e ao padrão de interação do App e seus usuários. Um usuário sentado em um café está navegando no Product Hunt e se depara com um novo aplicativo de namoro, que promete fornecer relacionamentos significativos. Você instala o aplicativo, faz login usando uma das duas senhas que você usa em todos os lugares da Web e se você é um desenvolvedor, você pode se perguntar por que não há um indicador de cadeado como o indicador para aplicativos móveis para garantir que a comunicação entre você e o servidor do aplicativo de namoro seja segura e não possa ser bisbilhotada. Você começa a usar o aplicativo, deslizando cuidadosamente e escrevendo mensagens espirituosas que aprendeu em um megathread reddit, mas todas as meninas parecem estar offline. De repente, você recebe uma oferta de assinatura premium que lhe mostrará mais frequentemente para meninas do que outros homens heterossexuais. Você adiciona rapidamente seu cartão de crédito para a assinatura de US$ 5 e, em seguida, fecha o aplicativo. O aplicativo de namoro, como em todos os aplicativos de namoro com UX acima da média, recebe muitos usuários rapidamente, e muita imprensa por seu foco em relacionamentos significativos e, em seguida, uma tonelada de dinheiro de pessoas proeminentes no vale para mudar o mundo. Não vamos nos concentrar nessas questões, só queremos saber onde as coisas podem dar errado.
Lembre-se que você estava sentado em uma cafeteria. E se tiver pressa em lançar seu aplicativo, os desenvolvedores estão tomando informações de inscrição em um canal não seguro? Isso significa que qualquer pessoa sentada no café pode ouvir e interceptar sua senha, que você compartilha em metade dos serviços na internet. Isso raramente acontece hoje. Vamos passar para outro cenário. E se o wi-fi ao qual você se conectou com o nome Cafe_Noir não for o wi-fi do Café, mas um falso para interceptar suas comunicações. Lembre-se que seu celular ou laptop salva a rede wi-fi e suas senhas para que, quando você revisitar um café, ele faça login automaticamente sem que você tenha que digitar a senha novamente. Com uma pequena configuração barata, qualquer pessoa pode começar a roubar dados em hotspots WiFi públicos.. Você está surpreso que seu telefone e laptop tagarela sobre cada rede wi-fi que você conectado a todos ao redor? Você aprenderá mais sobre a Segurança da Camada de Transporte e seu aplicativo para web e outras plataformas e protocolos no Capítulo 2.
Vamos supor que nada emocionante aconteceu no trânsito e você estava falando em um canal seguro com os servidores do aplicativo. Informações confidenciais como senhas não são armazenadas como são em bancos de dados, mas são hashed e armazenadas. Um hash é uma representação embaralhada de sua senha com quase nenhuma maneira de recuperar sua senha original do próprio hash. Ao tentar fazer login mais tarde, o valor digitado na caixa de senhas do aplicativo é hashed e verificado contra o hash de sua senha armazenada no banco de dados. Se ambos correspondem, você está logado. Esse processo, conhecido como hashing, garante que, mesmo que o banco de dados seja vazado, seria difícil obter sua senha do hash.
[[INSERT hash exemplo pic]]
Outras informações como seu e-mail, endereços, histórico de localização, mensagens trocadas são armazenadas em texto simples. O código usado para calcular o hash para senhas é crucial. Qualquer erro cometido ao projetar ou implementar o código seria desastroso. Portanto, as empresas geralmente passam por um mecanismo de hash comprovado e uma implementação completa correspondente que já existe há algum tempo e passou por algumas revisões de código. Uma consideração importante para os mecanismos de hashing é que a função deve ser lenta para ser executada em computadores. Isso é contra-intuitivo, pois ninguém quer que seu código seja lento. Mas isso é feito para garantir que um hacker não possa simplesmente executar este código em dizer todas as strings de caracteres de 3 a 8 feitas a partir de todas as combinações possíveis de alfabetos, números e caracteres especiais e, em seguida, basta verificar o banco de dados que eles hackearam para as entradas de hash correspondentes na tabela que eles acabaram de criar. Esse tipo de mesa são chamadas de mesas de arco-íris. Mesmo com funções de hash mais lentas, pode-se aplicar poder de computação adicional para trabalhar e criar esta tabela arco-íris. Para evitar que as tabelas de arco-íris funcionem efetivamente em quebrar senhas hashed, geramos uma pequena sequência aleatória e anexamos à senha dos usuários e, em seguida, gerar e salvar o hash para ele. O sal é armazenado em texto simples ao lado do hash. Agora, o invasor tem que gerar diferentes tabelas de arco-íris para cada senha levando em conta o sal para o respectivo hash tornando o cálculo em sua maioria inviável. Outra característica desses mecanismos de hashing é que ele deve evitar gerar hash exatamente semelhante para duas senhas ou strings diferentes (chamada de colisão de hash). Deve ser difícil para alguém apenas chegar a duas cordas diferentes que vão gerar o mesmo hash. Note que o uso das palavras evita e difícil, colisões existirão, mas alguém não deve fazer isso acontecer propositalmente. Essa condição provou ser um problema quando os pesquisadores foram capazes de gerar dois certificados diferentes com o mesmo hash usando o mecanismo de hash de MD5, quebrando efetivamente o SSL. O MD5 foi eliminado como um mecanismo de hashing para SSL de todos os principais navegadores até 2013 e até mesmo uma versão mais forte SHA1 está em processo de ser eliminado gradualmente até 2017 devido ao medo de colisão. Você aprenderá os detalhes do hashing e vários métodos de hashing no Capítulo 7. Se há uma única coisa que você precisa lembrar deste documento, é nunca armazenar senhas em plaintext. Basta usar bcrypt.
Mas como os hackers conseguem o despejo de dados em primeiro lugar? Na maioria das vezes é bastante fácil. No caso do hack de imagens da SONY, o grupo de hackers LulzSec diz ter explorado uma vulnerabilidade de injeção SQL. SQL é uma linguagem de programação usada para buscar e modificar dados de bancos de dados. Uma grande fraqueza do SQL é a incapacidade de diferenciar entre código e dados. As declarações SQL quando usadas em linguagens de programação e aceitando entradas de dados diretamente dos usuários podem ser manipuladas por hackers fornecendo código em vez de dados e obtendo informações extras dos bancos de dados. Você aprenderá mais sobre a injeção SQL, como preveni-los e como verificar no Capítulo 6.
[[Amostra de injeção SQL e SQL]]
Outra maneira comum de os hackers obterem esses dumps é simplesmente se conectar nas máquinas de banco de dados pertencer às empresas que não têm senhas e são expostas publicamente na internet ou têm senhas comuns ou fracas. Shodan, um mecanismo de busca por portas abertas em toda a internet fornece uma maneira fácil de procurar bancos de dados abertos como MongoDb, MySQL e até mesmo os tamanhos de db. Tomar um despejo desses bancos de dados é uma questão de minutos a horas, dependendo da quantidade de dados. Aprenderemos sobre vários erros de configuração no Capítulo 12.
Duas questões importantes surgem -
- Por que usar senhas? O público geral é extremamente ruim em selecionar senhas fortes e tendem a reutilizar a mesma senha em todos os diferentes serviços de internet. Por que precisamos de uma senha para provar que realmente somos quem afirmamos ser. Há outra maneira mais segura de fazer isso? Avaliamos isso no Capítulo 8 e uma forma sem senha de autenticação e muito mais no Capítulo 9.
- Por que armazenar todas as informações em um servidor remoto que não tem como provar para nós que nossas informações estão sendo armazenadas com segurança ou nossa senha está sendo hashed em tudo e não está em texto simples como a SONY. existe uma maneira de armazenar nossas informações conosco e implantar nossas próprias medidas para protegê-las, dependendo da probabilidade de sermos atacados e sermos livres para tirar nossos dados offline ou excluí-los sempre que quisermos.
Agora que os hackers têm sua senha ou o hash da sua senha, é trivial fazer login na sua conta e em todas as outras contas que compartilham a mesma senha. Para evitar isso, a maioria das empresas recorreu a algo chamado autenticação de 2 fatores. Você pode ter usado isso no login do Gmail, Twitter ou Facebook, onde depois de digitar corretamente sua senha, você recebe um código PIN de segurança como uma mensagem de texto em seu celular designado. No caso do Gmail, você pode até usar o aplicativo de autenticação do Google que lhe dá um código para ser inserido durante o login. Ter o celular ou o aplicativo configurado do Google Authenticator adiciona uma camada extra de segurança que você é quem você afirma ser. Você aprenderá sobre autenticação e métodos de autenticação de 2 fatores em detalhes no Capítulo 4.
Você deve estar ciente de que a autenticação de 2 fatores usando SMS como o segundo fator não é mais considerada segura. É possível enganar seu celular para se conectar a um dispositivo caseiro de hackers que age como uma torre móvel local (mais comumente conhecida pelo nome Stingray) e, em seguida, interceptar todas as comunicações. Também é possível (por mais difícil) explorar uma vulnerabilidade no protocolo de sinalização telefônica SS7 para rotear chamadas e SMS destinados ao seu telefone para um telefone de hackers mal-intencionados. Em alguns países, é bastante fácil ligar para o seu provedor de telecomunicações e solicitar a alteração do SIM e ter acesso aos seus códigos DE SMS de 2 fatores, como aconteceu com um ativista cuja conta no Twitter foi hackeada apesar da autenticação de 2 fatores estar ativa. Aliás, o Instituto Nacional de Padrões e Tecnologia dos EUA preteriu o SMS como meio para autenticação de 2 fatores em agosto de 2016. Examinaremos outros métodos de autenticação segura de 2 fatores no Capítulo 4.
Uma parte importante dos vazamentos de dados é o vazamento de dados financeiros. A darknet (uma rede via internet especificamente acessada com software configurado como o Tor) está cheia de entidades sombrias que vendem informações completas de cartão de crédito em massa. A maioria deles fazia parte de algum vazamento de dados ou outro. Um vazamento de dados envolvendo informações de cartão afetará severamente os usuários das entidades, algum mês após o vazamento ter sido divulgado e corrigido.
Quando você usa um serviço de terceiros como o Google Analytics ou login via Facebook em seu site ou aplicativo, você recebe um conjunto de tokens que identifica e autentica seu aplicativo exclusivamente para seus sistemas. Esses tokens também chamados de chaves de API devem ser usados em seu código. Às vezes, você pode expor esses tokens publicamente, por exemplo, ao empurrar seu código para um repositório público no GitHub. Essas chaves de API podem então ser mal utilizadas para obter dados, interromper seus sistemas ou, às vezes, até mesmo limpar suas implantações na nuvem (por exemplo, as chaves de acesso total da API da Amazon Web Services). Na verdade, o GitHub está cheio de inúmeras chaves de API expostas para quase todos os provedores de API populares.
Uma vulnerabilidade importante para coisas sérias, como a aquisição de dispositivos ou roubo de informações remotas, é a Execução remota de código ou a capacidade de executar um código arbitrário no dispositivo do alvo, seja um laptop, celular ou uma usina nuclear (por exemplo, Stuxnet é um malware sofisticado projetado para sabotar instalações nucleares). Se você passar pelos registros de atualização de segurança do Apple iOS e macOS, você terá exemplos de correções RCE em quase todas as outras atualizações, como, por exemplo, assumir um dispositivo Apple através de uma simples mensagem de texto ou e-mail. E, pode haver um bug equivalente para Android para que os haters da Apple não sejam deixados de fora em ser hackeados.. Houve um número significativamente grande de vulnerabilidades no Adobe Flash que poderiam ser exploradas para executar um código de hackers, uma das razões para sua depreciação dos principais navegadores da Web.
Fator Humano em Segurança Um aspecto importante, mas principalmente negligenciado do design de segurança e falhas, são os ataques de engenharia social. A interação humana é um aspecto importante do software e muitas vezes é mal utilizada de várias maneiras não técnicas para obter acesso ilegal a sistemas. Por exemplo, o hacker que ligou para a Verizon para obter um novo SIM para hackear a conta do ativista provavelmente não escreveu uma única linha de código para quebrar a autenticação de 2 fatores. Uma enorme população em todo o mundo, principalmente nos países em desenvolvimento, está tendo sua primeira experiência na internet agora. Sem o conjunto certo de informações, seria bastante fácil projetar um ataque que pareceria legítimo para eles e, em seguida, convencê-los a expor suas informações pessoais, senhas e detalhes de pagamento. Por exemplo, um link como https://google.com/amp/gmail-login.website redirecionará para gmail-login.website que pode ser um site de hackers válido com o Gmail, como página de login, graças a novos TLDs ou extensões de domínio, como .site chegando. Isso está acontecendo em uma taxa alarmante agora. Se o aplicativo de namoro em nosso exemplo anterior não tiver definido suas configurações de DNS para e-mail corretamente (especificamente cabeçalho SPF, DMARC e DKIM), seria bastante fácil enviar um e-mail que parece vir de seu domínio e endereço de e-mail e, em seguida, explorar seus usuários para revelar dados pessoais. As configurações do DNS são explicadas em detalhes no Capítulo 12.
Uma maneira comum de explorar os usuários é colocar anúncios de clickbaity em sites pornográficos convidando um clique que, em seguida, ou pede informações pessoais e detalhes de pagamento ou leva a uma instalação de malware. Um malware é um pequeno pedaço executável que é controlado remotamente e executa certos conjuntos de instruções, como excluir arquivos no sistema de usuários, roubar senhas de usuário ou pode ser usado para atacar outros sites e sistemas em conjunto com outros malwares instalados em vários outros sistemas, chamados coletivamente de botnet.
Todos os sistemas na internet sejam um site ou um aplicativo móvel como Pokemon Go é capaz de lidar com uma certa quantidade de tráfego. Quando o sistema é bombardeado com um tráfego muito maior do que ele é projetado para lidar com ele entra em colapso, deixando seus usuários sem serviço. Isso é comumente conhecido como ataques de Negação de Serviço ou DoS. Quando o tráfego gerado para derrubar sistemas vem não de um único sistema, mas de várias fontes, diz-se que é um DoS distribuído. Os ataques DDoS geralmente são feitos através de botnets ou de uma rede de sistemas comprometidos. Recentemente, um ataque DDoS a um provedor de serviços DNS derrubou quase metade da internet dos EUA, incluindo sites populares como Twitter, Netflix, Reddit, The New York Times, The Guardian e muito mais. Relatórios preliminares sugerem que este foi um trabalho de hackers amadores usando uma botnet popular chamada Mirai.
Observe que os sistemas comprometidos não precisam ser computadores ou telefones celulares. Pode ser qualquer dispositivo conectado à internet que tenha algum poder de processamento e capacidade de executar código. Com dispositivos como monitores de bebê, câmeras digitais conectadas à internet e a maioria deles com senhas padrão ou senhas fracas, tornou-se bastante fácil criar botnets usando esses dispositivos. Mirai é uma botnet que se alimenta de dispositivos IoT inseguros e cujo código foi recentemente lançado no GitHub por um hacker anônimo. Relatórios sugerem que os bots Mirai mais do que dobraram desde o lançamento de seu código fonte em público. Insecam é um diretório de câmeras inseguras habilitadas para internet que oferece transmissões ao vivo de todo o mundo.
Os ataques DDoS são geralmente medidos em termos de largura de banda do tráfego. O recente ataque ao Dyn, um provedor de serviços DNS para os principais serviços de internet, foi considerado de 1,2Tbps, quase o dobro do tamanho do maior ataque DDoS de todos os tempos, o que também aconteceu em 2016.
Você pode ler mais sobre ataques do DoS no capítulo 13.
Em 2005, o MySpace (quando ainda era uma coisa) foi atingido por uma vulnerabilidade relativamente inofensiva onde mais de um milhão de perfis de usuários exibiram o texto "mas acima de tudo, samy é meu herói". E tudo isso aconteceu um dia após seu lançamento por Samy Kamkar, de 21 anos. MySpace tem que ser desligado por algum tempo para resolver o problema e Samy foi invadido pelo FBI e colocado em liberdade condicional sem acesso ao computador por três anos. Este foi um exemplo de bug Srcipting cross-site, mais comumente conhecido como XSS. O XSS é uma das vulnerabilidades mais frequentes na segurança da Web. O XSS permite a execução do código JavaScript arbitrário em um navegador de usuários quando o usuário visita um site vulnerável. O código pode carregar outros arquivos JavaScript remotos, roubar cookies e informações de sessão, desfigurar sites, enganar os usuários para divulgar seus segredos que aparecem como o site legítimo ou exibir algum texto como no caso do MySpace e samy. O XSS é discutido no Capítulo 6 e algumas maneiras de atenuá-los usando cabeçalhos modernos embutidos em especificações HTTP recentes são discutidas no Capítulo 11.
Um grupo de pessoas considera que o manuseio inadequado de entradas é a causa principal de quase todos os problemas de segurança. Uma linguagem de programação ou mesmo uma linguagem geral tem geralmente uma gramática definida que auxilia na doação de significado e estrutura ao conteúdo gerado na língua. No caso de linguagens de programação, um analisador é usado para processar o conteúdo e extrair algo útil com ele. Uma vez que os analisadores são em si pedaços de código implementados em alguma linguagem de programação, ele pode conter problemas que podem levar a uma vulnerabilidade de segurança. Uma vez que parsers são peças de código, uma determinada gramática pode ser implementada em vários sistemas diferentes por pessoas diferentes levando a uma variedade interessante de erros. Parsers de codificação manual só podem piorar o problema. Nginx e Apache são dois dos servidores web de código aberto mais usados em uso em todo o mundo. Em 2013, um bug foi descoberto no analisador nginx para cabeçalhos HTTP escritos na linguagem de programação C, o mesmo bug foi descoberto e corrigido no Apache 11 anos atrás. Outro problema na análise do Nome (especificamente Nome Comum) do servidor em certificados HTTPS poderia levar à emissão de certificado para um site legítimo para uma entidade maléfica. Você aprenderá mais sobre HTTPS no próximo capítulo e examinaremos todas as questões relacionadas à entrada/saída no Capítulo 6.
A segurança não precisa dificultar as coisas para os usuários finais. Se a autenticação de dois fatores extravagantes for complicada, diminuiria a adoção entre seus usuários, tornando suas medidas de segurança inúteis. Outro erro comum é não comunicar medidas e ações de segurança efetivamente aos seus usuários. Discutimos questões de design ux e trocas por segurança no Capítulo 17.
Antes de começar a procurar sob o capô dos sistemas, você precisa estar ciente das implicações legais. Em alguns países, algo tão simples como entrar em um computador aberto pertencente a uma organização pode colocá-lo na cadeia por vários anos, mesmo se você fez isso com as intenções certas. A maioria das grandes empresas e startups tem um programa de recompensa por bugs para relatar problemas relacionados à segurança, onde você pode relatar qualquer vulnerabilidade encontrada nos sistemas das empresas e pode ser recompensada por elas se os bugs estiverem dentro do escopo do programa. Se você está ansioso para olhar sob o capô, a melhor maneira de começar seria encontrar empresas com programas públicos de recompensa de bugs e começar com eles.
A menos que você seja um pesquisador acadêmico, você quase nunca chegaria a projetar protocolos e sistemas de criptografia ou mesmo impolomentar um parser grande o suficiente e isso é uma coisa boa. Projetar e implementar qualquer coisa nova é propenso a ser buggy e vulnerável até que muitas revisões sejam feitas a ele. No entanto, você deve estar ciente das escolhas disponíveis para você e fazer uma escolha informada avaliando todas as trocas. Este guia irá ajudá-lo a tomar melhores decisões relacionadas à segurança. Você seria capaz de evitar armadilhas como a segurança pela obscuridade. Você apreciaria a necessidade de funções de hash mais fortes e talvez até mesmo ter o desejo de olhar sob o capô sempre que estiver usando um sistema online, enquanto conhece as repercussões. À medida que você avança através deste guia, nosso objetivo é começar do nada e fazer você entender os cenários de ataque mais comuns e maneiras que você como desenvolvedor pode evitá-los. Você será capaz de evitar armadilhas comuns enquanto escreve código ou configura seus sistemas. Pode haver uma porcentagem de leitores que podem achar este guia lento, por favor sinta-se livre para pular algumas partes do guia e enviar qualquer feedback para guide@fallible.co