Segurança de Camada de Transporte Insuficiente (HTTPS, TLS e SSL)

A comunicação entre as partes através da Internet é repleta de riscos. Quando você está enviando instruções de pagamento para uma loja usando o recurso on-line, a última coisa que você deseja é que um atacante seja capaz de interceptar, ler, manipular ou reproduzir a solicitação HTTP para o aplicativo on-line. Você pode imaginar as conseqüências de um invasor poder ler o cookie de sessão ou manipular o recebedor, o produto ou o endereço de cobrança ou simplesmente injetar novo HTML ou Javascript na marcação enviada em resposta a uma solicitação do usuário para a loja.

Proteger dados confidenciais ou privados é um assunto sério. Os usuários de aplicativos e navegadores têm uma expectativa extremamente alta a esse respeito, valorizando a integridade de suas transações com cartão de crédito, sua privacidade e suas informações de identidade. A resposta a essas preocupações quando se trata de defender a transferência de dados entre duas partes é usar a Segurança da Camada de Transporte, geralmente envolvendo HTTPS, TLS e SSL.

Os objetivos gerais dessas medidas de segurança são os seguintes:

  • Para criptografar com segurança os dados que estão sendo trocados
  • Para garantir a identidade de uma ou ambas as partes
  • Para impedir a adulteração de dados
  • Para evitar ataques de repetição

O ponto mais importante a ser notado acima é que todas as quatro metas devem ser cumpridas para que a Segurança da Camada de Transporte seja bem-sucedida. Se qualquer um dos itens acima estiver comprometido, teremos um problema real.

Um equívoco comum, por exemplo, é que a criptografia é o objetivo principal e os outros não são essenciais. Isso é, na verdade, completamente falso. A criptografia dos dados transmitidos exige que a outra parte seja capaz de descriptografar os dados. Isso é possível porque o cliente e o servidor concordarão com uma chave de criptografia (entre outros detalhes) durante a fase de negociação, quando o cliente tentar uma conexão segura. No entanto, um invasor pode se posicionar entre o cliente e o servidor usando vários métodos simples para enganar uma máquina cliente e acreditar que o invasor é o servidor que está sendo contatado, ou seja, um homem no meio (MitM) Ataque. Essa chave de criptografia será negociada com o MitM e não com o servidor de destino. Isso permitiria que o invasor descriptografasse todos os dados enviados pelo cliente. Obviamente, Portanto, precisamos do segundo objetivo – a capacidade de verificar a identidade do servidor com o qual o cliente está se comunicando. Sem essa verificação, não temos como informar a diferença entre um servidor de destino genuíno e um invasor MitM.

Portanto, todos os quatro objetivos de segurança acima DEVEM ser atendidos antes que uma comunicação segura possa ocorrer. Cada um deles trabalha para complementar perfeitamente os outros três objetivos e é a presença de todos os quatro que fornece segurança de Camada de Transporte confiável e robusta.

Além dos aspectos técnicos de como o Transport Layer Security funciona, a outra faceta da troca segura de dados está em quão bem nós aplicamos essa segurança. Por exemplo, se permitirmos que um usuário envie os dados do formulário de login de um aplicativo por HTTP, devemos aceitar que um MitM seja totalmente capaz de interceptar esses dados e registrar os dados de login do usuário para uso futuro. Se permitirmos que páginas carregadas em HTTPS carreguem recursos não HTTPS, devemos aceitar que um MitM tenha um veículo com o qual injetar ataques de Cross-Site Scripting para transformar o navegador do usuário em uma arma pré-programada que funcionará sobre a conexão HTTPS do navegador de forma transparente.

Ao julgar a qualidade de segurança de qualquer implementação, temos, portanto, algumas medidas muito óbvias, tiradas dos quatro objetivos que mencionei anteriormente:

  • Criptografia: a implementação usa um padrão de segurança forte e um conjunto de criptografia?
  • Identidade: a implementação verifica a identidade do servidor correta e completamente?
  • Adulteração de dados: a implementação protege totalmente os dados do usuário durante a sessão do usuário?
  • Ataques de repetição: a implementação contém um método de impedir que um invasor registre solicitações e as envie repetidamente ao servidor para repetir uma ação ou um efeito conhecido?

