As operações da API definem os requisitos de segurança para informar os consumidores da API sobre os parâmetros de autenticação e autorização necessários para invocá-los com sucesso.

As operações que tornam a segurança opcional podem permitir que invasores interajam com endpoints de API confidenciais e executem ações que devem ser restritas a contas de usuário específicas com privilégios explícitos.

Exemplo 1: A especificação do OpenAPI a seguir torna a segurança opcional incluindo um objeto vazio {} na definição security para uma operação confidencial. Isso substitui os requisitos de segurança definidos globalmente e torna a operação createUsers vulnerável a acesso não autorizado e não autenticado.

{
    "openapi": "3.0.0",
    "info": {
     ...
    },    
    "paths": {
      "/users": {
        "post": {
           "security": [
            {},
            {
              "my_auth": [
                "write:users"
              ]
            }
          ],
          "summary": "Create a user",
          "operationId": "createUsers",
         ...
        }
    ...
    }
}

Métodos de autenticação inseguros podem permitir que invasores obtenham privilégios administrativos e orquestrem um comprometimento completo do sistema.

Nunca é apropriado usar uma string vazia como senha. É muito fácil adivinhar.

Armazenar uma senha de texto simples em um arquivo de configuração permite a qualquer pessoa que possa ler o arquivo, acesso ao recurso protegido por senha. Os desenvolvedores às vezes acreditam que não podem defender o aplicativo de alguém que tenha acesso à configuração, mas essa atitude torna o trabalho do invasor mais fácil. Boas diretrizes de gerenciamento de senha exigem que uma senha nunca seja armazenada em texto simples.

Quando habilitada, a opção allow_url_fopen permite que funções PHP que aceitam um nome de arquivo operem em arquivos remotos usando uma URL HTTP ou FTP. A opção, que foi introduzida no PHP 4.0.4 e está habilitada por padrão, é perigosa porque pode permitir que os invasores introduzam conteúdo mal-intencionado em um aplicativo. Na melhor das hipóteses, operar em arquivos remotos deixa o aplicativo suscetível a invasores que alteram o arquivo remoto para incluir conteúdo mal-intencionado. Na pior das hipóteses, se os invasores puderem controlar uma URL na qual o aplicativo opera, eles poderão injetar conteúdo mal-intencionado arbitrário no aplicativo fornecendo uma URL para um servidor remoto.

Exemplo 1: O código a seguir abre um arquivo cujo nome é controlado por um parâmetro de solicitação e lê seu conteúdo. Como o valor de $file é controlado por um parâmetro de solicitação, um invasor pode violar as premissas do programador fornecendo uma URL para um arquivo remoto.

<?php
$file = fopen ($_GET["file"], "r");
if (!$file) {
    // handle errors
}
while (!feof ($file)) {
    $line = fgets ($file, 1024);
    // operate on file content
}
fclose($file);
?>

Quando habilitada, a opção allow_url_include permite que funções PHP que especificam um arquivo para inclusão na página atual, como include() e require(), aceitem uma URL HTTP ou FTP para um arquivo remoto. A opção, que foi introduzida no PHP 5.2.0 e está desabilitada por padrão, é perigosa porque pode permitir que os invasores introduzam conteúdo mal-intencionado em um aplicativo. Na melhor das hipóteses, incluir arquivos remotos deixa o aplicativo suscetível a invasores que alteram o arquivo remoto para incluir conteúdo mal-intencionado. Na pior das hipóteses, se os invasores puderem controlar uma URL que o aplicativo utiliza para especificar o arquivo remoto a ser incluído, eles poderão injetar conteúdo mal-intencionado arbitrário nesse aplicativo fornecendo uma URL para um servidor remoto.

Se o interpretador PHP for instalado como um binário CGI, as solicitações de recursos PHP serão tipicamente redirecionadas pelo servidor Web para esse interpretador. Nessa situação, quando um usuário solicita http://www.example.com/content/page.php, o servidor realiza primeiro as verificações de controle de acesso necessárias no diretório /content e depois redireciona o controle ao interpretador PHP com uma solicitação para http://www.example.com/cgi-bin/php/content/page.php.

Se cgi.force_redirect, que está habilitado por padrão, estiver desabilitado, os invasores com acesso a /cgi-bin/php poderão usar as permissões do interpretador PHP para acessar documentos da Web arbitrários, ignorando assim qualquer verificação de controle de acesso que teria sido realizada pelo servidor.

A configuração enable_dl permite o carregamento dinâmico de bibliotecas. Isso poderia permitir que um invasor contornasse as restrições definidas com a configuração open_basedir e, possivelmente, permitir o acesso a qualquer arquivo no sistema.

Ativar enable_dl pode tornar mais fácil para os invasores explorarem outras vulnerabilidades.

Quando habilitada, a opção file_uploads permite que os usuários do PHP carreguem arquivos arbitrários no servidor. Permitir que os usuários carreguem arquivos não representa uma vulnerabilidade de segurança por si só. No entanto, essa capacidade pode possibilitar uma variedade ataques, pois dá aos usuários mal-intencionados um meio de introduzir dados no ambiente do servidor.

Independentemente da linguagem na qual um programa está escrito, os ataques mais devastadores muitas vezes envolvem a execução de código remoto, por meio da qual um invasor consegue executar código mal-intencionado com sucesso no contexto do programa. Se os invasores puderem carregar arquivos em um diretório acessível na Web e fazer com que esses arquivos sejam transmitidos ao interpretador PHP, eles poderão fazer com que o código mal-intencionado contido nesses arquivos sejam executados no servidor.

Exemplo 1: O código a seguir processa arquivos carregados e os move para um diretório na raiz da Web. Os invasores podem carregar arquivos de origem PHP mal-intencionados nesse programa e, posteriormente, solicitar esses arquivos ao servidor, o que fará com que eles sejam executados pelo intérprete PHP.

<?php
$udir = 'upload/'; // Relative path under Web root
$ufile = $udir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $ufile)) {
    echo "Valid upload received\n";
} else {
    echo "Invalid upload rejected\n";
} ?>

