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

Thiago Zaninotti thiago at zaninotti.net
Mon Dec 28 10:47:30 EST 2009


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-brazilian/attachments/20091228/55437474/attachment.html 


More information about the Owasp-brazilian mailing list