O padrão J2EE permite o uso de soquetes apenas para fins de comunicação com sistemas legados, quando nenhum protocolo de nível superior está disponível. A criação do seu próprio protocolo de comunicação requer o combate a difíceis problemas de segurança, incluindo:

- Sinalização em banda versus fora de banda

- Compatibilidade entre versões de protocolo

- Segurança de canais

- Tratamento de erros

- Restrições de rede (firewalls)

- Gerenciamento de sessões

Sem o olhar examinador de um especialista em segurança, são boas as chances de que um protocolo de comunicação personalizado seja afetado por problemas de segurança.

Muitos dos mesmos problemas se aplicam a uma implementação personalizada de um protocolo padrão. Embora existam geralmente mais recursos disponíveis que abordam questões de segurança relacionadas à implementação de um protocolo padrão, esses recursos também estão disponíveis para os invasores.

O gerenciamento de threads em um aplicativo Web é proibido pelo padrão J2EE em algumas circunstâncias e é sempre muito propenso a erros. O gerenciamento de threads é difícil e pode interferir de maneiras imprevisíveis com o comportamento do contêiner do aplicativo. Mesmo sem interferir com o contêiner, o gerenciamento de threads geralmente provoca bugs que são difíceis de detectar e diagnosticar, como deadlocks, condições de corrida e outros erros de sincronização.

A maioria dos aplicativos da web usa um identificador de sessão para identificar exclusivamente os usuários, que normalmente é armazenado em um cookie e transmitido de forma transparente entre o servidor e o navegador da web.


Os aplicativos que não armazenam identificadores de sessão em cookies às vezes os transmitem como um parâmetro de solicitação HTTP ou como parte da URL. Aceitar identificadores de sessão especificados em URLs torna mais fácil para invasores realizar ataques de fixação de sessão.

Colocar identificadores de sessão em URLs também pode aumentar as chances de ataques de sequestro de sessão bem-sucedidos contra o aplicativo. O sequestro de sessão ocorre quando um invasor assume o controle da sessão ativa da vítima ou do identificador de sessão. É uma prática comum para servidores da web, servidores de aplicativos e proxies da web armazenar URLs solicitados. Se identificadores de sessão forem incluídos em URLs, eles também serão registrados. Aumentar o número de locais onde os identificadores de sessão são exibidos e armazenados aumenta as chances de serem comprometidos por um invasor.

Se você estiver usando o Tomcat para realizar a autenticação, o arquivo descritor de implantação do Tomcat especificará um "Realm" usado para autenticação. Parece o seguinte:

Exemplo 1:

  <Realm className="org.apache.catalina.realm.JAASRealm"
         appName="SRN"
         userClassNames="com.srn.security.UserPrincipal"
         roleClassNames="com.srn.security.RolePrincipal"/>

Essa tag Realm usa um atributo opcional denominado debug, que indica o nível de log. Quanto maior o número, mais detalhadas serão as mensagens de log. Se o nível de depuração estiver definido como muito alto, o Tomcat gravará todos os nomes de usuário e senhas em texto sem formatação no arquivo de log. O ponto limite para a depuração de mensagens relacionadas ao JAASRealm do Tomcat é 3 (3 ou acima é ruim, 2 ou abaixo é OK), mas esse limite pode variar para outros tipos de realms fornecidos pelo Tomcat.

Acessar diretamente as Java Server Pages (JSPs) em aplicativos construídos usando estruturas da web, como Struts ou Spring, que usam ações ou servlets para delegar solicitações a JSPs, pode resultar em exceções não tratadas e vazamentos de informações do sistema. Servidores de aplicativos mal implementados ou configurados foram cooptados para vazar detalhes do código-fonte usando solicitações especialmente criadas, como http://host/page.jsp%00 ou http://host/page.js%2570. Pior ainda, se um aplicativo permitir que os usuários carreguem arquivos arbitrários, os invasores podem usar esse mecanismo para fazer upload de código mal-intencionado na forma de um JSP e solicitar que a página carregada faça com que o código mal-intencionado seja executado no servidor.

Exemplo 1: O exemplo a seguir mostra uma restrição de segurança mal construída que permite explicitamente o acesso direto a JSPs com um '*' no nome da função, o que indica que todos os usuários têm permissão para acessar os recursos da web correspondentes.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>JSP Access for Everyone!</web-resource-name>
        <description>Allow any user/role access to JSP</description>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>*</role-name>
    </auth-constraint>
</security-constraint>