Mesmo que um programa armazene arquivos carregados em um diretório não acessível na Web, os invasores ainda podem ser capazes de se aproveitar da capacidade de introduzir conteúdo mal-intencionado no ambiente do servidor para preparar outros ataques. Se o programa for suscetível a vulnerabilidades de manipulação de caminho, injeção de comando ou inclusão remota, um invasor poderá carregar um arquivo com conteúdo mal-intencionado e fazer com que este seja lido ou executado pelo programa ao explorar outra vulnerabilidade.

Quando presente, a opção de configuração open_basedir tenta impedir que programas PHP operem em arquivos fora das árvores de diretório especificadas em php.ini. Se nenhum diretório for especificado usando a opção open_basedir, então os programas executados em PHP recebem acesso total a arquivos arbitrários no sistema de arquivos local, o que pode permitir que invasores leiam, gravem ou criem arquivos que eles não deveriam ser capazes de acessar.

Não especificar um conjunto restritivo de diretórios com open_basedir pode tornar mais fácil para os invasores explorarem outras vulnerabilidades.

Apesar da opção open_basedir ser um trunfo geral para a segurança, a implementação sofre de uma condição de corrida que pode permitir que os invasores contornem suas restrições em algumas circunstâncias [2]. Existe uma condição de corrida de tempo de verificação e tempo de uso (TOCTOU) entre o momento em que o PHP executa a verificação de permissão de acesso e quando o arquivo é aberto. Tal como acontece com as condições de corrida do sistema de arquivos em outras linguagens, essa condição de corrida pode permitir que os invasores substituam um link simbólico para um arquivo que transfere uma verificação de controle de acesso por outro, sendo que de outra forma, o teste falharia, obtendo acesso ao arquivo protegido.

A janela de vulnerabilidade para tal ataque é o período entre o instante em que a verificação de acesso é executada e o instante em que o arquivo é aberto. Mesmo que as chamadas sejam feitas de forma sucessiva, os sistemas operacionais modernos não oferecem nenhuma garantia quanto ao volume de código que é executado antes de o processo liberar a CPU. Os invasores têm uma variedade de técnicas para expandir a duração da janela de oportunidade a fim de tornar as explorações mais fáceis, mas mesmo com uma janela pequena, uma tentativa de exploração pode simplesmente ser repetida indefinidamente até ser bem-sucedida.