Essas perguntas são o seu conhecimento básico para todo este capítulo. Entrarei em mais detalhes ao longo do capítulo, mas tudo se resume a fazer essas perguntas e identificar as vulnerabilidades em que elas não se concretizam.

Um segundo entendimento central é o que os dados do usuário devem ser protegidos. Detalhes do cartão de crédito, informações pessoalmente identificáveis ​​e senhas obviamente precisam ser protegidos. No entanto, e quanto ao ID da sessão do usuário? Se protegermos as senhas, mas não protegermos a ID da sessão, o invasor ainda poderá roubar o cookie da sessão enquanto estiver em trânsito e executando um ataque de invasão de sessão para representar o usuário em seu próprio PC. Apenas proteger formulários de login NUNCA é suficiente para proteger a conta ou as informações pessoais de um usuário. A melhor segurança é obtida ao restringir a sessão do usuário para HTTPS a partir do momento em que eles enviam um formulário de login até o momento em que encerram sua sessão.

Agora você deve entender porque este capítulo usa a frase “insuficiente”. O problema na implementação do SSL / TLS não está na sua falha em usá-lo, mas na falha em usá-lo em um grau suficiente para que a segurança do usuário seja maximizada.

Este capítulo aborda a questão da segurança insuficiente da camada de transporte de três ângulos.

  • Entre um aplicativo do lado do servidor e um servidor de terceiros.
  • Entre um cliente e o aplicativo do lado do servidor.
  • Entre um cliente e o aplicativo do lado do servidor usando defesas personalizadas.

O primeiro aborda a tarefa de garantir que nossos aplicativos da Web se conectem com segurança a outras partes. O Transport Layer Security é comumente usado para APIs de serviço da web e muitas outras fontes de entrada exigidas pelo aplicativo.

O segundo aborda as interações de um usuário com nossos aplicativos da Web usando um navegador ou algum outro aplicativo cliente. Neste caso, somos aqueles que expõem uma URL segura e precisamos garantir que essa segurança seja implementada corretamente e não corra o risco de ser ignorada.

O terceiro é uma curiosidade estranha. Como o SSL / TLS tem a reputação de não ser implementado corretamente pelos programadores, existem várias abordagens desenvolvidas para proteger uma conexão sem o uso dos padrões SSL / TLS estabelecidos. Um exemplo é a confiança do OAuth em solicitações assinadas que não exigem SSL / TLS, mas oferecem algumas das defesas desses padrões (notavelmente, a criptografia dos dados do pedido é omitida, por isso não é perfeita, mas uma opção melhor do que uma biblioteca SSL / TLS configurada incorretamente) .

Antes de chegarmos a essas categorias específicas, vamos primeiro dar uma olhada na Segurança da Camada de Transporte em geral, já que há algum conhecimento básico importante que devemos ter em mente antes de nos aprofundarmos nas porcas e parafusos com o PHP.

Definições e Vulnerabilidades Básicas

Segurança da Camada de Transporte é um título genérico para proteger a conexão entre duas partes usando criptografia, verificação de identidade e assim por diante. A maioria dos leitores estará familiarizada com as três abreviações comuns usadas neste tópico: HTTPS, SSL, TLS. Vamos definir brevemente cada um para que todos entendam como estão relacionados.

SSL / TLS do PHP (Servidor para Servidor)

Por mais que eu adore PHP como linguagem de programação, a pesquisa mais breve sobre bibliotecas populares de código aberto deixa muito claro que as vulnerabilidades relacionadas à Segurança da Camada de Transporte são extremamente comuns e, por extensão, são toleradas pela comunidade PHP É mais fácil sujeitar os usuários a violações de segurança que invadem a privacidade do que corrigir o problema subjacente. Isto é apoiado pelo próprio PHP sofrendo de uma implementação muito pobre de SSL / TLS em PHP Streams que são usados ​​por tudo, desde clientes HTTP baseados em soquete até as file_get_contents()e outras funções do sistema de arquivos. Essa falha é então exacerbada pelo fato de que a biblioteca PHP não faz nenhum esforço para discutir as implicações de segurança das falhas de SSL / TLS.

