Atributos de manifesto de arquivo JAR para segurança O manifesto de arquivo JAR contém informações sobre o conteúdo do arquivo JAR, incluindo informações de segurança e configuração. Use os atributos de manifesto descritos nesta seção para melhorar a segurança de executar RIAs de um navegador. Adicione os atributos ao manifesto antes que o arquivo JAR seja assinado. Consulte Modificando um Arquivo Manifesto no Tutorial Java para obter informações sobre como adicionar atributos ao arquivo de manifesto JAR. Nota: Estes atributos aplicam-se a applets assinadas e aplicativos Java Web Start. Esses atributos são ignorados para aplicativos Java autônomos. Atributo de permissões O atributo Permissões é usado para verificar se o nível de permissões solicitado pelo RIA quando ele é executado corresponde ao nível de permissões que foi configurado quando o arquivo JAR foi criado. Use este atributo para ajudar a impedir que alguém re-implantação de um aplicativo que esteja assinado com seu certificado e executá-lo em um nível de privilégio diferente. Defina este atributo para um dos seguintes valores: sandbox - Indica que o RIA é executado no sandbox de segurança e não requer permissões adicionais. Todas as permissões - Indica que o RIA requer acesso aos recursos do sistema dos usuários. Para aplicativos e applets Java Web Start que usam o JNLP, o valor do atributo Permissões deve corresponder ao nível de permissão solicitado no arquivo JNLP ou combinar a permissão padrão se nenhum nível de permissão for solicitado. Caso contrário, é mostrado um erro eo RIA está bloqueado. Consulte Estrutura do Arquivo JNLP para obter informações sobre o elemento de segurança que é usado para solicitar o nível de permissões. Se o elemento não estiver presente, o nível de permissões é padrão para o sandbox. Para applets que não usam JNLP, o valor do atributo Permissões deve corresponder ao nível de permissões solicitado na etiqueta do applet. Caso contrário, é mostrado um erro eo RIA está bloqueado. Se a etiqueta do applet não contiver um nível de permissões, as applets assinadas são executadas com o nível de permissões definido pelo atributo Permissões. Consulte Implantando com o Tag do Applet para obter informações sobre como configurar o nível de permissões na etiqueta do applet. Se o controle deslizante Nível de Segurança no Painel de Controle Java estiver definido como Muito Alto ou Alto. O atributo Permissões é requerido no arquivo JAR principal para o RIA. Se o atributo não estiver presente, o RIA está bloqueado. Para o nível de segurança Médio, se o atributo Permissões não estiver presente, o prompt de segurança contém um aviso amarelo sobre o atributo ausente e o nível de permissão solicitado pelo RIA é usado. Atributo Codebase O atributo Codebase é usado para restringir a base de código do arquivo JAR a domínios específicos. Use esse atributo para evitar que alguém re-implanta seu aplicativo em outro site para fins maliciosos. Observação: se o atributo Codebase não especificar um servidor seguro, como HTTPS. Existe algum risco de que seu código possa ser reutilizado em esquemas de ataque de Man-in-the-Middle (MITM). Defina esse atributo para o nome de domínio ou o endereço IP onde o arquivo JAR para o aplicativo está localizado. O protocolo e o número da porta também podem ser incluídos. Para vários locais, separe os valores com um espaço. Um asterisco () pode ser usado como um curinga apenas no início do nome de domínio e não pode ser usado apenas com um domínio de nível superior, como. A tabela a seguir mostra valores de amostra e o que eles combinam. O valor do atributo Codebase deve corresponder à localização do arquivo JAR para o RIA. Caso contrário, é mostrado um erro eo RIA está bloqueado. Se o atributo não estiver presente, um aviso será gravado no Console de Java e a base de código especificada para a marca do applet ou o arquivo JNLP será usado. Atributo de nome de aplicativo O atributo de nome de aplicativo é usado em prompts de segurança para fornecer um título para o RIA assinado. O uso deste atributo é recomendado para ajudar os usuários a tomar a decisão de confiar e executar o RIA. O valor pode ser qualquer string válida, por exemplo: se o atributo Application-Name não estiver presente no manifesto do arquivo JAR, um aviso será gravado no Console Java e o valor para o atributo Main-Class será usado. Se nenhum dos atributos estiver presente no manifesto, nenhum título será exibido nas instruções de segurança. Os títulos não são mostrados para RIAs não assinados. Atributo Application-Library-Allowable-Codebase O atributo Application-Library-Allowable-Codebase identifica os locais onde o RIA assinado deverá ser encontrado. Este atributo é usado para determinar o que está listado no campo Local para o prompt de segurança que é mostrado aos usuários quando o arquivo JAR para o seu RIA está em uma localização diferente do arquivo JNLP ou página HTML que inicia seu RIA. Se os arquivos não estiverem nos locais identificados, o RIA está bloqueado. Defina esse atributo para os domínios onde o arquivo JAR, o arquivo JNLP e a página HTML estão localizados. Para especificar mais de um domínio, separe os domínios por um espaço, por exemplo: se o atributo Application-Library-Allowable-Codebase estiver presente e corresponder ao local a partir do qual o RIA for iniciado, um único host está listado no campo Local Para o prompt e a opção de ocultar prompts futuros é fornecida. Se este atributo estiver presente e os arquivos forem acessados a partir de um local não incluído no atributo, o RIA será bloqueado. Se esse atributo não estiver presente, vários hosts que correspondem às localizações do arquivo JAR e do arquivo JNLP ou página HTML estão listados no campo Localização para o prompt. Quando vários hosts são mostrados, o usuário não tem a opção de ocultar prompts futuros. O uso deste atributo é recomendado para que os arquivos para o RIA sejam acessados apenas em locais conhecidos. Este atributo não é necessário se o arquivo JAR para o RIA estiver no mesmo local que o arquivo JNLP ou a página HTML que inicia o RIA. Consulte Atributo da Base de Dados para uma descrição dos valores que são permitidos. Atributo Callable-Allowable-Codebase O atributo Callable-Allowable-Codebase é usado para identificar os domínios a partir dos quais o código JavaScript pode fazer chamadas para o RIA sem instruções de segurança. Defina este atributo para o domínio que hospeda o código JavaScript. Se uma chamada é feita a partir de código JavaScript que não está localizado em um domínio especificado pelo atributo Caller-Allowable-Codebase, a chamada é bloqueada. Para especificar mais de um domínio, separe os domínios por um espaço, por exemplo: se o atributo Callable-Allowable-Codebase não estiver presente, as chamadas do código JavaScript para o RIA mostram um aviso de segurança e os usuários podem optar por permitir a chamada Ou bloquear a chamada. Para RIAs não assinados, o código JavaScript que requer acesso ao RIA deve estar no mesmo local que o arquivo JAR principal para o RIA, caso contrário, o usuário será solicitado a permitir o acesso. Os prompts de segurança são mostrados para cada instância ClassLoader do Applet. Consulte Atributo da Base de Dados para uma descrição dos valores que são permitidos. Se um asterisco autônomo () for especificado como o valor do atributo Callable-Allowable-Codebase, as chamadas do código JavaScript para o RIA mostram um aviso de segurança, e os usuários podem escolher a chamada ou bloquear a chamada. Uma opção para lembrar a escolha também é fornecida e, se selecionada, o aviso não é exibido quando o RIA é iniciado. Atributo de ponto de entrada O atributo de ponto de entrada é usado para identificar as classes que podem ser usadas como pontos de entrada para o seu RIA. Identificar os pontos de entrada ajuda a evitar que o código não autorizado seja executado quando um arquivo JAR possui mais de uma classe com um método main (), várias classes Applet ou várias classes JavaFX Application. Defina este atributo para o nome de classe totalmente qualificado que pode ser usado como ponto de entrada para o RIA. Para especificar mais de uma classe, separe as classes por um espaço, por exemplo: Entry-Point: apps. test. TestUI apps. test. TestCLI Se o manifesto JAR estiver assinado e o ponto de entrada da classe principal ou do applet especificado em O arquivo JNLP ou o descritor da aplicação difere da classe especificada para o atributo Entry-Point, então o RIA está bloqueado. Se o atributo Entry-Point não estiver presente, qualquer classe com um método main () ou qualquer Applet ou JavaFX Application class no arquivo JAR pode ser usada para iniciar seu RIA. O atributo Trusted-Only é usado para impedir que classes ou recursos não confiáveis sejam carregados para um applet ou aplicativo. Defina o valor do atributo como verdadeiro. Por exemplo: Este atributo impede que um aplicativo ou applet privilegiado seja reutilizado com componentes não confiáveis. Todas as classes e recursos no aplicativo ou no applet devem ser assinados e solicitar todas as permissões. O atributo Trusted-Library é usado para aplicativos e applets projetados para permitir componentes não confiáveis. Nenhuma caixa de diálogo de aviso é mostrada e um aplicativo ou applet pode carregar arquivos JAR que contenham classes ou recursos não confiáveis. Defina o valor do atributo como verdadeiro. Por exemplo: Este atributo evita que os componentes de uma aplicação ou applet privilegiada sejam reutilizados com componentes não confiáveis. Todas as classes e recursos em um arquivo JAR contendo esse atributo de manifesto devem ser assinados e solicitar todas as permissões. Em um aplicativo ou applet de código misto, todas as classes e recursos privilegiados devem ser incluídos em arquivos JAR que contenham o atributo Trusted-Library. Este atributo é usado para chamadas entre o código Java privilegiado Java code sandbox. Se você tiver o código JavaScript que chama o código Java, consulte Atributo do Callable-Allowable-Codebase. Todos os JAR de biblioteca confiáveis são carregados em um carregador de classe dedicado separado que é exclusivo da instância do aplicativo ou do applet. Este carregador Trusted-Library agora é o pai do carregador normal da Web Start ou do applet. Para compatibilidade com a ordem de busca original, ambos os carregadores cooperam para implementar um caminho de classe comum. Em consonância com as versões anteriores, os arquivos JAR usam downloads preguiçosos e são abertos conforme necessário para encontrar as classes e recursos solicitados. O código em um arquivo JAR que deve ser marcado com o atributo do manifesto Trusted-Library talvez precise ser modificado um pouco se ele usar chamadas que dependem do carregador de classe, como a versão de parâmetro único de Class. forName (). Class. getResource (). E Class. getResourceAsStream (). Algumas variantes de java. util. ResourceBundle. getBundle (). E quaisquer outros métodos que operam em relação aos contadores imediatos que definem o carregador. As mudanças só precisam ser feitas se a classe ou o recurso solicitado puderem ser encontrados em um arquivo JAR que não seja uma Biblioteca Confiável (e, portanto, é carregado pelo carregador da classe normal do Web Start ou do applet). O código em uma Trusted-Library pode procurar o carregador normal invocando Thread. currentThread (). GetContextClassLoader (). Note, no entanto, que existem circunstâncias incomuns em que getContextClassLoader () pode retornar nulo. Por exemplo, isso pode acontecer quando o coletor de lixo usa uma thread do sistema JRE para invocar o método Object. finalize () de uma instância inacessível. Se você precisa converter a classe para Class. getResource () ou Class. getResourceAsStream () para seus equivalentes ClassLoader, lembre-se de ajustar o parâmetro string conforme descrito na documentação desses dois métodos. Se o nome do recurso original começou. Então era um nome absoluto e o líder simplesmente precisa ser removido. Caso contrário, determine se a instância da classe que foi o alvo da chamada getResource está em um pacote nomeado. Se for uma matriz, primeiro você deve determinar o tipo de componente subjacente da matriz. Invoque Class. getName () na instância do tipo classe ou componente. Se o nome da classe contiver qualquer. Caracteres, está em um pacote nomeado que precisará ser precedido do nome do recurso original. Determine o nome do pacote removendo alguns caracteres depois, e inclusive, o fim. personagem. Em seguida, substitua qualquer restante. Personagens com personagens. Finalmente, adicione uma sequência e anexe a string do nome do recurso original. Essa nova string agora pode ser passada para a versão ClassLoader dos métodos getResource () ou getResourceAsStream (). Geralmente, deve-se ter cuidado para garantir que o código na biblioteca confiável seja escrito de forma cuidadosa e segura e, de outra forma, é compatível com a carga em uma instância de carregador de classes separada de quaisquer frascos restantes que fazem parte do aplicativo e sejam carregados por O carregador normal. Informações adicionais Consulte Mixing Privileged Code e Sandbox Code para obter informações sobre o uso de atributos de manifesto para gerenciar chamadas de código não confiável. Consulte Impedir que os RIAs sejam repurposados para obter informações sobre o uso de atributos de manifesto para garantir que o nível de permissão correto ea base de código sejam usados. Para obter informações sobre como adicionar atributos ao arquivo de manifesto JAR, consulte Modificando um arquivo manifesto no tutorial Java. (1) Primeiro, você precisa criar um arquivo de texto com todos os atributos que deseja adicionar. Meu arquivo de texto parece assim: eu o nomeei addToManifest. txt. Obviamente, você precisará alterar os parâmetros para corresponder às suas necessidades de aplicativos. (2) Em seguida, você precisa adicionar isso ao principal. jar e todas as bibliotecas também. O comando para fazer isso é: claro distmyApp. jar precisará apontar para qualquer que seja o seu principal. jar. Você também precisa fazer isso para todas as bibliotecas também. (Nota: no Windows, eu escrevi um arquivo. bat para isso.) Depois de fazer isso, os atributos devem ser gravados no. jar s. Você pode abrir o. jars em um gerenciador de zip (como 7-Zip), extrair o arquivo MANIFEST. MF, abri-lo em um editor de texto e você deve ver os atributos listados. (3) Depois de adicionar os atributos, você precisa renunciar ao seu aplicativo. O comando para fazer isso é: Você também precisa fazer isso para todas as suas bibliotecas também: depois disso, seus atributos devem ser adicionados e o seu. jar s deve ser assinado. NOTA: Você só precisa fazer login para fazer suas bibliotecas uma vez, a menos que você seja Mudando a estrutura da biblioteca. Ou seja, se você estiver atualizando seu aplicativo, mas as bibliotecas já tiveram seus manifestos alterados, assinados corretamente e implantados, você não precisará renunciar a implantar as bibliotecas, a menos que você esteja adicionando bibliotecas de remoção de seu aplicativo. NOTA 2: A versão atual do Netbeans adicionará os atributos de manifesto do Codebase e Permissões somente ao seu. jar principal. Mas não às suas bibliotecas. Se você usar Netbeans, você receberá um aviso do utilitário jar quando você tentar adicionar um atributo de manifesto duplicado. Há um relatório de erro na fila para ter esta fixada netbeans. orgbugzillashowbug. cgiid234231. EDITAR: A versão mais recente do Netbeans (8.0) agora adiciona os três (Codebase. Permissões e Nome do aplicativo) ao manifesto para você. Respondeu 29 de outubro às 13:08 2estalavista, entendido. Somente o problema é que a mensagem Missing Application-Name é um aviso que só aparece no console, não um erro que será manifestado ao usuário, a menos que eles sejam inteligentes o suficiente para exibir o console. Além disso: devemos ser indignos em sugerir um trabalho para que o usuário final possa se livrar de um aviso de segurança apenas porque o consideram um incômodo, mesmo que sejam impotentes para corrigir o problema de forma definitiva. Não sei o que a Oracle esperava com esse aviso, mas existe por algum motivo. Ndash ryvantage 9 de maio 14 em 4:38 Se você usar Netbeans, defina esses atributos em seu arquivo nbprojectproject. properties: manifesto. custom. codebase manifest. custom. permissions manifest. application. name. attribute O último é suportado apenas por Netbeans 8.0 (veja aqui). Os outros deveriam funcionar mesmo no Netbeans 7.2. Eu configurei jnlp. mixed. code confiável também, mas talvez não seja apropriado no seu caso. Você pode modificar seu arquivo jnlp-impl. xml por sua própria conta e risco se você não puder mudar para uma versão mais recente do Netbeans. A sugestão de atóis é melhor se você não usa Netbeans.
No comments:
Post a Comment