Quando a opção safe_mode está habilitada, a opção safe_mode_exec_dir impede que o PHP execute comandos apenas dos diretórios especificados. Embora a ausência da entrada safe_mode_exec_dir não represente por si só uma vulnerabilidade de segurança, essa complacência adicional pode ser explorada por invasores em conjunto com outras vulnerabilidades para tornar as explorações ainda mais perigosas.

Quando presente, a opção de configuração open_basedir tenta impedir que programas PHP operem em arquivos fora das árvores de diretórios especificadas em php.ini. Se o diretório de trabalho for especificado com ., isso poderá ser alterado por um invasor com o uso de chdir().

Embora a opção open_basedir seja uma vantagem geral para a segurança, a implementação é afetada por uma condição de corrida que pode permitir que os invasores se esquivem de suas restrições em algumas circunstâncias [2]. Existe uma condição de corrida TOCTOU (tempo de verificação/tempo de uso) entre o momento em que o PHP realiza a verificação de permissão de acesso e o momento em que o arquivo é aberto. Tal como acontece com condições de corrida no sistema de arquivos em outras linguagens, essa condição de corrida pode permitir que os invasores substituam um link simbólico para um arquivo, aprovado em uma verificação de controle de acesso, por outro para o qual o teste seria reprovado de outra forma, obtendo assim acesso ao arquivo protegido.

A janela de vulnerabilidade para um ataque como esse é o período de tempo entre o momento em que a verificação de acesso é realizada e o momento em que o arquivo é aberto. Mesmo que as chamadas sejam realizadas em estreita sucessão, os sistemas operacionais modernos não oferecem nenhuma garantia sobre a quantidade de código que será executada antes que o processo se alastre na CPU. Os invasores possuem várias técnicas para expandir a duração da janela de oportunidade a fim de facilitar as explorações, mas, mesmo com uma janela pequena, uma tentativa de exploração pode ser repetida simplesmente várias vezes até ser bem-sucedida.

Quando habilitada, a opção register_globals faz com que o PHP registre todas as variáveis EGPCS (Ambiente, GET, POST, Cookie e Servidor) em um nível global, em que elas podem ser acessadas em qualquer escopo de qualquer programa PHP. Essa opção incentiva os programadores a escrever programas mais ou menos inconscientes da origem dos valores dos quais eles dependem, o que pode provocar comportamentos inesperados em ambientes bem-intencionados e deixar as portas abertas para invasores em ambientes mal-intencionados. Reconhecendo as perigosas implicações de segurança de register_globals, essa opção foi desabilitada por padrão no PHP 4.2.0 e foi preterida e removida no PHP 6.

Exemplo 1: O código a seguir é vulnerável à criação de scripts entre sites. O programador supõe que o valor de $username origina-se da sessão controlada pelo servidor, mas, em vez disso, um invasor pode fornecer um valor mal-intencionado para $username como um parâmetro de solicitação. Com a opção register_globals habilitada, esse código incluirá um valor mal-intencionado enviado por um invasor no conteúdo HTML dinâmico que ele gera.

<?php
if (isset($username)) {
    echo "Hello <b>$username</b>";
} else {
    echo "Hello <b>Guest</b><br />";
    echo "Would you like to login?";

}
?>

A opção safe_mode é um dos recursos de segurança mais importantes no PHP. Quando safe_mode está desabilitada, o PHP opera em arquivos com as permissões do usuário que a invocou, que muitas vezes é um usuário privilegiado. Embora a configuração do PHP com a opção safe_mode desabilitada por si só não introduza uma vulnerabilidade de segurança, essa complacência adicional pode ser explorada por invasores em conjunto com outras vulnerabilidades para tornar as explorações ainda mais perigosas.

Quando habilitada, a opção session.use_trans_sid faz com que o PHP transmita a ID de sessão na URL, tornando muito mais fácil para os invasores sequestrar sessões ativas ou enganar os usuários a usarem uma sessão existente que já está sob controle desses invasores.

Parâmetros transmitidos na URL são mais visíveis do que parâmetros POST e valores de cookies, pois aparecem frequentemente em históricos de navegador, marcadores, arquivos de log e outros locais altamente expostos. Se os invasores descobrirem o identificador da sessão secreto de uma sessão ativa em um sistema, eles poderão fornecer esse identificador de sessão de volta ao programa para sequestrar a sessão do usuário.

