[Owasp-brazilian] retomando a discussao sobre comunicacoes inseguras

Fernando Cima fcima at microsoft.com
Fri Feb 20 16:27:01 EST 2009


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



More information about the Owasp-brazilian mailing list