Noções de Segurança da Informação para Times de Desenvolvimento Web – Parte 2

Na primeira parte de noções de segurança da Informação, tentamos definir tanto o que é um ataque como traçar as motivações por trás de um, além de introduzir o tema de Injections, com um foco em sql injections. Desta vez, vamos focar menos na parte técnica e mais na camada humana.

O objetivo nesta segunda parte é detalhar sobre como decisões no desenho do software podem impactar os usuários em produção, desde o vazamento de informações pessoais, até a permissão de combinações fracas de login.

2 – Autenticação

Assim como injection é um problema mitigado pelo consciente uso de padrões estabelecidos, autenticação é um problema mitigado pela não reinvenção da roda. Porém, diferente de injection, autenticação não depende somente de garantir que “sasuke123” inseriu a senha referente ao login “sasuke123”.

 

Há uma distinção entre a camada humana (quem interage com o sistema) e a camada de software (o sistema em si). O foco desse post vai ser na camada humana, que certamente é onde a grande maioria das vulnerabilidades de autenticação acontecem hoje em dia. 

 

Sobre a camada de software, há diversas ferramentas que já foram testadas e aprovadas, desde implementações dos próprios frameworks ou recomendadas pela comunidade, até implementações externas, e do ponto de vista de desenvolvimento web, o melhor a se fazer é estudar as ferramentas e seguir o caminho trilhado. 

 

A Falha Humana na Segurança da Informação

Por mais polido que o seu sistema seja, se ele permitir a criação de uma conta com o login “tico” e a senha “teco”, as pessoas vão utilizar essa combinação e isso é uma falha de design onde o risco em potencial é relativo a quem possa vir a usar esse tipo de login e senha. 

 

Por exemplo, a pessoa que administra o sistema possuir como login “admin” e senha “12345”. Isso significa que todo o seu site está em perigo, mesmo que o software seja tecnicamente seguro. Um exemplo disso são modems que vêm de fábrica com uma senha padronizada que pode ser facilmente pesquisada na internet, como: “admin” -> “gvt12345”.

 

Essa falha de design costuma ser evidenciada em sistemas onde há gerenciamento de conteúdo e pessoas. Quando cada conta possui uma crescente de responsabilidades e agência dentro do sistema: 

 

conta anônima -> registrada -> moderação -> produção de conteúdo -> administração

 

Nestes casos, é importante que a cada degrau, os métodos de autenticação sejam mais rígidos. Porém, a realidade é que o sistema de autenticação do usuário costuma ser mais forte (para dar um ar de segurança ao sistema). Mas a mesma rigidez não é aplicada a área administrativa do site. Se uma conta comum é obrigada a usar 2FA e captcha, quem administra também precisa utilizar.

 

A mitigação dessa falha humana sempre varia de sistema para sistema, e é uma queda de braço entre garantir métodos de autenticação fortes. E não frustrar quem usa o sistema, afinal, se as pessoas evitam entrar no sistema por uma autenticação complexa demais, a segurança acaba atrapalhando a usabilidade. A ideia é ter um cinto de segurança e não uma camisa de força quando falamos de segurança da informação. 

 

Essa nuance na hora de desenhar sistemas é o que costuma exigir um planejamento prévio e crítico antes da implementação de ferramentas prontas. O que vai variar de acordo com a importância dos dados a serem protegidos. Por exemplo, um hospital idealmente teria exigências muito mais complexas para autenticação do que o Medium. (Entretanto, não é bem assim)

 

O Ponto de Vista do Atacante em Relação a Segurança

Sempre que um banco de dados é vazado, ou um sistema expõe as senhas de seus usuários, é possível que esses dados se tornem públicos, e assim, como é relativamente fácil para alguém tech savvy conseguir baixar um episódio da sua série favorita assim que ele sai, é relativamente fácil conseguir os dados vazados de uma breach famosa (caso estes dados tenham sido abertos ao público de alguma forma, ao invés de vendidos à indivíduos ou grupos fechados). 

 

A partir do momento que estes dados estão abertos ao público, eles se tornam potenciais portas de entrada ao seu sistema por uma premissa simples:

1. Pessoas costumam utilizar a mesma combinação de login e senha sempre que possível;
2. Caso a plataforma X tenha seu banco de dados vazado, e suas bilhões de contas estejam abertas ao público, é extremamente provável que alguma destas contas pertença a alguém dentro do seu sistema que ainda usa a mesma combinação de login e senha vazados em outra plataforma;

 

