[Owasp-brazilian] retomando a discussao sobre comunicacoes inseguras

Myke mykesh at gmail.com
Fri Feb 20 19:41:52 EST 2009


Nash,

Se a comunicação for subvertida, de que adianta ter criptografia no cliente?

Não vai ajudar em nada a criptografia no cliente, no lugar do "applet
do bem" pode-se simplesmente injetar um "applet do mal" e o cliente
vai pensar que todos os dados estão sendo criptografados.

Não consigo ver segurança no cenário proposto. O problema aqui é o
canal inseguro (Internet) que está sendo subvertido (DNS, SSL, url
spoofing). Se um dos pontos for subvertido (browser, servidor ou canal
de comunicação) é o fim da segurança.

sds

Myke

2009/2/20 Fernando Cima <fcima at microsoft.com>:
> Caro Nash,
>
> Desculpe, para mim ainda não está claro. Na sua idéia, como o cliente estaria recebendo e validando este applet?
>
> Abraços,
>
> - Fernando Cima
>
> -----Original Message-----
> From: owasp-brazilian-bounces at lists.owasp.org [mailto:owasp-brazilian-bounces at lists.owasp.org] On Behalf Of Nash Leon
> Sent: Friday, February 20, 2009 5:54 PM
> To: owasp-brazilian at lists.owasp.org
> Subject: Re: [Owasp-brazilian] retomando a discussao sobre comunicacoes inseguras
>
>
> Como vai, Thiago?
>
> Talvez eu nao tenha sido claro, novamente...:)
>
> Se esquecermos do SSL, esquecermos que ele existe e pensarmos apenas
> no HTTP. Que codigo eh mais seguro, aquele que implementa pki na
> aplicacao ou aquele que nao implementa?
>
> Obviamente que o uso de pki na aplicacao nao resolverah todos
> os problemas ocasionados por man-in-the-middle, no entanto, mitigaria
> esses problemas reportados de captura de dados sensiveis em modo limpo,
> jah que os dados enviados seriam criptografados no lado cliente(sem ssl).
>
> Se um applet bem trabalhado e assinado digitalmente for enviado
> para o cliente(navegador), acredito que exigiria bem mais de um
> atacante.
>
> Mesmo que o cliente(usuario) cai vitima de um ataque "generico" como
> esse, os dados seriam criptografados no lado cliente(navegador). E eu
> nao vejo como isso nao mitigaria um problema ocasionado pela
> infra ou falta dela.
>
> Essa ferramenta(sslstripe) deverah executar ataques genericos,
> entao uma recomendacao de mitigacao talvez seja o uso de algum recurso
> de criptografia no navegador.
>
> Quanto aos problemas culturais, foge da minha ossada discutir sobre isso.
> Nao acredito em educacao em massa sobre esses aspectos de seguranca,
> entao na minha visao a solucao de problemas de seguranca nao vai estar
> nas maos de usuarios, mas na de desenvolvedores. As melhorias na
> infra-estrutura de daemons e sistemas operacionais me leva a crer que
> essa abordagem de melhorar as praticas de programacao podem diminuir
> os problemas de seguranca.
>
> Um cordial abraco,
>
> NL.
>
>
> --- Em sex, 20/2/09, Thiago Zaninotti <thiago at zaninotti.net> escreveu:
>
>> De: Thiago Zaninotti <thiago at zaninotti.net>
>> Assunto: Re: [Owasp-brazilian] retomando a discussao sobre comunicacoes  inseguras
>> Para: nashleon at yahoo.com.br
>> Cc: owasp-brazilian at lists.owasp.org
>> Data: Sexta-feira, 20 de Fevereiro de 2009, 17:05
>> Oi Nash,
>>
>> Talvez você tenha se confundido sobre o tipo de ataque. O
>> problema não é
>> confiar a segurança nas mãos da "infraestrutura
>> SSL", mas simplesmente pelo
>> fato que a combinação de fatores simples e culturais no
>> dia-a-dia do usuário
>> de aplicações Web acabam por permitir que esta condição
>> prospere:
>>
>> - As pessoas acessam aplicações seguras (HTTPS) a partir
>> de links promovidos
>> por aplicações abertas (HTTP);
>> - Administradores de aplicações seguras (HTTPS)
>> geralmente também permitem
>> que uma transação seja invocada usando HTTP (mesma
>> aplicação "bindeada" em
>> portas 80 e 443);
>> - As pessoas são facilmente confundidas com símbolos
>> tradicionais do
>> e-commerce -- basta alterar seu o favicon do browser para
>> um cadeado para se
>> achar que está em SSL;
>> - As pessoas precisam de uma resposta negativa para achar
>> que existe um
>> problema com a comunicação segura do browser (e algumas
>> inclusive não dão a
>> mínima para a tela de "Warning").
>> - Quando a idéia é validar uma comunicação SSL, os
>> navegadores estão
>> geralmente satisfeitos em autenticar e garantir que existe
>> confiabilidade na
>> cadeia de assinatura dos certificados (pouco importa se a
>> "Geotrust" não é a
>> CA escolhida pelo Banco XPTO para garantir a integridade e
>> origem do DN/CN
>> www.bancoxpto.com.br).
>>
>> O uso do "PKI" de nada ajudaria nos casos acima
>> citados. Se falarmos em
>> verificação de "BasicConstraints" do lado da
>> implementação (e.g: OpenSSL),
>> provavelmente vamos cobrir uma pequena parte do problema
>> (ex:
>> $certificado->dn == $url->dn).
>>
>> Existe um outro problema que você não citou mas é o uso
>> de IDN para
>> confundir as pessoas. Eu posso usar caracteres unicode (se
>> vc for para a
>> Latvia vai saber o que estou falando) para compor meu
>> domínio e escolher
>> símbolos que parecem com letras do nosso alfabeto
>> ocidental (o 'a' por
>> exemplo). Apesar do problema estar corrigido com o advento
>> do "Punycode" (
>> http://en.wikipedia.org/wiki/Punycode) para domínios
>> .com/.net/.org/.us, os
>> browsers vão renderizar estes elementos em um top level
>> domain regional (no
>> caso do Marlin, ele pegou um .CN). Basta escolher
>> caracteres que pareçam com
>> "?/" e outros que comumente aparecem em
>> queries/URLs e o usuário é
>> facilmente enganado (veja o exemplo do gmail).
>>
>> Enfim, o problema é mais embaixo. Talvez as pessoas
>> precisem começar a se
>> preocupar com a forma de distribuir os links de forma
>> segura para suas
>> aplicações SSL. Mesmo quando você não tem um
>> virtualhost cujo acesso se faz
>> tanto em SSL quanto em HTTP, o problema dos ataques
>> homográficos continua.
>>
>> Resumindo: O usuário precisa deliberadamente acessar
>> https://minhaaplicacao.net/meulogon diretamente, sem passar
>> pelo lado
>> "claro" para obter um redirecionamento. (E Deus
>> queira que o seu DNS não
>> esteja envenenado -- veja a briga de DNSSEC do Kaminsky).
>>
>> Abraços,
>> --
>> Thiago Zaninotti,Security+,CISSP-ISSAP,CISM
>> Sr. InfoSec Professional
>>
>
>
>
>      Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com
> _______________________________________________
> 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
>


More information about the Owasp-brazilian mailing list