Infinidade

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!

Dia desses em pleno projeto de uma migração de sistema me deparo com um problema. Estamos utilizando a Enterprise Library 5.0 para acesso a dados. Como se trata de um sistema legado onde apenas a interface está sendo migrada (base Oracle) a idéia era simples: usar toda a parte de banco pronta e alterar o mínimo necessário. O objetivo do projeto é melhorar a experiência do usuário ao usar o sistema. Migrando para uma interface web, naturalmente, a experiência do usuário vai melhorar. Hoje o sistema está desenvolvido em Forms (Oracle).

Cá estou com um dos desenvolvedores quando vem o primero dilema. Como já usamos inumeras vezes a EL para acesso ao SQL Server temos vários e vários códigos de referência. Baseados nisso escrevemos as chamados de procedure e tudo mais. Porém, na hora dos testes veio o susto: os objetos command não conseguiam criar a lista de parametros para execução no banco. Depois de uma rápida busca no google veio a resposta: a instrução SQL precisa ser construída com um curinga diferente no caso do Oracle. Ao invés do uso do “@” antes do nome do parametro, precisamos colocar “:”. Aí é que vem o X da questão. A proposta da EL é tornar o acesso independente da fonte de dados. Você pode fazer um acesso específico, mas no final das contas o ganho está em abstrair a camada de dados e passar intruções que seriam traduzidas para necessidade de cada banco configurado. Porque então “cargas d’água” não fizeram ali uma inteligência que traduzisse isso? Se for “@” sendo enviado para uma base Oracle, troca pra “:”. No contrário: fazia-se o inverso oras!

Pois bem, eu não ia perder tempo com um post pra reclamar só disso. Esclarecido que precisávamos escrever as instruções SQL com “:” e não com o “@”, fomos adiante e nos deparamos com outro problema. Esse já foi melhorzinho, mais rebuscado. Ao fazer uso de uma instrução que usava Cursor a EL devolvia um erro dizendo que o número de parâmetros estava errado. Vi e revi: o número estava certo. Daí comecei a me perguntar o que havia de diferente para a EL retornar um erro desse tipo. Me ocorreu que se houve necessidade de adaptar a instrução para que os parametros fossem criados, esse erro de agora era porque ela não conseguia criar um dos parametros da instrução. Daí chutei logo que fosse o cursor. Estava certo. A EL não trata o tipo correto no Oracle para cursores. Tanto é que o Rain Man Alex escreveu um artigo no Code Project sobre esse problema (Microsoft Enterprise Library Data Access Block [DAAB] on Oracle Provider [ODP.NET]). Resumidamente: o cara trocou o provider para Oracle que é distribuído junto com a EL pelo ODP.Net . Ele disponibilizou a EL alterada e detalhou tudo direitinho. Vale a leitura.

De novo não consegui entender como uma biblioteca como a EL chega na versão 5 com esse tipo de furo. Mas beleza, fica aí a dica para quem precisar trabalhar com Cursor no Oracle usando a Enterprise Library. Use a versão com ODP.Net quu tudo roda direitinho.