Além do sequestro de sessão, expor uma ID de sessão na URL também facilita ataques de fixação de sessão. Na exploração canônica de vulnerabilidades de fixação de sessão, o invasor cria uma nova sessão em um aplicativo Web e registra o identificador de sessão associado. Em seguida, o invasor faz com que a vítima se autentique no servidor usando esse identificador de sessão, o que dá a ele acesso à conta do usuário através da sessão ativa. Transmitir o identificador de sessão na URL permite que os invasores atinjam um grande número de vítimas potenciais, enviando a elas URLs que incluem um identificador de sessão comprometido por e-mail ou outro mecanismo de comunicação em massa.

Quando presente, a opção de configuração open_basedir tenta impedir que programas PHP operem em arquivos fora das árvores de diretórios especificadas em php.ini. Embora a opção open_basedir seja uma vantagem geral para a segurança, a implementação é afetada por uma condição de corrida que pode permitir que os invasores se esquivem de suas restrições em algumas circunstâncias [2]. Existe uma condição de corrida TOCTOU (tempo de verificação/tempo de uso) entre o momento em que o PHP realiza a verificação de permissão de acesso e o momento em que o arquivo é aberto. Tal como acontece com condições de corrida no sistema de arquivos em outras linguagens, essa vulnerabilidade pode permitir que os invasores substituam um link simbólico para um arquivo, aprovado na verificação de controle de acesso, por outro para o qual o teste seria reprovado de outra forma, obtendo assim acesso ao arquivo protegido.

A janela de vulnerabilidade para um ataque como esse é o período de tempo entre o momento em que a verificação de acesso é realizada e o momento em que o arquivo é aberto. Mesmo que as chamadas sejam realizadas em estreita sucessão, os sistemas operacionais modernos não oferecem nenhuma garantia sobre a quantidade de código que será executada antes que o processo se alastre na CPU. Os invasores possuem várias técnicas para expandir a duração da janela de oportunidade a fim de facilitar as explorações, mas, mesmo com uma janela pequena, uma tentativa de exploração pode ser repetida simplesmente várias vezes até ser bem-sucedida.

Nomes duplicados de form-bean não têm qualquer utilidade, pois apenas a última entrada será registrada quando o mesmo nome é usado em várias tags <form-bean>.

Exemplo 1: A seguinte configuração tem duas entradas form-bean com o mesmo nome.

<form-beans>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaActionForm">
    <form-property name="favoriteColor" type="java.lang.String" />
  </form-bean>
</form-beans>

O Struts usa o atributo path para localizar o recurso necessário para lidar com uma solicitação. Como o caminho é uma localização relativa ao módulo, é um erro se não começar com um caractere "/".

Exemplo 1: A configuração a seguir contém um caminho em branco.

<global-exceptions>
  <exception key="global.error.invalidLogin" path="" scope="request" type="InvalidLoginException" />
</global-exceptions>

Exemplo 2: A configuração a seguir usa um caminho que não começa com um caractere "/".

<global-forwards>
  <forward name="login" path="Login.jsp" />
</global-forwards>

A especificação de struts exige um atributo input sempre que uma ação nomeada retorna erros de validação [2]. O atributo input especifica a página usada para exibir mensagens de erro quando ocorrem erros de validação.
Exemplo 1: A configuração a seguir define uma ação de validação nomeada, mas não especifica um atributo input.

<action-mappings>
  <action   path="/Login"
            type="com.LoginAction"
            name="LoginForm"
            scope="request"
            validate="true" />
</action-mappings>

A tag <exception> exige que um tipo de exceção seja definido. Um atributo type ausente ou em branco é indicativo de um manipulador de exceção supérfluo ou uma omissão acidental. Se um desenvolvedor pretendia lidar com uma exceção, mas se esqueceu de definir o tipo de exceção, o aplicativo pode vazar informações confidenciais sobre o sistema.
Exemplo 1: A configuração a seguir omite o tipo da tag <exception>.

  <global-exceptions>
    <exception
      key="error.key"
      handler="com.mybank.ExceptionHandler"/>
  </global-exceptions>