As funções de segurança duplicadas não têm nenhum propósito, pois apenas a última definição de uma determinada função de segurança será aplicada.
Exemplo 1: A entrada de um arquivo web.xml define duas funções admin.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>AdminPage</web-resource-name>
        <description>Admin only pages</description>
        <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>
...
<security-role>
    <description>Administrator</description>
    <role-name>admin</role-name>
</security-role>

<security-role>
    <description>Non-Administrator</description>
    <role-name>admin</role-name>
</security-role>

Os mapeamentos de servlet duplicados não têm nenhum propósito, pois apenas a última entrada será aplicada quando o mesmo padrão de URL for usado em vários mapeamentos de servlet.

Exemplo 1: No exemplo a seguir, o padrão do URL /servletA/* é usado em dois mapeamentos de servlet diferentes.

<servlet-mapping>
    <servlet-name>ServletA</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>ServletB</servlet-name>
    <url-pattern>/servletA/*</url-pattern>
</servlet-mapping>

Vários padrões de URL mapeados para um único Servlet podem ser um sinal de que o Servlet executa muitas funções.

Exemplo 1: O exemplo a seguir mapeia cinco padrões de URL para um único Servlet.

<servlet>
    <servlet-class>com.class.MyServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/myservlet</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/helloworld*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/servlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/mservlet*</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>MyServlet</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

Quanto mais tempo uma sessão fica aberta, maior a janela de oportunidade que um invasor tem para comprometer contas de usuário. Enquanto uma sessão permanece ativa, um invasor pode ser capaz de aplicar força bruta à senha de um usuário, quebrar a chave de criptografia sem fio de um usuário ou comandar uma sessão de um navegador aberto. Tempos limites de sessão mais longos também podem impedir que a memória seja liberada e, eventualmente, resultar em uma denial of service se um número suficientemente grande de sessões for criado.

Exemplo 1: Se o tempo limite da sessão for zero ou menor que zero, a sessão nunca expirará. O exemplo a seguir mostra um tempo limite de sessão definido como -1, que fará com que a sessão permaneça ativa indefinidamente.

<session-config>
    <session-timeout>-1</session-timeout>
</session-config>

A tag <session-timeout> define o intervalo de tempo limite da sessão padrão para todas as sessões no aplicativo da web. Se a tag <session-timeout> estiver ausente, cabe ao contêiner definir o tempo limite padrão.

Quando um invasor explora um site em busca de vulnerabilidades, a quantidade de informações que o site fornece é fundamental para o eventual sucesso ou falha de qualquer tentativa de ataque. Se o aplicativo mostrar ao invasor um rastreamento de pilha, ele cede informações que tornam o trabalho do invasor significativamente mais fácil. Por exemplo, um rastreamento de pilha pode mostrar ao invasor uma string de consulta SQL malformada, o tipo de banco de dados que está sendo usado e a versão do contêiner do aplicativo. Essas informações permitem que o invasor almeje vulnerabilidades conhecidas nesses componentes.

A configuração do aplicativo deve especificar uma página de erro padrão para garantir que o aplicativo nunca vaze mensagens de erro para um invasor. Tratar códigos de erro HTTP padrão é útil e intuitivo, além de ser uma boa prática de segurança, e uma boa configuração também definirá um manipulador de last-chance error que captura qualquer exceção que possa ser lançada pelo aplicativo.

Se um aplicativo usa SSL para garantir a comunicação confidencial com navegadores clientes, a configuração do aplicativo deve tornar impossível a exibição de qualquer página de acesso controlado sem SSL.

Existem três maneiras comuns de contornar o SSL:

- Um usuário insere manualmente o URL e digita "HTTP" em vez de "HTTPS".

- Os invasores enviam intencionalmente um usuário para um URL inseguro.

- Um programador cria erroneamente um link relativo para uma página no aplicativo, falhando ao mudar de HTTP para HTTPS. (Isso é particularmente fácil de fazer quando o link muda entre áreas públicas e seguras em um site.)

O descritor de implantação do WebLogic deve especificar um tamanho de identificador de sessão de pelo menos 24 bytes. Um identificador de sessão menor deixa o aplicativo aberto a ataques sessão de adivinhação de força bruta. Se um invasor conseguir adivinhar o identificador de sessão de um usuário autenticado, ele poderá assumir o controle da sessão do usuário. O restante desta explicação detalha uma justificativa no verso do envelope para um identificador de sessão de 24 bytes.

O identificador de sessão é formado por uma seleção pseudoaleatória dos 62 caracteres alfanuméricos, o que significa que, se a string fosse composta de uma forma realmente aleatória, cada byte poderia produzir um máximo de 6 bits de entropia.

O número esperado de segundos necessários para adivinhar um identificador de sessão válido é dado pela equação:

(2^B+1) / (2*A*S)

Onde:

- B é o número de bits de entropia no identificador de sessão.

- A é o número de suposições que um invasor pode tentar a cada segundo.

- S é o número de identificadores de sessão válidos que são válidos e estão disponíveis para serem adivinhados a qualquer momento.

O número de bits de entropia no identificador de sessão é sempre menor que o número total de bits no identificador de sessão. Por exemplo, se os identificadores de sessão foram fornecidos em ordem crescente, haveria quase zero bits de entropia no identificador de sessão, independentemente do comprimento do identificador. Pressupondo que os identificadores de sessão estão sendo gerados usando uma boa fonte de números aleatórios, estimaremos que o número de bits de entropia em um identificador de sessão seja a metade do número total de bits no identificador de sessão. Para tamanhos de identificador realistas, isso é possível, embora talvez otimista.

Se os invasores usarem um botnet com centenas ou milhares de computadores drones, é razoável supor que eles possam tentar dezenas de milhares de suposições por segundo. Se o site em questão for grande e popular, um alto volume de suposições pode passar despercebido por algum tempo.

Um limite inferior no número de identificadores de sessão válidos que estão disponíveis para serem adivinhados é o número de usuários ativos em um site a qualquer momento. No entanto, qualquer usuário que abandonar suas sessões sem fazer logout aumentará esse número. (Este é um dos muitos bons motivos para ter um tempo limite curto para sessão inativa.)

Com um identificador de sessão de 64 bits, assuma 32 bits de entropia. Para um grande site, suponha que o invasor possa tentar 1.000 suposições por segundo e que haja 10.000 identificadores de sessão válidos a qualquer momento. Dadas essas suposições, o tempo esperado para um invasor adivinhar com êxito um identificador de sessão válido é menos de 4 minutos.

Agora suponha um identificador de sessão de 128 bits que forneça 64 bits de entropia. Com um site muito grande, um invasor pode tentar 10.000 suposições por segundo com 100.000 identificadores de sessão válidos disponíveis para serem adivinhados. Dadas essas suposições, o tempo esperado para um invasor adivinhar com sucesso um identificador de sessão válido é maior que 292 anos.

Trabalhando retroativamente de bits para bytes, agora, o identificador de sessão deve ser 128/6, o que produz aproximadamente 21 bytes. Além disso, o teste empírico demonstrou que os primeiros três bytes do identificador de sessão não parecem ser gerados aleatoriamente, o que significa que, para atingir nossos 64 bits de entropia desejados, precisamos configurar o WebLogic para usar um identificador de sessão de 24 bytes de comprimento.

Um nome de servlet ausente ou duplicado em web.xml é um erro. Cada Servlet deve ter um nome único (servlet-name) e um mapeamento correspondente (servlet-mapping).

Exemplo 1: A seguinte entrada de web.xml mostra várias definições de servlet erradas.

<!-- No <servlet-name> specified: -->
    <servlet>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Empty <servlet-name> node: -->
    <servlet>
        <servlet-name/>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

<!-- Duplicate <servlet-name> nodes: -->
    <servlet>
        <servlet-name>MyServlet</servlet-name>
        <servlet-name>Servlet</servlet-name>
        <servlet-class>com.class.MyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

Esses erros podem causar uma negação não intencional de acesso ao Servlet.

O elemento <login-config> é usado para configurar como os usuários se autenticam em um aplicativo. A ausência de um método de autenticação significa que o aplicativo não sabe como aplicar restrições de autorização, pois ninguém pode fazer login. O método de autenticação é especificado usando a tag <auth-method> que é “child-of” de <login-config>.

Existem quatro métodos de autenticação: BASIC, FORM, DIGEST e CLIENT_CERT.

BASIC denota autenticação HTTP Basic.
FORM denota autenticação baseada em formulário.
DIGEST é como a autenticação BASIC; entretanto, em DIGEST a senha é criptografada.
CLIENT_CERT requer que os clientes tenham certificados de chave pública e usem SSL/TLS.

Exemplo 1: A configuração a seguir não especifica uma configuração de login.

<web-app>

    <!-- servlet declarations -->
    <servlet>...</servlet>

    <!-- servlet mappings-->
    <servlet-mapping>...</servlet-mapping>

    <!-- security-constraints-->
    <security-constraint>...</security-constraint>

    <!-- login-config goes here -->

    <!-- security-roles -->
    <security-role>...</security-role>

</web-app>

As restrições de segurança de web.xml são normalmente usadas para controle de acesso baseado em função, mas o elemento opcional user-data-constraint especifica uma garantia de transporte que evita que o conteúdo seja transmitido de maneira insegura.

Na tag <user-data-constraint>, a tag <transport-guarantee> define como a comunicação deve ser tratada. Existem três níveis de garantia de transporte:

1) NONE significa que o aplicativo não exige nenhuma garantia de transporte.
2) INTEGRAL significa que o aplicativo requer que os dados enviados entre o cliente e o servidor sejam enviados de forma que não possam ser alterados em trânsito.
3) CONFIDENTIAL significa que o aplicativo requer que os dados sejam transmitidos de uma maneira que evite que outras entidades observem o conteúdo da transmissão.



Na maioria das circunstâncias, o uso de INTEGRAL ou CONFIDENTIAL significa que é necessário SSL/TLS. Se as tags <user-data-constraint> e <transport-guarantee> são omitidas, o padrão de garantia de transporte é NONE.

Exemplo 1: A seguinte restrição de segurança não especifica uma garantia de transporte.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Storefront</web-resource-name>
        <description>Allow Customers and Employees access to online store front</description>
        <url-pattern>/store/shop/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Anyone</description>
        <role-name>anyone</role-name>
    </auth-constraint>
</security-constraint>

Quando um invasor explora um site em busca de vulnerabilidades, a quantidade de informações que o site fornece é fundamental para o eventual sucesso ou falha de qualquer tentativa de ataque. Se o aplicativo mostrar ao invasor um rastreamento de pilha, ele cede informações que tornam o trabalho do invasor significativamente mais fácil. Por exemplo, um rastreamento de pilha pode mostrar ao invasor uma string de consulta SQL malformada, o tipo de banco de dados que está sendo usado e a versão do contêiner do aplicativo. Essas informações permitem que o invasor almeje vulnerabilidades conhecidas nesses componentes.

A configuração do aplicativo deve especificar uma página de erro padrão para garantir que o aplicativo nunca vaze mensagens de erro para um invasor. Tratar códigos de erro HTTP padrão é útil e intuitivo, além de ser uma boa prática de segurança, e uma boa configuração também definirá um manipulador de last-chance error que captura qualquer exceção que possa ser lançada pelo aplicativo.

Cada mapeamento de filtro deve corresponder a uma definição de filtro válida para que seja aplicado.

Exemplo 1: O exemplo a seguir mostra um mapeamento de filtro que faz referência ao filtro inexistente AuthenticationFilter. Em razão da definição estar ausente, o filtro AuthenticationFilter não será aplicado ao padrão de URL designado /secure/* e pode causar uma exceção de tempo de execução.

<filter>
    <description>Compresses images to 64x64</description>
    <filter-name>ImageFilter</filter-name>
    <filter-class>com.ImageFilter</filter-class>
</filter>

<!-- AuthenticationFilter is not defined -->
<filter-mapping>
    <filter-name>AuthenticationFilter</filter-name>
    <url-pattern>/secure/*</url-pattern>
</filter-mapping>

<filter-mapping>
    <filter-name>ImageFilter</filter-name>
    <servlet-name>ImageServlet</servlet-name>
</filter-mapping>

Um security-role ausente para um role-name definido em um auth-constraint pode indicar uma configuração desatualizada.

Exemplo 1: O exemplo a seguir especifica um role-name, mas não o define em um security-role.

<security-constraint>
    <web-resource-collection>
         <web-resource-name>AdminPage</web-resource-name>
         <description>Admin only pages</description>
         <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>

    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>

    <user-data-constraint>
        <transport-guarantee>INTEGRAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

A ausência de um mapeamento de servlet válido impede todo o acesso ao servlet não mapeado.

Exemplo 1: A seguinte entrada de web.xml define ExampleServlet mas falha ao definir um mapeamento de servlet correspondente.

<web-app
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

    <servlet>
      <servlet-name>ExampleServlet</servlet-name>
      <servlet-class>com.class.ExampleServlet</servlet-class>
      <load-on-startup>1</load-on-startup>
    </servlet>

</web-app>

Os beans de entidade que expõem uma interface remota se tornam parte da superfície de ataque de um aplicativo. Em virtude do desempenho, um aplicativo raramente deve usar beans de entidade remotos, portanto, há uma boa chance de que uma declaração de bean de entidade remota seja um erro.

Exemplo 1: A seguinte declaração de bean de entidade inclui uma interface remota:

<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>EmployeeRecord</ejb-name>
<home>com.wombat.empl.EmployeeRecordHome</home>
<remote>com.wombat.empl.EmployeeRecord</remote>
...
</entity>
...
</enterprise-beans>
</ejb-jar>