Expostas ou não, vulnerabilidades são perigosas

Ilustração de Lou Reade

Imagine que você tem um lago no quintal, com um deque de madeira. Certo dia, ao caminhar pelo deque, você percebe que uma tábua está rachada e quase se partindo. Você precisa decidir se vai consertá-la ou deixá-la assim por um tempo e resolver isso mais tarde. Se só você usa o deque, talvez não seja um grande problema. Você sabe que a tábua está quebrada e vai tomar cuidado (se lembrar). Mas e o resto da sua família? E os amigos que vão visitar você? Não há garantia de que todos vão se lembrar, mesmo que você avise. Mais cedo ou mais tarde, alguém vai pisar naquela tábua e tomar um banho indesejado. Basta uma pessoa, um passo. Muitas vezes, uma biblioteca pode ter uma vulnerabilidade conhecida, mas, se o site ou aplicativo em questão não usar uma chamada de método específica, essa vulnerabilidade não fica exposta. Nesse caso, você até poderia ignorá-la: ela simplesmente não afeta seu sistema atual. Mas a palavra-chave aqui é “atual”. O problema das vulnerabilidades é que elas geralmente não são muito óbvias. Não é como se o método vulnerável tivesse um nome claro, como “naoUseNaoÉSeguro”. Em geral, vulnerabilidades são sutis. Basta uma mudança nas configurações ou uma chamada de método aparentemente inofensiva para passar de seguro a vulnerável. Saber se uma vulnerabilidade está exposta hoje é importante, mas não tanto quanto algumas pessoas pensam. Isso pode, sem dúvida, ser um fator decisivo na hora de definir prioridades. Se você precisa corrigir duas vulnerabilidades, e uma está exposta e a outra não, priorize a que está exposta. Mas também é fundamental corrigir rapidamente as vulnerabilidades que ainda não estão expostas. Até que isso aconteça, elas são um ponto fraco no seu aplicativo, uma brecha na armadura. Basta uma alteração no código, feita por um único desenvolvedor, para que se tornem exploráveis. Resiliência importa, e uma vulnerabilidade não exposta, mas ainda sem correção, acrescenta um nível desnecessário de fragilidade. Grande parte do trabalho de segurança é reativa: quem atua na defesa tenta acompanhar as inúmeras formas que um invasor pode usar para atacar seu sistema. Vulnerabilidades conhecidas que ainda não estão expostas no seu aplicativo não devem ser ignoradas. Elas são uma rara oportunidade de você se antecipar e reforçar a segurança antes que algo dê errado. Diante de tantos desafios para proteger nossos sites e aplicativos, devemos aproveitar toda oportunidade de agir de forma proativa para garantir a segurança daquilo que criamos.