[Owasp-brazilian] [Fwd: Re: validação de banco de dados]

Thiago Zaninotti thiago at zaninotti.net
Mon Dec 28 13:18:49 EST 2009


Marcelo,

O executor da transação (programa/procedure/etc) estaria autenticado com o
banco (lembrando que isso já acontece na maioria dos aplicativos web),
porém, os dados continuam tendo origem na interação com interfaces externas
(usuário ou outros sistemas).

Se o usuário for vítima de um XSRF, por exemplo, os dados inputados serão de
origem duvidosa (troca de uma senha de maneira arbitrária, por exemplo). Se
um sistema externo produzir um JSON modificado (envenenado, se preferir), de
nada adianta validar a comunicação da minha transação com o meu banco -- o
dado externo já está comprometido e vai comprometer a integridade do meu
banco de dados.

Não se esqueça que o seu banco de dados reflete as interações entre todas as
interfaces (internas e externas). A melhor saída para o probelma ainda é a
sanitização adequada de todos os dados recebidos através de interfaces e uma
arquitetura segura de comunicação com o banco (ex: SSL ou IPSec -- que o
Fernando Cima lembrou bem).

Abraços,

Thiago Zaninotti,Security+,CISSP-ISSAP,CISM,CSSLP
Restless Infosec & C/C++ Engineer


2009/12/28 marcelojunior at superig.com.br <marcelojunior at superig.com.br>

