>
> Ola Bruno,
>
> estou olhando a sua resposta para o Arthur na lista de discussao java e nao
> entendi como um usuario pode ter informacoes sobre a login/senha no codigo
> compilado da applet. E tambem sobre o usuario baixar um software de rede e
> monitorar as informacoes...... uma criptografia com chaves nao resolveria o
> problema? Bom, se minhas perguntas sao mediocres me perdoe pela ignorancia.
> E que eu nunca mexi com redes.
>
> Obrigado e um abraco,
>
> Guilherme Lloyd
>
Todas as linguagem sa "decompilaveis", inclusive (e especialmente)
Java. O maximo que voce pode fazer eh tornar as coisas um pouco
mais dificies, mas se voce tem apenas linhas do tipo:
String login = "username";
String senha = "senha123";
Voce nem precisa decompilar a aplicacao, basta uma rapida olhada
no binario, com qualquer "file viewer", para voce encontrar as
duas strings acima. Faca a experiencia.
Quanto a monitorar as informacoes, nao estou falando de alguem
monitorar as informacoes da sua maquina sem voce saber (isso pode
ser resolvido com criptografia), mas sim voce monitorar as
informacoes na sua propria maquina. Lembre-se, nesse caso (a
senha e o login sao os mesmos para todos), voce nao precisa
roubar a informacao de alguem, voce so precisa rouba-la
de voce mesmo.... Facil, nao?
Eh claro, voce pode fazer varias coisas para dificultar (Arthur,
aproveite essas dicas, que eu nao havia citado, ja que nao acho
que resolvam o problema, mas cabem nessa outra pergunta):
Voce pode criptografar o login/senha na sua aplicacao local, e
fazer com que a aplicacao descritografe no momento de usa-las.
Isso talvez obrigasse o "hacker" a entender a logica da sua
aplicacao, para poder pegar as informacoes, e ai sim ele precisaria
decompilar o seu codigo. Com um bom ofuscador de codigo, voce
tornaria dificil a compreensao do seu codigo, e dificultaria mais
um pouco o trabalho. Mas no fundo, se alguem quiser, ele vai
continuar capaz de entender o funcionamento da aplicacao e
capturar as informacoes.
No caso especifico da aplicacao do Arthur, ele nao tem controle do
applet da Oracle, e em algum momento, ele vai necessitar passar
essas informacoes para esse outro applet. Nesso momento, fica facil
capturar as informacoes. Se o Arthur fosse bem sofisticado, um
hacker de inteligencia mediana substituiria o applet da Oracle por
um applet proprio e receberia de bandeja os parametros. Mas nem
isso seria necessario. Qualquer um instalaria um analizador de
pacotes na propria maquina e esperaria que o applet que faz
o acesso a base de dados tentasse fazer a conexao, e tambem
receberia de graca os parametros de conexao do banco. Ah! voce
que enviar isso via SSL por exemplo? Tudo bem, eu instalo os
dois applets na minha maquina, copio o html, e faco o acesso
sem seguranca, na minha propria maquina. Ou seja, as possibilidade
sao muitas. E eu nem citei voce vasculhar a memoria do seu applet
esperando que a senha apareca em algum lugar.
Lembrem-se: podemos dificultar o trabalho, podemos impedir que
alguem interfira com as aplicacoes e informacoes de nosso usuario,
mas nao ha nada que se possa fazer se o nosso usuario quer roubar
suas proprias informacoes! O Applet esta RODANDO na maquina do
hacker, e as informacoes em questao sao UNICAS para todos os usuarios.
Basta o hacker "atacar" a si mesmo. Facil, facil. E depois, com
o login/senha, ele acessa a base de dados calmamente.
Moral da historia: seguranca eh um assunto complexo. Nao adianta
tentar ser mirabolante quando a arquitetura esta furada, ou como
diz o jargao: "Nao adianta colocar portas de ferro em cabanas de
palha". Nesse caso, o erro eh o applet fazer o acesso aa base de dados
diretamente. Por isso na minha primeira resposta, a minha proposta
foi a de se fazer uma arquitetura mais segura (e, de lambuja, melhor
a longo prazo.)
Abracos,
Bruno.
______________________________________________________________________
Bruno Peres Ferreira de Souza Sun Microsystems
System Engineer - Java Technologist [EMAIL PROTECTED]
if I fail, if I succeed, at least I live as I believe
* Para nao receber mais e-mails da lista, acesse
<http://www.sun.com.br:8080/guest/RemoteAvailableLists>, coloque seu e-mail, escolha a
lista <[EMAIL PROTECTED]> e de um <submit>.
