Estou pesquisando esse problema a algum tempo e não encontrei uma solução plausível. Tenho uma aplicação java web rodando no servidor glassfish e em um determinado cliente preciso instalar a aplicação localmente devido ao acesso bando de dados, que esta integrado no servidor interno dele e não pode ser acessado de fora por N motivos.
O Problema é que instalando a aplicação localmente no servidor do cliente, corro o risco de minha aplicação ser acessada e descompilada, todos sabem se acessando o servidor de aplicação glassfish ou qualquer outro é possível acessar os arquivos do war e descompilar facilmente os .class e assim obter os fontes e todos os outros arquivos de configuração que já estão de mão beijada como .xml, .properties, etc. Pensei em algumas alternativas 1º, fazer a segurança por usuário, criar um usuário onde só eu ou uma pessoa especifica tenha acesso a pasta do servidor, mais isso é muito furado, sabemos que é fácil descobrir e modificar uma senha do linux, 2º alternativa ofuscar o código fonte, essa é a mais complicada, no meu sistema uso muita reflexão, annotations e classes genéricas e isso para quem já trabalhou com ofuscação de código é uma dor de cabeça, não tem como ofuscar, sem contar que os métodos usados nas views não podem ser trocados de nomes, e outros muitos problema que gera. 3º alternativa foi pesquisar muito sobre os servidores glassfish e jboss, se teria algum jeito de deixar não acessível os arquivo do projeto, mais não encontrei nada a respeito. Se alguem já passou por isso ou sabe de alguma solução e poder ajudar ficaria muito grato. Valeu!
Ei, faça como o amigo Hebert Coelho disse: respeite o forum; fazendo apenas perguntas obvias, do tipo: como converter tipos, como ligar o web server, como trocar uma lampada, esse tipo de pergunta vc deve fazer no stackoverflow por exemplo, ou outros forum de respeito q vá agregar conhecimento e não aborrecimento, esqueça esse forum.
Neste ponto, você deve consultar um advogado, não a gente. Isso é para fazer um bom contrato, em que você não seja prejudicado caso seja “roubado”.
Digamos que a aplicação fosse escrita não em Java mas sim em alguma linguagem que não seja muito fácil de descompilar ou de modificar, como é o caso do C++.
Se o cliente for mal-intencionado, não adianta você mudar a sua aplicação para não ser fácil de mudar.
Se o cliente for realmente mal-intencionado, é só questão de tempo (e de ele contratar alguém que saiba fazer isso, o que pode sair caro ou não) ele “crackear” sua aplicação e você ser “roubado” do mesmo jeito.
Você pode continuar a hospedar sua aplicação na máquina que você hospeda suas aplicações, e o banco de dados do cliente poderia ser acessado via VPN e ter um usuário específico só para sua aplicação. Então o cliente não precisa ter receio que o banco seja acessível via Internet (como estará protegido por uma VPN, só seu servidor irá acessar o banco) e se seu servidor de aplicações for hackeado, o cliente pode desativar esse usuário que é específico de sua aplicação.
É claro que o acesso via VPN é bem lento, portanto você tem de acertar sua aplicação de modo que ela minimize as consultas ao banco
Uma alternativa é você deixar, no cliente, apenas um monte de web services que acessam o banco, e deixar esses web services, disponíveis para sua aplicação Web que estará disponível no seu servidor. Isso ajuda a minimizar os acessos ao banco, e o cliente não consegue fazer nada útil com um web service se não tiver sua aplicação Web (que estará no seu servidor, não com ele).
Bacana as alternativas, o problema é que tenho que deixar lá mesmo a aplicação, exigência do cliente, e não posso usar nenhum meio de acessar o banco de fora, sem contar a lentidão e não posso usar meios de cache, porque tem outros sistemas de outras linguagens acessando o mesmo banco, iria ter problema de concorrência.
A ideia de criar o webservice e deixar no cliente é boa, o problema que não tenho muito tempo para fazer isso, o código DAO é bem complexo, prevendo que ira dar muitos problemas para fazer essa separação. Bem que o glassfish ou outro servidor poderia ter essa opção de proteger o fonte.
Cite algum sem ser de ofuscamento, como eu citei lá em cima os problemas que ocorrem ofuscando um projeto web. Pesquisei bem isso, não tem nenhum que relacione com os servidores.
Obfuscar uma aplicação web é realmente complicado.
Se for ver uma aplicação Web que roda em cliente (por exemplo, o Office Banking Bradesco Plus, que é uma versão customizada do Tomcat que é instalada com uma JVM 1.4) você vai ver que as páginas JSP originais não existem, somente os .class resultantes da compilação dos JSPs.
Mesmo assim todos os .jar estão abertos (já que os frameworks normalmente não funcionam se os .class estão obfuscados. Isso é porque eles usam muita reflection, e qualquer coisa que deva ser acessada pelo nome, via reflection, não vai funcionar com obfuscation. )
Como a funcionalidade principal desse sistema depende de transações do mainframe, na prática , nesse caso, não adianta ficar mexendo muito ou descompilar os fontes, a menos que alguém prepare uma versão maliciosa do OBB Plus.
Uma forma boba de você simular o caso “servidor próprio, rodando fora do cliente” é simplesmente montar uma máquina que vai ficar fisicamente no cliente, mas que ele não conheça nenhuma senha. Óbvio que se der algum problema nessa máquina, você vai ter de “ir voando” consertá-la
Para ele pegar alguma informação dessa máquina, terá de reinicializá-la com um pendrive contendo aquela distribuição do Linux “RIP” (Recovery is Possible), o que não é nada complicado, mas é sempre um obstáculo a mais.
vc pode contratar um advogado? foi isso que eu li? vou dar minha resposta eu não quero ver ninguem cornetando. Amigo, vc pode fazer uma oração, uma vez funcionou em um projeto. outra forma eficaz de proteger seu código é pedindo para as pessoas não olhar seu codigo, tem um cara que trabalha comigo que usa esse metodo, funciona certinho.
[quote=entanglement]Obfuscar uma aplicação web é realmente complicado.
Se for ver uma aplicação Web que roda em cliente (por exemplo, o Office Banking Bradesco Plus, que é uma versão customizada do Tomcat que é instalada com uma JVM 1.4) você vai ver que as páginas JSP originais não existem, somente os .class resultantes da compilação dos JSPs.
Mesmo assim todos os .jar estão abertos (já que os frameworks normalmente não funcionam se os .class estão obfuscados. Isso é porque eles usam muita reflection, e qualquer coisa que deva ser acessada pelo nome, via reflection, não vai funcionar com obfuscation. )
Como a funcionalidade principal desse sistema depende de transações do mainframe, na prática , nesse caso, não adianta ficar mexendo muito ou descompilar os fontes, a menos que alguém prepare uma versão maliciosa do OBB Plus.
[/quote]
Sim, ofuscadores é um pesadelo em um projeto web usando frameworks e reflection, inviável.
[quote=entanglement]Uma forma boba de você simular o caso “servidor próprio, rodando fora do cliente” é simplesmente montar uma máquina que vai ficar fisicamente no cliente, mas que ele não conheça nenhuma senha. Óbvio que se der algum problema nessa máquina, você vai ter de “ir voando” consertá-la
Para ele pegar alguma informação dessa máquina, terá de reinicializá-la com um pendrive contendo aquela distribuição do Linux “RIP” (Recovery is Possible), o que não é nada complicado, mas é sempre um obstáculo a mais.
[/quote]
Nessa ideia pensei em fechar uma maquina virtual criptografada e colocar no cliente… não sei se seria a melhor ideia, mais é possível.