>
> Olá Thiago,
>
> Sim as duas abordagens seríam possíveis para o que estávamos pensando,
> tanto validando as tabelas quanto as linhas através de hash...
> Sem dúvidas questões de desempenho devem ser considerados, mas performance
> normalmente está do lado oposto do acesso seguro não é...
> Em que cenário você vê como possível a inserção de dados contaminados se
> estivéssemos no cenário de autenticarmos aquelas páginas específicas para
> interagir na base?
>
> Abs. Marcelo Jr.
>
> Marcelo,
>
> O protocolo SSL ou a opção que o Cima estabeleceu são dois controles que
> irão proporcionar a identificação da identidade das partes, permitindo que
> apenas as legítimas tomem ações no banco de dados.
>
> Pelo que eu entendi, o que você está querendo é um validador de dados. Você
> provavelmente irá esbarrar nos seguintes cenários:
>
> - Se estamos trando com um banco de dados estático (Read-Only), é possível
> criar um hash das principais tabelas ou, em casos específicos, do próprio
> arquivo de banco de dados (por exemplo um arquivo sqlite). Não se esqueça do
> ônus de computar o hash para o bloco de queries que irá executar ad-hoc
> (isso certamente será um impasse no desempenho);
>
> - Se estamos falando de um banco de dados dinâmico, com alterações providas
> através de interações com diferentes interfaces (humanas ou máquinas), temos
> um paradigma maior do que o desempenho: nada impede que uma  "thread"
> legítima que possui acesso RW injete dados "contaminados", modificando o
> banco de maneira inapropriada. O cálculo do hash, neste caso, será
> verdadeiro mas com base em informações não legítimas.
>
> Em ambos os cenários, o melhor é garantir a autenticidade das pontas e
> assegurar que exista "sanitização" adequada nas interações de dado (entre as
> diferentes interfaces). Esse é a melhor abordagem (a mais simples também).
>
> Abraços,
>
> Thiago Zaninotti,Security+,CISSP-ISSAP,CISM,CSSLP
> Restless Infosec & C/C++ Engineer
>
>
> 2009/12/28 marcelojunior at superig.com.br <marcelojunior at superig.com.br>
>
>>  Oi Fernando, a opção é ótima para autenticar mas ainda não garante que o
>> banco não foi acessado indevidamente...
>> A idéia é sim garantir que somente as páginas específicas que se
>> "autentiquem" façam o acesso, mas também possibilitar que elas validem que a
>> base é confiável e quem não foi acessada/editada diretamente...
>>
>> Fernando Cima escreveu:
>>
>>   Oi Marcelo,
>>
>>
>>
>> Na plataforma Windows a forma mais simples de fazer isto seria utilizando
>> IPsec entre o servidor Web e o servidor de banco de dados. Você pode usar
>> certificados ou Kerberos para autenticação mútua, que seria transparente e
>> independente de qual servidor Web ou banco de dados você estiver usando.
>>
>>
>>
>> Abraços,
>>
>>
>>
>> - Fernando Cima
>>
>>
>>
>> *From:* owasp-brazilian-bounces at lists.owasp.org [
>> mailto:owasp-brazilian-bounces at lists.owasp.org<owasp-brazilian-bounces at lists.owasp.org>]
>> *On Behalf Of *marcelojunior at superig.com.br
>> *Sent:* segunda-feira, 28 de dezembro de 2009 14:07
>> *To:* owasp-brazilian at lists.owasp.org
>> *Subject:* Re: [Owasp-brazilian] [Fwd: Re: validação de banco de dados]
>>
>>
>>
>> Entendi.
>> Há algum case prático em que a restrição da interação na base seja
>> possível usando PKI? Não consigo imaginar a implementação...
>> Além disso, existe alguma forma de checagem possível nessa sugestão ou
>> apenas confiaríamos que o uso de chaves públicas foi usado e a base está
>> confiável?
>>
>> Abs. Marcelo Jr.
>>
>> Thiago Zaninotti escreveu:
>>
>> Marcelo,
>>
>> Não estou focando na proteção da transmissão mas utilizando o serviço de
>> identificação da sessão do SSL para identificar as pontas. Basta invocar
>> este serviço para beneficiar-se de uma troca de informações entre pontas
>> conhecidas.
>>
>> Abraços,
>>
>> Thiago Zaninotti,Security+,CISSP-ISSAP,CISM,CSSLP
>> Restless Infosec & C/C++ Engineer
>>
>>  2009/12/28 marcelojunior at superig.com.br <marcelojunior at superig.com.br>
>>
>> Olá Thiago,
>>
>> Quanto mais eu vejo posts mais penso que podemos estar filosofando sobre
>> algo já pronto...
>> Porém, penso que em relação a sua contribuição não seja o caso, já que
>> apesar de ser boa prática a adoção de ssl, não estamos focando na proteção
>> da transmissão...
>>
>> Abs. Marcelo Jr.
>>
>> Thiago Zaninotti escreveu:
>>
>> Oi Marcelo,
>>
>> Isso parece reinvenção da roda -- ou talvez eu esteja pegando o bonde
>> andando e querendo sentar na janela (me desculpe se for esse o caso).
>>
>> O que você está sugerindo é enrijecer a segurança da comunicação com o
>> banco de dados. Oras, porque fazer isso de uma maneira tão complexa
>> (implementada no nível de aplicação) quando você pode simplesmente enrijecer
>> o protocolo -- passe a utilizar troca de chaves públicas entre o aplicativo
>> web e o servidor de banco de dados através de uma camada de protocolo
>> tradicional (SSL).
>>
>> A eficácia da segurança de um sistema está na simplicidade de seus
>> mecanismos.
>>
>> Abraços,
>>
>> Thiago Zaninotti,Security+,CISSP-ISSAP,CISM,CSSLP
>> Restless Infosec & C/C++ Engineer
>>
>>  2009/12/28 marcelojunior at superig.com.br <marcelojunior at superig.com.br>
>>
>>
>> Oi Fernando,
>>
>> Pelo contrário, atribuindo uma "assinatura" às páginas legítimas seria um
>> impeditivo a mais para as explorações que citou...criando-se um hash
>> reproduzível apenas pelas páginas que tem acesso à esta "chave" criada,
>> teríamos uma camada de proteção extra que garantiria a integridade da
>> base...Para injections de consulta, já são tratados caracteres permitidos e
>> outras abordagens.
>> Dependendo do grau de comprometimento do server, obviamente essa e outras
>> contra-medidas perdem efeito...
>> O cenário que vislumbramos seria o de que pudéssemos verificar a cada
>> transação com o banco se o mesmo está "íntegro", através de um hash gerado a
>> partir dos dados imputados, com base em uma chave conhecida apenas pelas
>> páginas legítimas (conceito de criação de mensagens smime por
>> exemplo)...desta forma mesmo um acesso desautorizado que efetuou um exclude,
>> edit ou include seria detectado na próxima transação, que não reconheceria
>> os hashes verificadores e faria por exemplo um alerta seguido de fall-back
>> para última versão de backup salva...
>>
>> Abs. Marcelo Jr.
>>
>> Fernando Cima escreveu:
>>
>> Oi Marcelo,
>>
>>
>>
>> Qual seria a ameaça que você quer evitar?
>>
>>
>>
>> Se eu entendi direito a sua idéia, isso não seria proteção nenhuma contra
>> por exemplo um SQL injection ou CSRF, ou cenários onde o servidor Web foi
>> comprometido.
>>
>>
>>
>> Abraços,
>>
>>
>>
>> - Fernando Cima
>>
>>
>>
>> *From:* owasp-brazilian-bounces at lists.owasp.org [
>> mailto:owasp-brazilian-bounces at lists.owasp.org<owasp-brazilian-bounces at lists.owasp.org>]
>> *On Behalf Of *marcelojunior at superig.com.br
>> *Sent:* segunda-feira, 28 de dezembro de 2009 11:06
>> *To:* owasp-brazilian at lists.owasp.org
>> *Subject:* Re: [Owasp-brazilian] validação de banco de dados
>>
>>
>>
>> Olá chará,
>>
>> Por páginas eu me referi à todas as webpages (asp´s ou php´s) da internet
>> ou extranet que fazem interação com a base (input, exclude, edit)...
>> O link do projeto me deu novas idéias...o produto é muito bacana! Obrigado
>> pela dica.
>> É uma outra abordagem, mas que pode levar-nos à resultado parecido...
>> Com o produto eu consigo listar quais são as interações permitidas e isso
>> limitaria bastante as "sql statements" que não são conhecidas e portanto não
>> poderíam partir das páginas legítimas, apesar de não garantir de fato a
>> procedência da query e nem inserir verificadores na base para "check"
>> posterior como havíamos pensado.
>>
>> Abs. Marcelo Jr.
>>
>> Marcelo M. Fleury escreveu:
>>
>> "geração de hash em todas as páginas que interagem com o banco,
>>
>> garantindo que somente as transações "legais" oriundas dessas páginas
>>
>> possam ter a capacidade de gera-la" O que seriam essas paginas ?
>>
>>
>>
>> Existe um projeto chamado GreenSQL que é inclusive open source, veja:
>>
>> http://www.greensql.net/
>>
>>
>>
>> Traz o conceito de firewall para a camada de dados, apesar de não ter
>>
>> ele em produção, achei fantástico o seu propósito. Se você partir para
>>
>> uma solução caseira, acredito que além dos hash's que são difíceis de
>>
>> manter e com uma maior custo computacional, seria legal pensar em
>>
>> regex, claro sempre atento para as maneiras de bypassar as
>>
>> assinaturas,,, multiline, encoding(com acentos... tem um post
>>
>> interessante do nash sobre isso aqui na lista).
>>
>>
>>
>> []s
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Owasp-brazilian mailing list
>> Owasp-brazilian at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-brazilian
>>
>>
>>
>>
>> _______________________________________________
>> Owasp-brazilian mailing list
>> Owasp-brazilian at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-brazilian
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Owasp-brazilian mailing listOwasp-brazilian at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-brazilian
>>
>>
>> _______________________________________________
>> Owasp-brazilian mailing list
>> Owasp-brazilian at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-brazilian
>>
>>
>
> _______________________________________________
> Owasp-brazilian mailing list
> Owasp-brazilian at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-brazilian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-brazilian/attachments/20091228/ca53c8f2/attachment-0001.html 


More information about the Owasp-brazilian mailing list