Isso faz com que o seu sistema se torne inseguro por cascata, neste caso, o hacker não está atacando o seu sistema, está atacando o padrão humano de se utilizar senhas iguais em múltiplas plataformas. Portanto, é um problema de camada humana, e não de software.

 

Como comentado na parte 1, o objetivo aqui não é parar nenhum gênio do crime, mas sim, não ficar vulnerável ao menor denominador comum. E existem diversas maneiras de se fazer isso, desde exigir uma confirmação por e-mail quando uma conta tenta fazer login de uma localização nova. Até 2FA, ou até mesmo logins por tokens acessíveis somente por app ou e-mail. O importante é fazer da autenticação uma prioridade, e não simplesmente uma solução plug and play.

 

3 – Exibição de Informações Sensíveis

Este também não é um ponto técnico que depende da habilidade de quem desenvolve sistemas, e sim um ponto de design e tomada de decisões conscientes.

 

Aqui, podemos definir “Informação sensível” como qualquer coisa que associe os dados às pessoas. Uma idade e uma cor de cabelo não significam nada a vácuo, mas uma idade com filiação política, nome e endereço são bastante significativos. E o ônus de garantir que estes dados não vão ser usados de forma nociva é sempre no time de desenvolvimento.

 

Não é incomum que informações sensíveis não sejam tratadas sem o devido cuidado, mesmo por empresas grandes. Dados como login e senha são vistos como sensíveis e há um cuidado para que sejam enviadas pela rede sempre encriptados e nunca exibidos em endpoints públicos, mas informações menos óbvias muitas vezes não recebem o mesmo tratamento, até mesmo informações médicas sofrem desse descuido. 

 

O problema aqui é que a exibição de informações sensíveis não tem um custo financeiro muito óbvio, é uma questão mais ética do que prática. Exibir esse tipo de informação permite que toda uma gama de pessoas sofra assédio, possa ter sua identidade roubada ou até mesmo tenha a sua vida em risco.

 

E por “exibir” não me refiro só ao descuido em deixar um endpoint sensível em um ambiente público só por ele não ser indexado, ou transferir informações por protocolos inseguros, o que quero dizer com “exibir”, é que muitas vezes funcionários de dentro da empresa tem acesso a informações que certamente deveriam ser privadas. 

Privacidade e Segurança do Usuário

Por exemplo, vamos supor que seja necessário um exame médico para entrada em uma academia. E no momento do registro, os dados deste exame fiquem associados a sua conta. É muito comum nesse tipo de sistema que todo mundo tenha acesso aos dados. Desde quem atende até quem instrui e pode realmente precisar dessas informações. 

 

Quanto mais pessoas tiverem acesso à informações privadas de alguém, maior a possibilidade de que estes dados sejam usados de forma nociva em algum momento, e eles vão. A questão é: se o sistema conscientemente tenta ou não mitigar esse problema. (reduzindo o número de quem pode acessar uma informação e preferencialmente mantendo um registro de quem tentou ver o que, por exemplo).

 

O importante aqui, é entender que quando seu sistema pede alguma informação de uma pessoa, essa informação deveria ser vistas quando absolutamente necessárias pela quantidade mínima possível de pessoas, e preferencialmente com logs detalhados para manter a segurança da informação.

 

Não é raro que pessoas sejam atendidas em um estabelecimento, e recebam ligações de funcionários que tiveram acesso ao seus telefones pessoais, e muitas vezes até endereço. E casos individuais como esse, com um responsável direto, raramente causam problemas para a instituição que permitiu que isso acontecesse, pois o funcionário é visto como único agente responsável e a instituição como vítima de uma pessoa sem postura ética ou moral, e não necessariamente como uma instituição que não se preocupa com privacidade. 

 

Isso faz com que dificilmente esse tipo de cuidado com a real privacidade dos usuários venha como uma ordem de cima para baixo. A privacidade e segurança de quem usa um sistema não reflete diretamente na venda de um produto, e há poucas chances disso entrar como uma demanda no jira, como qualquer produto IoT demonstra. Mas deveriam receber o mesmo cuidado que o login e senha por parte do time de desenvolvimento com a segurança da informação.

 

4 – Conclusão

O restante da lista OWASP envolve algo que eu não teria muito a dizer. Além do que já está no report (como má configuração de sistemas), ou dados técnicos demais que fogem do escopo desse post (deserialização e logs). Portanto, dessa vez paramos por aqui. 

Posteriormente, nos próximos posts, vamos falar sobre a segurança da informação de forma mais aprofundada. Desta vez para quem tem interesse de se profissionalizar ou tornar infosec um hobbie.