Dias desses fui pego de surpresa por um cliente de um site. Ele disse que haviam invadido o site e que os clientes dele podiam, de alguma forma obscura, ver os dados uns dos outros. No mercado financeiro isso é fatal pois trata da privacidade do cidadão. Ninguém quer seu sigilo bancário exposto na web para qualquer um. O desespero foi total!
Foi aí que entrei na jogada para entender o problema e procurar as alternativas. O primeiro dos problemas era bem básico: passagem de parâmetros por querystring. Que vacilo deixar isso passar. Porém, como já conheço bem a equipe e a forma como os requisitos não-funcionais são tratados no ambiente, não culpo os desenvolvedores. De qualquer forma o acerto emergencial foi mesmo criptografar os parâmetros. O método foi o RC4. Ele gera uma criptografia boa o suficiente para esses casos. Apesar de a url ficar enorme esse foi o método mais rápido possível para fechar logo a brecha. Depois mudamos para passar os parâmetros por post. O correto mesmo e que foi sugerido é que mesmo enviando dados de forma segura se valide se o usuário em questão tem acesso aqueles dados. Em todas as consultas que sejam críticas esse tipo de verificação é a unica forma de garantir que apenas ele consegue visualizar seus dados. Alguém pode até se passar por ele mas aí já é outra história!
O outro bendito problema era o javascript injection. Esse me arrepiou os cabelos!!! Isso porque o site já havia sido projetado de forma deixar essa brecha fechada. Como diabos isso foi acontecer. Os usuários estavam conseguindo mudar parâmetros dentro do javascript da página usando o prompt do navegador. Ao menos para mim foi sinistro descobrir isso! Solução: hijack de função e uso de método privado em javascript.
No primeiro caso o que implementamos foi modificar o comportamento das funções dinamicamente. Atribuiu-se a função que gerava os links com parâmetros um alert de acesso negado conforme o exemplo:
<a href=”javascript: funcao.Link.Cms(’sasasas’, ‘asasasas’);”>asas</a>
Logo em seguida foi tudo modificado para não permitir a utilização direta (pública) dessas funções usando um conceito básico de métodos privados em javascript. Pronto! Agora não é possível acessar as funções e variáveis publicamente e o comportamento só é setado quando um click de link é disparado! Ufa!
Só para relembrar: o correto mesmo é já projetar a aplicação com esse tipo de proteção. Isso pode ser feito de muitas maneiras. Esse exemplo foi uma solução às pressas!!! Não siga isso. Aprenda com o exemplo e desenvolva uma solução melhor!
Comment