Falando nisso, ótimo link.

Abs, Anderson Fraga

1 – Primeiro tenha um processo de desenvolvimento de software.

sua observação é valida, realmente estas vulnerabilidades existem. Mas eu mesmo assim ainda acredito que possa ser usado como quebra-galho, pois mesmo sem ter autenticação, podemos usar um token de sessão e mitigar significativamente o risco.

E vale ressaltar que um token de sessão é recomendado, necessário mesmo sem a utilização deste plugin.

Abs.

Os ataques MITM são os piores, mas o DoS também é trivial aqui. Vamos pegar o seu exemplo do envio de usuário e senha, onde a criptografia é feito a partir de uma página não autenticada. Um atacante pode rapidamente criar código Javascript no cliente para pedir que o seu servidor gere centenas de milhares de pares de chaves RSA, sem o menor custo de CPU para o atacante.

acho que deixei bem claro a frase que você citou: Ele não substitui o SSL, mas pode “quebrar o galho” em algumas requisições.

Uma situação onde você pode usar é: uma requisição onde você envia usuário e senha. Isto não irá afundar o processamento.

Vou escrever mais uma vez, se você não tem como implementar o SSL, você pode usar isto em requisições específicas. Jamais isto irá substituir o SSL, isto está bem claro na página do projeto e no post.

Já inicio o post com a seguinte frase: Muitas vezes necessitamos criptografar o tráfego de dados sensíveis em aplicação, a melhor opção para estes casos é usar SSL.

Abs.

“jCryption at it’s [sic] current state is no replacement for SSL, because there is no authentication”

Wagner, eu sinceramente não sei em que situação você usaria isto. Como não existe autenticação você está exposto a ataques MITM, e gerar um par de chaves RSA a cada requisição vai afundar o processamento do seu servidor (e ainda abrir um potencial canal para um DoS). Fuja!

Se você tem condição de implementar o SSL, sem dúvida é a melhor opção. Como eu deixei bem claro no texto, é um quebra galho. Em situações onde você mantém um “clear text” porque não tem como implementar um SSL, é uma alternativa.

Abs.

Eu não trocaria um padrão conhecido e seguro como o SSL por uma implementação de RSA “puro” como a desse plugin.

sem dúvida! Eu acho que deixei bem claro no texto.

“Ele não substitui o SSL, mas pode “quebrar o galho” em algumas requisições.”

hehehe

É um prazer interagir contigo novamente. Anteriormente, foi no espaço da Fac. Impacta prédio Santa Cruz – palestra sobre seguramça em moblidade.

Gostaria de saber se estará previsto na conferência sobre segurança em aplicações o ambiente móvel. Entendo que é muitos bancos possuem aplicações que rodam em dispositivos móveis e esses ainda não têm ou não possuem uma blindagem de segurança como as existentes em outros dispositivos.

Acredito ser ideal focar a segurança dessas aplicações na conferência.

Contudo, gostaria de saber quando teremos o conteúdo programático da conferência para que eu justifique melhor aos meus superiores minha presença no evento.

Por favor, me retorne.

Um grande abraço.

Agatângelo Pereira dos Santos
Ṣo Paulo РSP
11 8182-5016
E-mail: agatangelo@msn.com

Abraços,
Ranieri Marinho de Souza
Segurança da Informação

exatamente por isto eu escrevi este post. O programador tem que lidar com estas características via código, pois em geral o servidor não trata.

Quanto ao Tomcat, o Lucas dá boas dicas sobre o tratamento de Cookies:
http://java.sapao.net/Home/garantir-a-seguranca-dos-identificadores-de-sessao-cookies

Abs.

Como o próprio OWASP diz “…Most environments (e.g., Java EE) do not provide a mechanism to set the HTTPOnly flag. ”

O JSESSIONID é gerado pelo container, no caso o tomcat. Estou tentando saber como setar estes valores. alguma dica?

Obrigado,
Andre

Abraços.

Cassio Menezes.

eu recomendo uma pesquisa neste blog: http://thebpmexperience.wordpress.com/

Abs.

nós iniciamos um trabalho com a Virtual Testing, mas ainda necessita de alguns ajustes. Por favor, me mande um e-mail com a sua necessidade que eu lhe passo mais informações.

Abs.