JPA Revelando a Senha do BD? Falha na segurança ou erro meu?

Seguinte, achei uma coisa agora que simplesmente inviabiliza o uso do JPA para produção.
Ao extrair o .jar gerado pelo netbeans e navegar pelas pastas extraidas chego ao persistance.xml e la dentro para minha surpresa esta os dados de conexão sem nenhuma dificuldade.

<properties>
      <property name="javax.persistence.jdbc.url" value="jdbc:mysql:/localhost:3306/tcc?zeroDateTimeBehavior=convertToNull"/>
      <property name="javax.persistence.jdbc.password" value="toor"/>
      <property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver"/>
      <property name="javax.persistence.jdbc.user" value="root"/>
    </properties>

Tá beleza, é meu tcc e teoricamente não há problemas, agora imagina um software para uma empresa onde qualquer funcionário com acesso ao .jar consegue os dados de acesso ao sistema?
Como corrigir?

Os famosos ByteCodes “escondem” meu código fonte, mas e xml da persistencia? Tem que ficar aberto mesmo?

As implementações de JPA nos application servers comerciais (WebSphere, Weblogic, etc.) normalmente deixam a senha em um outro arquivo, gerado na interface de administração Web, justamente por causa disso. Esse arquivo pode ser protegido com permissões de acesso mais restritas.

De qualquer maneira, normalmente você bota o servidor de banco de dados de produção em um lugar protegido por um firewall de modo que só a máquina que tem o servidor de aplicações, e mais as máquinas dos administradores de bancos de dados de produção, podem acessá-lo. Dessa forma, você não precisa se preocupar em senhas, já que você nem pode ver o servidor :slight_smile:

em aplicação corporativa o banco fica configurado no app server, com pool de conexoes. e vc só declara o jndi do pool no seu projeto

Tudo bem, entendi esse ponto.

Mas e em aplicações Desktop? JPA não é recomendado então para aplicações assim? Porque a senha está lá no XML pra quem quiser ver

No brasil, principalmente no interior, conexão estável com a internet ainda é um problema, e nem todas empresas querem investir em um bom servidor para rodar as aplicações. Ou seja, ainda utilizam o velho e bom aplicativos desktop;

De qualquer maneira, em uma aplicação Desktop, os arquivos não precisam ficar “abertos” - podem ficar dentro do jar mesmo . A senha do banco pode ficar em aberto ou não que não vai fazer diferença nenhuma, já que os dados não são criptografados no banco. Você pode, com alguma paciência, mexer em dados de qualquer banco, se tiver os arquivos do banco disponíveis, sem saber a senha :slight_smile:

Mas se eu tenho os dados de acesso ao bd por exemplo eu posso ir lá e “brincar” de inserts, updates e deletes, isso nas mãos de alguém mal intencionado é um perigo.

Deve haver um jeito de esconder esse XML, não consigo concordar que seja algo tao simples de pegar todos os dados de acesso ao BD.

Pois bem, é questão de você olhar a documentação da sua implementação específica de JPA.
Pode ser que já haja algum suporte a criptografar essa senha, ou deixá-la em outro arquivo que possa ficar no JAR.
Você não é o primeiro cara que reparou nessa tal “vulnerabilidade”.

Tem alguma forma então de (sem eu ter que reescrever o que já esta pronto) eu passar a carregar isto através da Web? Tipo algum servidor web apache que carregue o meu JAR dentro do navegador sem enviar o JAR diretamente para o cliente?

O Tomcat consegue fazer isto de alguma forma?

Aqui na empresa usamos um w2008 com Remote Desktop para gerar WebApps e Remote Apps dos .exe, tem como fazer isto com os .jar ?

Você pode criar um aplicativo Swing que acessa EJBs em um servidor de aplicação cuja senha do banco está apenas lá. O JBoss e o Weblogic, por exemplo, deixam você manter a senha criptografada na definição dos datasources.

O JPA não revela a senha do banco. Quem revela é a pessoa que toma péssimas decisões arquiteturais.

Entendi a alfinetada. hehe por isso desde o começo julguei poder ser erro meu. Entendi a lógica e vou tentar resolver.

Entendi a alfinetada. hehe por isso desde o começo julguei poder ser erro meu. Entendi a lógica e vou tentar resolver.[/quote]

Pior que nem foi alfinetada não…é que eu sou ragubento mesmo… :slight_smile:

Mas e então? Alguem ai sabe me dizer se tem algum Applet que execute JAR? Ou um servidor java (linux ou windows) que execute o jar e envie as respostas ao usuário sem ser jsp? Seria tipo um RemoteApp do Windows + Remote Desktop