[Owasp-brazilian] A9 – Comunicações Inseguras

Fernando Cima fcima at microsoft.com
Thu Jan 22 09:58:20 EST 2009


Eu vejo dois problemas aqui:

- O primeiro é que a segurança da aplicação sempre vai depender da segurança da infra sob ela. Se o sistema operacional p.ex. foi comprometido, game over. Se o servidor Web ou no cliente o browser forem comprometidos, também game over. Infelizmente não dá para revogar isso.

- O segundo é que desenvolver a sua própria criptografia é invariavelmente uma má idéia e por si só estar dentro dos Top Ten. Desenvolver código criptográfico não é simples e invariavelmente a equipe de desenvolvimento não vai saber fazer isto direito. Melhor usar o que a infraestrutura oferece.

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: Thursday, January 22, 2009 6:12 AM
To: owasp-brazilian at lists.owasp.org
Subject: [Owasp-brazilian] A9 – Comunicações Inseguras

Como vai, pessoal?

Temos usado o top 10 da owasp como recomendação para os desenvolvedores
e treinamento que damos, no entanto um item em especial me tem intrigado
já há algum tempo.

Pelo que sei, o objetivo da owasp e do top 10 em especial é conscientizar
quanto a práticas seguras de desenvolvimento, mas este item citado no
subject joga toda a responsabilidade de segurança para a "infra-estrutura" e não para a aplicação, como deveria ser.

Do top 10 em português temos:

"A parte mais importante da proteção é usar o SSL em todas as conexões autenticadas ou em qualquer
informação sensível em transmissão...."

Isso não deveria ser a parte mais importante, pois qualquer fraqueza
na "infra-estrutura" iria expor a aplicação. Como exemplo cito os
problemas de certificados que não raro são mal gerados e fracos o
bastante para serem comprometidos.

Uma sugestão melhor seria a aplicação 'criptografar' os dados, pelo
menos os dados críticos usando PKI. Como se trata de aplicações WEB, isso
pode ser facilmente implementado usando JavaScript(sim, do lado cliente), num custo operacional que deve ser analisado(chaves de 2048 bits em javascript pode travar qualquer navegador).

SSL deveria ser visto como algo a parte, como uma camada secundária
de segurança e não como a principal.

Mesmo sabendo que existem formas de se quebrar uma implementação de criptografia a nível de navegador(o mesmo se aplica ao uso de SSL nos navegadores), acredito que essa ainda seria uma melhor sugestão de solução, cabendo o ônus ao desenvolvedor da aplicação e não a infra-estrutura WEB.

Nos treinamentos que damos, nós dizemos que isso é uma deficência da
OWASP e que uma coisa é aplicação e segurança da aplicação e outra bem
diferente é infra-estrutura e consequentemente segurança de infra. E que
"uma aplicação pra ser segura não deve depender da segurança de infra".

O que os senhores pensam a respeito disso?

Um cordial abraço,

Nash Leon.


      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