Se você não tomar mais nada desta seção, meu conselho é garantir que todas as solicitações HTTPS sejam executadas usando a extensão CURL para PHP. Essa extensão é configurada para ser segura por padrão e é submetida a backup, em termos de revisão por especialistas, por sua grande base de usuários fora do PHP. Tome este passo simples para uma maior segurança e você não vai se arrepender. Uma solução mais ideal seria que os desenvolvedores internos do PHP acordassem e aplicassem o princípio Secure By Default ao seu suporte SSL / TLS integrado.

Minha introdução ao SSL / TLS no PHP é obviamente muito dura. As vulnerabilidades da Camada de Transporte de Segurança são muito mais básicas do que a maioria das questões de segurança e todos nós estamos familiarizados com a ênfase que ela recebe nos navegadores. Nossos aplicativos do lado do servidor não são menos importantes na cadeia de proteção de dados do usuário. Vamos examinar o SSL / TLS no PHP com mais detalhes, procurando por sua vez no PHP Streams e na extensão CURL superior.

Fluxos PHP

Para aqueles que não estão familiarizados com o recurso Streams do PHP, ele foi introduzido para generalizar arquivos, redes e outras operações que compartilhavam funcionalidades e usos comuns. Para dizer a um fluxo como lidar com um protocolo específico, existem “wrappers” que permitem que um Stream represente um arquivo, uma solicitação HTTP, um arquivo PHAR, um Data URI (RFC 2397) e assim por diante. Abrir um fluxo é simplesmente uma questão de chamar uma função de arquivo de suporte com uma URL relevante que indica o wrapper e o recurso de destino a serem usados.

file_get_contents ( 'file: ///tmp/file.ext' );

Os fluxos padrão usam um File Wrapper, portanto, você normalmente não precisa usar um URL file: // e pode até usar caminhos relativos. Isto deveria ser óbvio desde a maioria das funções do sistema de arquivos, como file()include()require_oncefile_get_contents()todos aceitam referências de fluxo. Então podemos reescrever o exemplo acima como:

file_get_contents ( '/tmp/file.ext' );

Além de arquivos e de relevância para nosso tópico atual de discussão, também podemos fazer o seguinte:

file_get_contents ( 'http://www.example.com' );

Como as funções do sistema de arquivos, como file_get_contents()suporte ao HTTP, fazem do PHP um muito simples para acessar o cliente HTTP, caso você não sinta a necessidade de usar uma biblioteca cliente HTTP dedicada, como as \Zend\Http\Clientclasses Guzzle, Buzz ou Zend Framework . Para que isso funcione, você precisará ativar a opção de configuração php.inido arquivo allow_url_fopen. Essa opção é ativada por padrão.

Naturalmente, a allow_url_fopenconfiguração também apresenta um risco separado de ativar ataques de Execução Remota de Arquivo, Desvio de Controle de Acesso ou Divulgação de Informações. Se um invasor puder injetar um URI remoto de sua escolha em uma função de arquivo, ele poderá manipular um aplicativo para executar, armazenar ou exibir o arquivo buscado, incluindo aqueles de qualquer fonte remota não confiável. Também vale a pena ter em mente que essas buscas de arquivos se originam do host local e, portanto, são capazes de contornar os controles de acesso baseados nas restrições do servidor local. Assim, enquanto allow_url_fopenestiver ativado por padrão, você deve desativá-lo sem hesitação para maximizar a segurança.

De volta ao uso do PHP Streams como um simples cliente HTTP (que você agora sabe que NÃO é recomendado), as coisas ficam interessantes quando você tenta o seguinte:

$ url  =  'https://api.twitter.com/1/statuses/public_timeline.json' ; 
$ result  =  file_get_contents ( $ url );

 

