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.

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>

Se o descritor de implantação EJB contiver uma ou mais permissões de método que concedem acesso à função ANYONE, isso indica que o controle de acesso para o aplicativo não foi totalmente pensado ou que o aplicativo está estruturado de tal forma que as restrições de controle de acesso razoáveis são impossíveis.

Exemplo 1: O seguinte descritor de implantação concede a ANYONE permissão para invocar o método EJB do Employee, denominado getSalary().

<ejb-jar>
	...
	<assembly-descriptor>
		<method-permission>
			<role-name>ANYONE</role-name>
			<method>
				<ejb-name>Employee</ejb-name>
				<method-name>getSalary</method-name>
		</method-permission>
	</assembly-descriptor>
	...
</ejb-jar>

Os servidores da API Kubernetes aceitam solicitações anônimas por padrão se as solicitações não forem rejeitadas por outros métodos de autenticação configurados. Como um servidor de API é a entidade de gerenciamento central de um cluster, os invasores podem usar solicitações anônimas para obter acesso a APIs de serviço com proteção insuficiente e sensíveis à segurança.

Exemplo 1: A configuração a seguir inicia um servidor da API Kubernetes e permite solicitações anônimas definindo o sinalizador --anonymous-auth=true.

...
spec:
  containers:
    - command:
      - kube-apiserver
...
      - --anonymous-auth=true
...

Um servidor da API Kubernetes grava eventos de auditoria na saída padrão, como padrão. Os eventos de auditoria devem ser registrados no armazenamento persistente. Os eventos de auditoria contêm dados valiosos usados para identificar incidentes de segurança, monitorar violações de políticas e auxiliar nos controles de não repúdio.

Exemplo 1: A configuração a seguir inicia um servidor da API Kubernetes sem o sinalizador --audit-log-path.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=RBAC
  image: example.domain/kube-apiserver-amd64:v1.6.0
...

Um servidor da API Kubernetes, a entidade de gerenciamento central de um cluster, aceita a autenticação HTTP básica para autenticar usuários. A autenticação básica HTTP está obsoleta e suscetível a ataques de força bruta e vazamentos de credenciais de usuário para invasores em um ambiente mal configurado.

Exemplo 1: A configuração a seguir inicia um servidor da API Kubernetes e define o sinalizador --basic-auth-file=<filename>> para usar autenticação básica HTTP.

...
kind: Pod
...
spec:
  containers:
    - command:
      - kube-apiserver
      - --basic-auth-file=<filename>
    image: example.domain/kube-apiserver-amd64:v1.6.0
    livenessProbe:
...

Configurações de acesso livre podem expor sistemas e ampliar a superfície de ataque de uma organização. Os serviços abertos à interação com o público são normalmente submetidos a varreduras e investigações quase contínuas por entidades mal-intencionadas.

Isso é especialmente problemático quando uma exploração de dia zero para um serviço exposto é descoberta e publicada, como Heartbleed. Os invasores podem perseguir e pesquisar ativamente sistemas não corrigidos e expostos para explorá-los.

O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.

O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.

O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.