Uma Intent interna usa uma ação personalizada conforme definido por um componente interno. Intenções implícitas podem facilitar a chamada de intenções de qualquer componente externo sem o conhecimento do componente específico. A combinação das duas permite que um aplicativo acesse intenções especificadas para um uso interno específico fora do contexto do aplicativo desejado.

A capacidade de processar uma Intent interna de um aplicativo externo pode permitir uma ampla variedade de explorações man-in-the-middle que variam em gravidade desde vazamento de informações e negação de serviço até execução remota de código, dependendo da capacidade de ação interna especificada pela Intent.

Exemplo 1: O código a seguir usa uma Intent interna implícita.

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Intents Android são usadas para vincular aplicativos e componentes de aplicativos, fornecendo instruções sobre ações que um determinado componente executa. As intenções pendentes são criadas para entregar a Intent posteriormente. As intenções implícitas facilitam a chamada de intenções de qualquer componente externo, usando um nome geral e um filtro para determinar a execução.

Quando uma Intent implícita é criada como uma PendingIntent, isso pode permitir que Intent seja enviada para um componente não intencional que é executado fora do contexto temporal pretendido, deixando o sistema vulnerável a explorar vetores como negação de serviço, vazamento de informações privadas e do sistema e escalonamento de privilégios.

Exemplo 1: O seguinte código usa uma PendingIntent implícita.

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...

Permitindo a modificação da Intent subjacente de uma PendingIntent após sua criação pode deixar um sistema aberto a ataques. Isso depende principalmente da capacidade geral da Intent subjacente. Na maioria dos casos, é uma prática recomendada evitar possíveis problemas definindo o sinalizador PendingIntent como FLAG_IMMUTABLE.

Exemplo 1: O seguinte inclui uma PendingIntent criada com um valor de sinalizador de FLAG_MUTABLE.

...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
    this,
    0,
    intent_flag_mut,
    flag_mut
)
...

Um problema de manipulação da intenção de redirecionamento ocorre quando as seguintes condições são atendidas:
1. Um componente exportado aceita um Intent arbitrário aninhado no pacote de extras de um Intent fornecido externamente.

2. O componente exportado usa o Intent arbitrário para iniciar um componente chamando startActivity, startService ou sendBroadcast.

Um invasor pode obter uma capacidade que, de outra forma, não seria permitida na existência dessas condições.
Exemplo 1: O código a seguir aceita um Intent aninhado de uma fonte externa e usa esse Intent para iniciar uma atividade.

...
Intent nextIntent = (Intent) getIntent().getParcelableExtra("next-intent");
startActivity(nextIntent);
...

O padrão J2EE requer que os aplicativos usem as instalações de gerenciamento de recursos do contêiner para obter conexões com recursos.

Por exemplo, um aplicativo J2EE deve obter uma conexão com o banco de dados da seguinte maneira:

ctx = new InitialContext();
datasource = (DataSource)ctx.lookup(DB_DATASRC_REF);
conn = datasource.getConnection();

e deve evitar obter uma conexão desta maneira:

conn = DriverManager.getConnection(CONNECT_STRING);

Cada principal contêiner de aplicativo Web fornece o gerenciamento de conexões com bancos de dados em pool como parte de sua estrutura de gerenciamento de recursos. Duplicar essa funcionalidade em um aplicativo é um processo difícil e propenso a erros, o que explica em parte sua proibição de acordo com o padrão J2EE.

Quanto mais tempo uma sessão permanecer aberta, maior será janela de oportunidade que um invasor terá para comprometer as contas dos usuários. Enquanto uma sessão permanece ativa, um invasor pode ser capaz de obter a senha de um usuário por força bruta, quebrar a chave de criptografia sem fio de um usuário ou comandar uma sessão a partir de um navegador aberto. Tempos limite de sessão mais longos também podem evitar a liberação da memória e eventualmente resultar em uma negação de serviço se um número suficientemente grande de sessões for criado.

Exemplo 1: O código no exemplo a seguir define um valor negativo para o intervalo inativo máximo, resultando em uma sessão que permanece ativa indefinidamente.

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...

Nunca é uma boa ideia um aplicativo Web tentar desligar o contêiner do aplicativo. Uma chamada para um método de encerramento é provavelmente parte de um código de depuração restante ou de um código importado de um aplicativo não J2EE.

Uma prática comum de desenvolvimento é adicionar código "back door" (porta dos fundos), projetado especificamente para fins de depuração ou teste, que não se destina a ser enviado ou implantado com o aplicativo. Quando esse tipo de código de depuração é acidentalmente deixado no aplicativo, o aplicativo fica aberto a modos não intencionais de interação. Esses pontos de entrada "back door" criam riscos de segurança, pois não são levados em consideração durante procedimentos de design ou teste e não se enquadram nas condições operacionais esperadas do aplicativo.

O exemplo mais comum de um código de depuração esquecido é um método main() que aparece em um aplicativo Web. Embora esta seja uma prática aceitável durante o desenvolvimento de produtos, as classes que fazem parte de um aplicativo J2EE de produção não devem definir um main().

Um aplicativo J2EE pode fazer uso de várias JVMs para melhorar o desempenho e a confiabilidade dos aplicativos. Para que as várias JVMs apareçam como um único aplicativo para o usuário final, o contêiner J2EE pode replicar um objeto HttpSession em várias JVMs de forma que, se uma JVM se tornar indisponível, outra poderá entrar e tomar o seu lugar sem interromper o fluxo do aplicativo.

Para que a replicação da sessão funcione, os valores que o aplicativo armazena como atributos na sessão devem implementar a interface Serializable.

Exemplo 1: A classe a seguir se adiciona à sessão, mas, como não é serializável, a sessão já não pode mais ser replicada.

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

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.)