O acima é um pedido não autenticado simples para a (antiga) API do Twitter 1.0 sobre HTTPS. Também tem uma falha séria. O PHP usa um para solicitações feitas usando os wrappers HTTPS ( https: // ) e FTPS (ftps: //). O oferece muitas configurações para SSL / TLS e seus valores padrão são totalmente inseguros. O exemplo acima pode ser reescrito da seguinte forma para mostrar como um conjunto padrão de opções pode ser conectado como um parâmetro:SSL ContextSSL ContextSSL Contextfile_get_contents()

$url = 'https://api.twitter.com/1/statuses/public_timeline.json';
$contextOptions = array(
    'ssl' => array()
);
$sslContext = stream_context_create($contextOptions);
$result = file_get_contents($url, NULL, $sslContext);

 

Conforme descrito anteriormente neste capítulo, a falha em configurar o SSL / TLS com segurança deixa o aplicativo aberto para ataques do tipo Man-In-The-Middle (MitM). Fluxos PHP são totalmente inseguros por SSL / TLS por padrão. Então, vamos corrigir o exemplo acima para torná-lo completamente seguro!

$url = 'https://api.twitter.com/1/statuses/public_timeline.json';
$contextOptions = array(
    'ssl' => array(
        'verify_peer'   => true,
        'cafile'        => '/etc/ssl/certs/ca-certificates.crt',
        'verify_depth'  => 5,
        'CN_match'      => 'api.twitter.com',
        'disable_compression' => true,
        'SNI_enabled'         => true,
        'ciphers'             => 'ALL!EXPORT!EXPORT40!EXPORT56!aNULL!LOW!RC4'
    )
);
$sslContext = stream_context_create($contextOptions);
$result = file_get_contents($url, NULL, $sslContext);

 

Agora temos um exemplo seguro! Se você comparar isso com o exemplo anterior, você notará que tivemos que definir quatro opções que eram, por padrão, não definidas ou desativadas pelo PHP. Vamos examinar cada um deles para desmistificar seu propósito.

  • verify_peer

A Verificação por Pares é o ato de verificar se o Certificado SSL apresentado pelo Host para o qual enviamos a solicitação HTTPS é válido. Para ser válido, o certificado público do servidor deve ser assinado pela chave privada de uma autoridade de certificação (CA) confiável. Isso pode ser verificado usando a chave pública da CA, que será incluída no conjunto de arquivos como a cafileopção para o contexto SSL que estamos usando. O certificado também não deve ter expirado.

  • cafile

cafileconfiguração deve apontar para um arquivo válido contendo as chaves públicas de CAs confiáveis. Isso não é fornecido automaticamente pelo PHP, então você precisa ter as chaves em um arquivo formatado com certificado concatenado (geralmente um arquivo PEM ou CRT). Se você está tendo alguma dificuldade para localizar uma cópia, você pode baixar uma cópia que é analisada do VCS da Mozilla em http://curl.haxx.se/ca/cacert.pem . Sem esse arquivo, é impossível realizar a verificação por pares e a solicitação falhará.

  • verify_depth

Essa configuração define o número máximo permitido de emissores de certificados intermediários, ou seja, o número de certificados de autoridade de certificação que podem ser seguidos durante a verificação do certificado de cliente inicial.

  • CN_match

As três opções anteriores se concentraram em verificar o certificado apresentado pelo servidor. No entanto, eles não nos dizem se o certificado verificado é válido para o nome de domínio ou endereço IP que estamos solicitando, ou seja, a parte do host do URL. Para garantir que o certificado esteja vinculado ao domínio / IP atual, precisamos realizar a verificação de host. No PHP, isso requer configuraçãoCN_matchno contexto SSL para o valor do host HTTP (incluindo a parte do subdomínio, se presente!). O PHP executa a correspondência internamente, desde que esta opção esteja configurada. A não realização dessa verificação permitiria que um MitM apresentasse um certificado válido (ao qual ele pode se candidatar facilmente em um domínio sob seu controle) e o reutilizasse durante um ataque para garantir que estivesse apresentando um certificado assinado por uma CA confiável. No entanto, tal certificado só seria válido para o seu domínio – e não aquele para o qual você está tentando se conectar. Definir a CN_matchopção detectará essas incompatibilidades de certificado e causará falha na solicitação HTTPS.

Embora esse certificado válido usado por um invasor contenha informações de identidade específicas do invasor (uma condição prévia para a obtenção de um!), Lembre-se de que há, indubitavelmente, vários certificados válidos assinados por CA, completos com chaves privadas correspondentes, disponíveis para um invasor experiente. Estes podem ter sido roubados de outra empresa ou ter passado por um radar da CA confiável, como aconteceu em 2011, quando o DigiNotor notoriamente (desculpe, não resistiu) emitiu um certificado para google.comuma parte desconhecida que o empregou em ataques MitM predominantemente contra ataques iranianos. Comercial.

  • disable_compression

Esta opção foi introduzida no PHP 5.4.13 e serve como uma defesa contra ataques CRIME e outros ataques derivados de oracle acolchoados como o BEAST. No momento da escrita, ele estava disponível há 10 meses e localizar um único exemplo de seu uso no PHP de código aberto era praticamente uma missão com extrema paciência.

  • SNI_enabled

Ativa o suporte para Indicação de Nome do Servidor, em que qualquer endereço IP pode ser configurado para apresentar vários certificados SSL, em vez de ficar restrito a um único certificado para todos os sites ou serviços não HTTP hospedados nesse IP.

  • ciphers (cifras)

Essa configuração permite que os programadores indiquem quais cifras devem ou não devem ser usadas ao estabelecer conexões SSL / TLS. A lista padrão de cifras fornecidas pela extensão openssl contém um número de cifras inseguras que devem ser desabilitadas, a menos que seja absolutamente necessário. A lista de cifras acima, em uma sintaxe aceita pela openssl, foi implementada pela cURL em janeiro de 2014. Uma lista de cifras alternativa foi sugerida pela Mozilla, que pode ser melhor, pois enfatiza o Perfect Forward Secrecy, que é uma abordagem de melhores práticas emergentes. A lista do Mozilla é um pouco mais longa:

ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384: ECDHE-ECDSA-AES256-GCM-SHA384: 
DHE-RSA-AES128-GCM-SHA256: DHE-DSS-AES128-GCM-SHA256: kEDH + AESGCM: ECDHE-RSA-AES128-SHA256: ECDHE-ECDSA-AES128-SHA256:
ECDHE-RSA-AES128-SHA: ECDHE-ECDSA-AES128-SHA: ECDHE-RSA- AES256-SHA384: ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA:
ECDHE-ECDSA-AES256-SHA: DHE-RSA-AES128-SHA256: DHE-RSA-AES128-SHA: DHE-DSS-AES128- SHA256: DHE-RSA-AES256-SHA256: DHE-DSS-AES256-SHA:
DHE-RSA-AES256-SHA: AES128-GCM-SHA256: AES256-GCM-SHA384: ECDHE-RSA-RC4-SHA: ECDHE-ECDSA- RC4-SHA: AES128: AES256: RC4-SHA:
ALTO:! ANULL:! ENULL:! EXPORT:! DES:! 3DES:! MD5:! PSK

Limitações

Conforme descrito acima, a verificação de que o certificado apresentado por um servidor é válido para o host na URL que você está usando garante que um MitM não possa simplesmente apresentar qualquer certificado válido que possa adquirir ou obter ilegalmente. Este é um passo essencial, um dos quatro, para garantir que sua conexão seja absolutamente segura.

CN_matchparâmetro exposto pelo wrapper HTTPS do PHP diz ao PHP para realizar este exercício de correspondência, mas ele tem um lado negativo. No momento da gravação, a correspondência usada só verificará o Nome Comum (CN) do certificado SSL, mas ignorará o campo igualmente válido de Nomes Alternativos de Assunto (SANs), se definido pelo certificado. Uma SAN permite proteger vários nomes de domínio com um único certificado SSL, por isso é extremamente útil e suportado por todos os navegadores modernos. Como o PHP atualmente não suporta a correspondência de SAN, as conexões sobre SSL / TLS para um domínio protegido usando esse certificado falharão. O suporte SAN para PHP será introduzido no PHP 5.6.SSL Context

A extensão CURL, por outro lado, suporta SANs prontas para uso, por isso é muito mais confiável e deve ser usada de preferência para os wrappers HTTPS / FTPS embutidos do PHP. Usar o PHP Streams com este problema introduz um risco maior de comportamento errôneo que, por sua vez, tentaria os programadores impacientes a desabilitar completamente a verificação do host, que é a última coisa que queremos ver.

Contexto SSL no PHP Sockets

Muitos clientes HTTP em PHP oferecerão um adaptador CURL e um adaptador padrão PHP Socket. A opção padrão para usar sockets reflete o fato de que CURL é uma extensão opcional e pode ser desabilitada em qualquer servidor em estado selvagem.

Os PHP Sockets usam o mesmo recurso que o PHP Streams para que ele herde todos os problemas e limitações descritos anteriormente. Isso tem o efeito colateral que muitos dos principais clientes HTTP são, por padrão, provavelmente não confiáveis ​​e menos seguros do que deveriam ser. Tais bibliotecas cliente devem, quando possível, ser configuradas para usar seu adaptador CURL, se disponível. Você também deve analisar esses clientes para garantir que eles não estejam desativando (ou esquecendo de ativar) a abordagem correta para proteger o SSL / TLS.SSL Context

Riscos Adicionais?

Extensão CURL

Ao contrário do PHP Streams, a extensão CURL é toda sobre a realização de transferências de dados, incluindo sua capacidade mais comumente conhecida para solicitações HTTP. Além disso, ao contrário do contexto SSL do PHP Streams, o CURL é configurado por padrão para fazer solicitações com segurança por SSL / TLS. Você não precisa fazer nada especial, a menos que tenha sido compilado sem o local de um pacote de certificados da Autoridade de Certificação (por exemplo, um arquivo cacert.pem ou ca-bundle.crt contendo os certificados para CAs confiáveis).

Como não requer nenhum tratamento especial, você pode executar uma chamada similar da API do Twitter para o que usamos anteriormente para SSL / TLS em um fluxo PHP com um mínimo de problemas e sem se preocupar com opções ausentes que o tornarão vulnerável a ataques MitM.

$url = 'https://api.twitter.com/1/statuses/public_timeline.json';
$req = curl_init($url);
curl_setopt($req, CURLOPT_RETURNTRANSFER, TRUE);
$result = curl_exec($req);
 

É por isso que minha recomendação para você é preferir CURL para solicitações HTTPS. É seguro por padrão, enquanto o PHP Streams definitivamente não é. Se você se sentir à vontade para configurar opções de contexto SSL, sinta-se à vontade para usar o PHP Streams. Caso contrário, use apenas CURL e evite a dor de cabeça. No final do dia, a CURL é mais segura, requer menos código e é menos provável que sofra uma falha relacionada a erro humano em sua segurança SSL / TLS.

No momento em que este artigo foi escrito, o PHP 5.6 atingiu um release alpha1. A versão final do PHP 5.6 introduzirá padrões mais seguros para fluxos PHP e conexões de soquete sobre SSL / TLS. Estas mudanças não serão portadas para o PHP 5.3, 5.4 ou 5.5. Como tal, todos os programadores precisarão implementar configurações padrão seguras como uma escolha consciente até que o PHP 5.6 seja um requisito mínimo para seu código.

É claro que, se a extensão CURL foi ativada sem a localização do pacote de certificado confiável que está sendo configurado, o exemplo acima ainda falhará. Para as bibliotecas que pretendem ser distribuídas publicamente, o programador precisará seguir um padrão sã que imponha o comportamento seguro:

$ url  =  'https://api.twitter.com/1/statuses/public_timeline.json' ; 
$ req  =  curl_init ( $ url ); 
curl_setopt ( $ req ,  CURLOPT_RETURNTRANSFER ,  TRUE ); 
$ result  =  curl_exec ( $ req );

/ ** 
* Verifique se um erro é uma falha de SSL e tente novamente com certs de CA agrupados 
* supondo que o servidor local não tenha nenhum configurado para ext / curl. 
* Erro 77 refere-se a CURLE_SSL_CACERT_BADFILE que não é definido como 
* como uma constante no manual do PHP por algum motivo. 
* / 
$ error  =  curl_errno ( $ req ); 
if  ( $ error  ==  CURLE_SSL_PEER_CERTIFICATE  ||  $ error  ==  CURLE_SSL_CACERT 
||  $ erro  ==  77 )  { 
    curl_setopt ( $ req ,  CURLOPT_CAINFO ,  __DIR__ .  '/cert-bundle.crt' ); 
    $ result  =  curl_exec ( $ req ); 
}

/ ** 
* Quaisquer erros subsequentes não podem ser recuperados enquanto permanecerem 
* seguros. Portanto, não fique tentado a desabilitar o SSL e tente novamente;). 
* /

