Infelizmente implementar SSL em todos os ambientes nem sempre é responsabilidade do desenvolvedor, geralmente ele depende de uma área responsável por infraestrutura. Quando não existe um bom relacionamento entre as áreas e/ou um estudo de requisitos antes de colocar uma aplicação em produção, a aplicação acaba indo para produção sem o SSL e consequentemente exposta as vulnerabilidades pertinentes a data tampering.
Uma alternativa para desenvolvedores é um plugin chamado JCryption para o framework javascript JQuery. O plugin possibilita que seja criptografado as requisições POST e GET. Ele não substitui o SSL, mas pode "quebrar o galho" em algumas requisições.
A implementação é simples, basta seguir os exemplos da página do plugin.
9 comentários:
Wagner, eu colocaria um * bem grande nesse "alternativa"... não dá pra comparar uma criptografia SSL com javascript, nem de longe! hehe
Chris,
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
[...] ao SSL em jQuery http://wagnerelias.com/2009/08/28/uma-alternativa-ao-ssl/ a few seconds ago from [...]
Esse plugin usa uma implementação meio "simplória" do RSA. Eu tenho bastante receio desse tipo de implementação e dos ataques possíveis.
Eu não trocaria um padrão conhecido e seguro como o SSL por uma implementação de RSA "puro" como a desse plugin.
Fala Lucas!
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.
Da página do projeto:
"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!
Oi Cima,
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.
Wagner, o meu ponto é diferente. Isto não é alternativa para SSL. Encriptação de canal sem autenticação do destinatário não serve nem para quebrar galho.
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.
Oi Cima,
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.
Postar um comentário