O crescente aumento da velocidade de acesso a internet junto com a oferta de serviços de banda larga em todo o Brasil, está criando uma crescente demanda por Softwares que são ofertados como Serviço e que em suma maioria rodam online, e são hospedados em servidores com acesso a internet e que possuem uma arquitetura aberta, seja através de uma API ou de acesso aos servidores de dados compartilhados. Essa arquitetura, traz inúmeros benefícios para os usuários que passam a ter acesso ao software em todo o lugar e muitas vezes através de um celular ou tablet, além de manter uma sincronia e melhorar a experiência de uso por parte dos consumidores. Por outro lado, essa abertura de arquitetura, traz para os desenvolvedores uma série de preocupações com segurança da informação, compartilhamento da informação e escalabilidade dos sistemas, e sobre esse pontos que vamos fazer uma rápida abordagem neste artigo.
Nos primeiros sistemas baseados em mainframes, estes enormes computadores realizavam todo o processamento dos dados, e as aplicações eram acessadas através de terminais que simplesmente tinham acesso aquilo, toda e qualquer alteração era demorada porém controlada e centralizada. Com o barateamento dos sistemas de informática, as empresas começaram a fazer uso dos computadores para processarem diversos ramos diferentes de dados, nesta época, o volume de aplicações e usos dos computadores foi cada vez mais difundido, e ampliado.
Com o surgimento dos microcomputadores e computadores pessoais, e a crescente tecnologia de comunicação de redes e interfaces cada vez mais intuitivas, fez aumentar a demanda pela informação, e praticamente qualquer empresa indiferente do seu porte passou a ter um computador para realizar algum processo, seja ele um simples cadastro de clientes ou toda a automação comercial e acesso as mais novas tecnologias, nesta segunda fase, houve uma explosão de sistemas especializados nos mais diversos ramos de atividade empresarial ou comercial e industrial.
Posteriormente, na década de 80, o novo boom nas aplicações corporativas era o compartilhamento de dados através de rede local, o que começou a trazer para a mão dos desenvolvedores problemas relacionados a controle de acesso lógico, concorrência, e otimização de dados, permitindo que houvesse essa troca de informações, e a necessidade de informações atualizadas era uma constante, neste momento, um gerente de loja, queria ver na hora, as posições de estoque, faturamento, entre centenas de outros dados.
Na década de 90, somente o acesso através da rede, não era mais suficiente, agora os sistemas precisavam ter acesso remoto, e a troca de dados deveria ocorrer entre as filiais, que poderiam estar em uma mesma cidade, ou em países diferentes e o acesso era realizado via internet, neste momento, houve um enorme esforço por parte de empresas de software, desenvolvedores e consórcios para a padronização da troca de dados, e para o crescente aumento da segurança da informação, além da criação de inúmeros padrões de comunicação e protocolos.
Com a consolidação da internet, durante os anos 90, e a difusão do acesso, através das redes sem fio, já no inicio do milênio, a troca de dados passou a ser uma constante, e os sistemas de informação não bastavam trazerem as informações em tempo real, agora, os computadores pessoais podiam ser carregados de dentro da empresa e gerentes e funcionários podem acessar os dados e por exemplo emitir um pedido de venda diretamente do estabelecimento dos clientes, consultar andamento de entregas e posições de estoque, trazendo na hora todas as informações necessários, e permitindo uma maior agilidade na tomada de decisões.
Por fim, mais de uma década se passou, e a nova onda era o compartilhamento de dados, agora não só os funcionários tinham que ter acesso, mais também, os clientes podiam fazer uma compra online, verificar o andamento do pedido diretamente dos celulares, podiam compartilhar as informações em suas redes sociais entre outros, e por outro lado, as industrias podiam receber pedidos dos seus distribuidores de maneira integrada com os sistemas de venda, os sistemas agora precisavam ser altamente abertos, possuírem alta disponibilidade de acesso e de disponibilização dos dados, além de serem fáceis de serem usados através de interfaces cada vez mais intuitivas.
Nos dias de hoje, é impossível imaginar o desenvolvimento de uma aplicação que não tenha acesso ao compartilhamento de dados, interoperabilidade entre plataforms e o uso de API´s para permitir a integração com diversas integrações sociais e plataformas diferentes, este é o novo modelo de software, não basta fornecer um sistema como um produto, onde o cliente compra a aplicação e a utiliza da maneira que ela vem, adaptando seus processos a forma como a aplicação foi desenvolvida e pensada. Atualmente, tanto a infraestrutura de TI como o software são vistos como um serviço, ou seja, você não depende mais de um único fornecedor de hardware, e de software e telecomunicação, tudo roda em um ambiente compartilhado (cloud) onde é possível escalonar a disponibilidade de recursos para um aumento de demanda ou estar sempre atualizado com as melhores praticas e recursos.
Os Problemas
Se você leu até aqui, deve ter visto que a complexidade dos sistemas de informação atualmente é muito maior que nas décadas anteriores, na mesma proporção que os dados são facilmente acessados por quem precisa deles, centenas de dados valiosos trafegam por redes que podem ser acessadas publicamente, e existem empresas e pessoas que querem ter acesso a estes, sem a devida permissão, e é responsabilidade dos desenvolvedores garantirem a segurança e o controle de acesso.
As principais vulnerabilidades de sistemas de informação, são falhas no acesso e compartilhamento de dados, e que podem expor dados sensíveis causando prejuízos imensuráveis tanto para as corporações que dependem desses dados quanto para as pessoas que tiveram dados e informações sigilosas expostas ou exploradas. Alguns pontos devem ser checados pelos desenvolvedores para garantir pelo menos um mínimo de segurança para os usuários.
Os tipos de ataques mais amplamente explorados são também os mais simples de serem mitigados simplesmente com uso de um desenvolvimento consciente, e a atenção dos desenvolvedores aos pontos mais vulneráveis, ou seja, são os mais básicos e também os que causam os maiores prejuízos monetários, físicos e sociais. Nenhum site está totalmente seguro, do ponto de vista dos dados, muitas vezes, os desenvolvedores só percebem uma falha quando está é explorada, ou seja, só pensam em fechar as portas da casa depois da casa ter sido arrombada.
Entrada de dados não validados é o maior desafio para qualquer time de desenvolvimento e é a origem dos problemas de segurança de muitas aplicações. De fato, muitos dos itens presentes na lista recomendam a validação de entrada como parte da solução.
Falta de SSL ou HTTPS
Quando você acessa um site, os dados trafegados passam por ulguns servidores, e não são uma ligação direta entre seu computador e o site, você pode verificar isso, rodando um traceroute, que vai mostrar por quantos servidores e roteadores seus dados estão passando antes de chegarem ao destino final.
Veja, na tela, usando um serviço online de traceroute (http://www.isptools.com.br) vemos que para acessar o site do blog (www.brasap.com.br) desde o site de origem até o destino final, os dados passaram por 6 servidores, e não é incomum, vermos registros onde mais de 30 servidores foram acessados. Se você não utiliza um certificado SSL, os dados trafegados são visíveis abertamente, e mesmo que você tenha usado autenticação em 2 fatores, e toda a segurança no gerenciamento de sessão, se em algum destes saltos outros usuários estiverem escutando ou analisando o trafego de rede, todos os dados trocados podem ser lidos, como um texto.
Quando um certificado SSL está habilitado, criando uma conexão segura entre você e seu cliente ou visitante, antes de qualquer dado ser trafegado, os pontos de origem (seu computador ou o computador do visitante) e o servidor, fazem um HANDSHAKE (aperto de mão) e neste momento, trocam uma chave de criptografia que será usada para criptografar e descriptografar os dados trocados, mesmo que eles passem por diversos pontos pelo meio do caminho, o que será visto serão basicamente um monte de caracteres não legíveis, pois para descriptografar os dados somente é necessário conhecer a chave pública, trocada no HANDSHAKE.
Na imagem ao lado, o “TEXT” é o conteúdo que seria enviado para o usuário, se ele estiver usando um certificado SSL a unica coisa que alguém que interceptasse a comunicação veria seria o conteúdo do campo “ENCRYPTED” já em uma conexão sem o SSL o intercptor veria o conteúdo do campo “DECRYPTED”. Se você quiser ler mais detalhes de como funciona um certificado digital SSL, leia este artigo da ajuda do google chrome sobre o assunto (https://support.google.com/chrome/answer/95617).
Um dos pontos mais vulneráveis é justamente a tela de login, ou mesmo a exibição de dados sensíveis somente a pessoas certificadas, mesmo que você tenha tomado todas as precauções na validação, se alguém conseguir ter acesso as credenciais do usuário, pode se passar por ele, e ter acesso ao conteúdo restrito. Este tipo de falha, pode ser mitigado, simplesmente fazendo a verificação e só permitir o acesso ao envio de login e senha se estiver em uma conexão segura, em usar regras para mesmo que o usuário acesse o sistema ou site fora do HTTPS direciona-lo forçadamente para a versão HTTPS.
SQL INJECTION
Este tipo de falha ocorre, quando o desenvolvedor não faz as devidas checagens de segurança do conteúdo recebido através da conexão, geralmente em campos de entrada do usuário, ou em qualquer outra entrada proveniente da conexão, e que possa de qualquer maneira ser editado ou alterado pelo usuário ou navegador. Muitas vezes, os desenvolvedores até validam parte das entradas, mais se esquecem de alguma, e justamente esse elo mais fraco pode ser usado.
Se você quer ler de maneira mais aprofundada como funciona este tipo de ataque, leia este artigo, aqui do blog mesmo: (https://brasap.com.br/injecao-sql-sql-injection-exemplos-e-como-se-prevenir/) que trata especificamente deste assunto.
Este é um tipo de ataque muito comum, e que uma grande parte dos sistemas acaba sendo vulnerável, simplesmente porque o desenvolvedor esqueceu-se de um único ponto de checagem. É responsabilidade dos desenvolvedores terem rotinas de teste que garantam que a injeção de SQL não esteja ocorrendo, pois somente este tipo de proteção, reduz muito a probabilidade de vazamento de informações e conteúdos.
Atualmente a maioria das linguagens já possui ferramentas para fazer essas validações de entrada e praticamente todos os frameworks também usam técnicas de acesso aos dados que mitigam esse tipo de ataque, cabe ao desenvolvedor utiliza-las e garantir que o sistema esteja usando as versões mais atualizadas das bibliotecas de acesso a dados, de compilações das linguagens em caso de linguagens interpretadas e toda a garantia para validar, bloquear e isolar este tipo de ataque. Além de criar em suas rotinas de teste casos para esse tipo de validação.
Existem no mercado alguns utilitários de segurança, escritos com o propósito de validar as possíveis formas e explorar de meneira segura, dando ao desenvolvedor uma ferramente de apoio a realização dos testes de segurança de seus sistemas. Uma das ferramentas mais comuns para este tipo de teste é a SQLMAP que você pode avaliar e utilizar em (https://github.com/sqlmapproject/sqlmap)
ATAQUES DE FORÇA BRUTA
Muitas vezes o sistema de login acaba sendo alvo de ataques de força bruta, e estes podem ocorrer de diversas formas, é responsabilidade do desenvolvedor, criar em suas rotinas de autenticação formas para prevenir que este tipo de ataque possa ocorrer.
Este tipo de ataque ocorre de algumas maneiras diferentes, na maioria das vezes o atacante faz dezenas ou milhares de tentativas de acesso seja de um mesmo IP ou de uma mesma rede, seja de redes distribuidas, tentando encontrar por força bruta uma senha válida, para ter acesso ao sistema. Esse tipo de ataque é mitigado, quando o sistema consegue entender que um dado usuário esta tentando acesso forçado, verificando se ele está tentando acesso de diferentes localidades, ou usando credenciais diferentes de um mesmo endereço.
Uma boa prática é ter rotinas de verificação de localização de acesso por ip ou geolocalidade, ter limites te tentativa seguidas, validar se os usuários e senhas testados estão vindo de um mesmo ponto, e ter delay diferente de resposta, seja para acesso válido como acesso inválido. A combinação de mais de um destes métodos é sempre a melhor recomendação.
Este tipo de ataque, pode ser forçado, principalmente quando outros sistemas geralmente de redes sociais acabam tendo vazamentos de dados, e os atacantes recebem acesso aos dados vazados e passam a explorar com essa lista de credenciais outros sistemas. Um dos pontos usados, é que a maioria dos usuários, acaba usando senhas, que seguem um padrão, de maneira a conseguir se lembrar de todas elas, isso acaba gerando as famosas bases de senhas, que são nada mais nada menos que uma combinação das senhas mais utilizadas, ou dos padrões.
Para diminuir este tipo de ataque, além das validações de origens, são boas práticas a exigência do uso de senhas seguras, trocas periódicas de senhas, uso de autenticação em 2 fatores para dados mais sensíveis, log de todas as tentativas de acesso bem sucedidas e mal sucedidas, entre outros, uso de serviços e servidores de autenticação, onde é possivel ao usuário realizar a autenticação em um ponto, receber uma credencial de acesso e fazer o acesso em outro sistema com essa credencial.
As falhas ou vulnerabilidades nos mecanismos de autenticação são comuns, mas pontos mais fracos e esquecidos geralmente são explorados e introduzidos a partir de funções menos importantes como o logout (saída), gerência de senhas(armazenamento destas no banco de dados), timeout (desconexão de um usuário autenticado, sem as devidas finalizações), recordação de dados de logon (salvar dados de autenticação do lado do usuário), perguntas secretas ou formas de recuperação de senhas e atualizações de conta ou mesmo de dados.
Tão importante quanto garantir a autenticidade no login, é garantir que todas as ações realizadas estão sendo provenientes do mesmo ponto de origem, ou seja, de um mesmo navegador ou endereço físico, garantir, que quando o usuário saia, seja impossível re-utilizar as credenciais e sessões geradas por ele, garantir que ninguém tenha acesso aos dados de login e senha da maneira como foram inseridas (texto puro) em nenhum nível da organização, utilizar técnicas de HASH e CRIPTOGRAFIA de dados, com os níveis adequados de segurança ao tipo de dado que está sendo trafegado, criar formas que garantam que quando um determinado usuário tenha perdido suas credenciais, ele esteja realmente tentando recupera-las seja usando uma segunda senha (frase de segurança e pergunta/resposta) e notifica-lo de todas as maneiras possíveis que ele está realizando essa ação, de maneira a prevenir uma ação prolongada em caso de comprometimento.
Quando criamos uma recuperação de senha, garantir, que ela tenha um prazo de validade, o mais curto possível, para evitar ataques pronlogados, o que nos leva a um outro tipo de ataque comum, que veremos abaixo, a transferência de responsabilidade
TRANSFERÊNCIA DE RESPONSABILIDADE
Os ataques de transferência de responsabilidade, ocorrem, quando um usuário realmente autenticado, manipula dados de sua conexão, para por exemplo obter níveis mais elevados de acesso, ou acesso a dados de outros usuários, por exemplo manipulando uso de sessões e forjando dados. Este tipo de ataque é dificil de ser identificado num primeiro momento, pois depende da lógica e da validação para níveis diferentes de acesso.
Por exemplo, um usuário digamos de um plano básico solicita acesso a recursos de um plano intermediário, em algumas situações, é possível simplesmente manipulando os dados da requisição a API ou de solicitação do serviço que ele consiga as respostas, ou que o perfil de usuário seja transmitido, transferindo para o usuário a responsabilidade pelo controle de acesso.
Para mitigar esse tipo de ataque, você deve ter em mente que mesmo depois de autenticado, o usuário pode ser capaz de manipular qualquer dado de acesso, ou mesmo, quem está autenticado ser outra pessoa (um atacante) se passando pelo usuário legítimo afim de obter acesso não autorizado. Lembre-se que as credenciais de acesso podem não terem sido roubadas ou violadas no seu próprio sistema, mais sim em outros, dos quais você não tem nenhum controle. Credenciais roubadas, podem ser válidas (como dito, muitos usuários usam um mesmo email para relizar dezenas de cadastros em sistemas diferentes, ou mesmo um mesmo par de usuário e senha em diversos sites ou aplicações diferentes) e usadas para acessar seu sistema e fraudar outros acessos. Lembre-se de SEMPRE que houver necessidade, voce deve ter rotinas que GARANTAM que o usuário mesmo autenticado não está manipulando ou tentando fraudar suas credenciais de acesso.
Ambiente Seguro e Problemas de Configurações
Gerenciamento de configurações principalmente em servidores web pode tornar uma aplicação que foi feita tomando todas as medidas de segurança insegura, isso afeta todos os sistemas coexistente em alguma extensão, particularmente linguagens web como o PHP ou .NET o Python, JAVA e uma centena de outras pode sofrer com isso. A contra medida mais eficaz é utilizar as diretrizes de configuração mais restritivas onde a politica só libera o que é estritamente necessário, além, de evitar uso de servidores compartilhados onde não se tenha total controle sobre o software existente e instalado em TODAS as instâncias, principalmente para aplicações que lidam com dados críticos e sigilosos.
Outra prática para mitigar problemas de configuração é manter os softwares, linguagens, sistema operacional atualizados sempre na última versão, já que uso de versões estáveis e amplamente testadas tendem a ter menos problemas, além de que as proprias comunidades e empresas desenvolvedoras apresentam soluções para correções de flahas e configurações o que evita que falhas já amplamente conhecidas possam ser exploradas.
A Falda de backup é também uma grande falha de segurança, já que não só falhas de acesso podem causar corrupção e prejuizos, nenhuma empresa está imune a falhas de servidores ou outros hardwares, todo o equipamento elétrico e eletrônico pode parar de funcionar, o sistema pode ser invadido, data centers podem apresentar indisponibilidade temporária, entre outros tipos de problemas que podem ocorrer no ambiente corporativo e comprometer as suas operações, quando se tem um backup, a recuperação de dados é rápida e praticamente não afeta a continuidade dos serviços. O plano de contingência é essencial para que as equipes saibam como proceder caso venha ocorrer falhas técnicas e/ou operacionais. Dessa forma, as atividades poderão ser restabelecidas em um espaço menor de tempo, com o mínimo de prejuízo.
Lembre-se que essa mudança para sistemas de backup devem ser sempre testadas em momentos de menor uso, e também em falhas simuladas e parciais, pois os equipamentos de backup geralmente possuem configurações diferentes e muitas vezes desatualizadas, manter tudo orquestrado e em perfeita sincronia é parte importante de uma politica de segurança e deve ter um espaço de destaque na atenção do pessoal de TI.
USO DE CRIPTOGRAFIA
Nossos sistema, muitas veses está sendo executado em um ambiente compartilhado, como um servidor WEB ou mesmo um serviço de CLOUD ou distribuído através de REDES DE CONTEÚDO e estas podem ter falhas de segurança e permitirem vazamentos dos dados, seja nos servidores de aplicação, servidores de autenticação, servidores de API ou servidores de bancos de dados, ou mesmo em sistemas AUTOESCALONADOS, podem haver falhas que permitam que dados possam ser copiados ou roubados e que outros usuários possam ter acesso a eles.
Dados muito sensíveis, devem ser armazenados já com uso de criptografia, garantindo que somente quem deve ter acesso a eles seja capaz de visualiza-los ou manipula-los. Uso de chaves criptográficas vem se tornando comuns, devido ao seu baixo custo, e com a crescente capacidade de processamento, podem ser mais amplamente utilizadas.
Neste ponto, uma das MAIORES falhas de segurança, é também causada pelo ego, muitos programadores acreditam que conseguiram criar um algoritmo próprio ou mais seguro que o uso dos tradicionais, e como não são especialistas em criação deste tipo de funções matemáticas complexas acaba criando algo vulnerável. Usar as versões mais recentes das bibliotecas públicas, testadas e aprovadas por orgãos de segurança, sempre será uma melhor opção.
Sempre seja permissivo, obrigar o uso de combinações excentricas é uma falha, adicionar complexidade desnecessária a uma senha, vai invariavelmente fazer com que o usuário tenha que recorrer aos mecanismos de recuperação de senha, que são menos seguros e que podem aumentar a chance de falha, monitorar o número de usuários e o número de requisições para este tipo de rotina de recuperação de credencial, serve como um termometro para validar se suas regras podem estar sendo coercivas demais. Já ví sites, que exigiam senhas com 32 caracteres, e pelo menos 12 digitos diferentes, além de letras maiusculas, minusculas e simbolos. Nem mesmo os geradores de senha eram capazes de gerar senhas que fossem aceitas de primeira, imagine para alguém que não usa um software desses se seria possível se recordar da senha. E o pior, ao pedir para ser lembrado da senha, recebia-mos ela por email, ou seja, ela de alguma maneira, que nem quero pensar como, era salva no banco de dados sem uso de HASH.
Hashing vs criptografia
O hash e a criptografia fornecem maneiras de manter os dados confidenciais protegidos, impedindo-os de serem lidos a olho nú. No entanto, em quase todas as circunstâncias, as senhas devem ser hash, NÃO criptografadas. O hash é uma função unilateral (ou seja, é impossível “descriptografar” um hash e obter o valor do texto original). O hash é apropriado para validação de senha, e outras informações de verificação. Mesmo se um invasor obtiver a senha como hash, ele não poderá inseri-la no campo de senha de um aplicativo e efetuar login como a vítima.
A criptografia é uma função bidirecional, o que significa que o texto original pode ser recuperado. A criptografia é apropriada para armazenar dados como os endereços, emails, documentos e outros dados, que precisam ser recuperados e lidos, uma vez que esses dados são exibidos em texto. No contexto de armazenamento de senhas, a criptografia deve ser usada apenas em casos extremos em que é necessário obter a senha em texto simples original. Isso pode ser necessário se o aplicativo precisar usar a senha para se autenticar em outro sistema, como salvar os dados de autenticação para uma API externa por exemplo que não ofereça suporte a uma maneira moderna de conceder acesso programaticamente, como OpenID Connect (OIDC). Sempre que possível, uma arquitetura alternativa deve ser usada para evitar a necessidade de armazenar senhas em uma forma criptografada.
Políticas de Segurança
Uma das grandes falhas da segurança de sistemas online é justamente a falta de uma politica clara dos processos e as responsabilidades, manter um registro escrito e acessível a todos é uma obrigação da equipe de TI. Você sabia que grande parte dos vazamentos de informação, vem justamente dos próprios usuários que deviam zelar pela segurança, e acabam compartilhando informações sigilosas ou mesmo senhas e credenciais de acesso. Não adianta ter um sistema impecavel, que zela por todas as boas práticas, se não existe uma responsabilidade de utilização por parte dos próprios usuarios e proprietários.
Segurança não é um evento único. Não é suficiente considerar a segurança de código uma única vez, é algo que constantemente precisa ser revisto, novas técnicas e procedimentos devem ser empregados na mesma velocidade onde as falhas de segurança são encontradas. Uma iniciativa de codificação segura deve abordar todos os estágios do ciclo de vida de um programa.