A parte complicada é, obviamente, distribuindo o cert-bundle.crtou cafile.pemarquivo de pacote certificado (nome do arquivo varia de acordo com fonte!). Como o certificado de qualquer Autoridade de Certificação pode ser revogado a qualquer momento pela maioria dos navegadores, caso eles sofram uma violação em seus processos de revisão ou de revisão por pares, não é uma boa ideia permitir que um arquivo de certificado permaneça obsoleto por muito tempo. No entanto, a solução mais óbvia é distribuir uma cópia desse arquivo com a biblioteca ou aplicativo que o requer.

Se você não puder garantir um controle rígido sobre a atualização de um pacote de certificados de distribuição, ou se apenas precisar de uma ferramenta que possa executar essa verificação periodicamente, considere o uso da ferramenta PHP Sslurp: https://github.com/EvanDotPro/Sslurp.

SSL / TLS do cliente (cliente / navegador para servidor)

Até agora, a maior parte do que discutimos está relacionada a conexões SSL / TLS estabelecidas a partir de um aplicativo da Web PHP para outro servidor. Naturalmente, também há algumas preocupações de segurança quando nosso aplicativo da Web é a parte que expõe o suporte SSL / TLS a navegadores clientes e outros aplicativos. Neste final do processo, corremos o risco de sofrer ataques de segurança decorrentes de vulnerabilidades da Proteção de Camada de Transporte Insuficiente.

Isso é realmente muito básico se você pensar sobre isso. Digamos que eu crie um aplicativo on-line que seja um login seguro para proteger a senha do usuário. O formulário de login é servido por HTTPS e o formulário é enviado por HTTPS. Missão cumprida. O usuário é redirecionado para um URL HTTP para começar a usar sua conta. Descubra o problema?

Quando um ataque Man-In-The-Middle (MitM) é uma preocupação, não devemos simplesmente proteger o formulário de login para os usuários e, em seguida, encerrá-lo. Por HTTP, o cookie de sessão do usuário e todos os outros dados que eles enviam, e todas as outras marcações HTML que eles recebem, não serão seguros. Um MitM pode roubar o cookie de sessão e representar o usuário, injetar XSS nas páginas da web recebidas para executar tarefas como o usuário ou manipular suas ações, e o MitM nunca precisará saber a senha para realizar tudo isso.

A simples proteção da autenticação com HTTPS evita o roubo direto de senhas, mas não impede o seqüestro de sessão, outras formas de roubo de dados e injeção de ataque de Cross-Site Scripting (XSS). Ao limitar a proteção oferecida pelo HTTPS ao usuário, estamos realizando uma proteção insuficiente na camada de transporte. Os usuários de nosso aplicativo ainda estão vulneráveis ​​a ataques MitM.

 

 

Este artigo é uma tradução de: https://phpsecurity.readthedocs.io/en/latest/Transport-Layer-Security-(HTTPS-SSL-and-TLS).html