Proteção contra Vulnerabilidades

De tempos em tempos, uma falha de segurança é relatada em outro site importante ou uma falha é explorada. Isso é desagradável. Se você se preocupa com a segurança de suas aplicações web, o Nette Framework é certamente a melhor escolha.

Cross-Site Scripting (XSS)

Cross-Site Scripting é um método de violação de sites que explora saídas não tratadas. O invasor pode então injetar seu próprio código na página e, assim, modificá-la ou até mesmo obter dados confidenciais dos visitantes. A única maneira de se defender contra XSS é tratar todas as strings de forma consistente e correta. Basta que seu codificador omita isso apenas uma vez, e todo o site pode ser comprometido instantaneamente.

Um exemplo de ataque pode ser injetar uma URL modificada para o usuário, através da qual injetamos nosso próprio código na página. Se a aplicação não tratar adequadamente as saídas, ela executará o script no navegador do usuário. Desta forma, podemos, por exemplo, roubar sua identidade.

https://example.com/?search=<script>alert('Ataque XSS bem-sucedido.');</script>

O Nette Framework vem com uma tecnologia revolucionária Context-Aware Escaping, que o livrará para sempre do risco de Cross-Site Scripting. Ele trata todas as saídas automaticamente, para que não haja chance de o codificador esquecer algo. Exemplo? O codificador cria este template:

<p onclick="alert({$message})">{$message}</p>

<script>
document.title = {$message};
</script>

A notação {$message} significa imprimir a variável. Em outros frameworks, é necessário tratar explicitamente cada impressão e, além disso, de forma diferente em cada local. No Nette Framework, não é necessário tratar nada, tudo é feito automaticamente, corretamente e consistentemente. Se atribuirmos à variável $message = 'Largura 1/2"', o framework gerará o código HTML:

<p onclick="alert(&quot;Largura 1\/2\&quot;&quot;)">Largura 1/2&quot;</p>

<script>
document.title = "Largura 1\/2\"";
</script>

Cross-Site Request Forgery (CSRF)

O ataque Cross-Site Request Forgery consiste em o invasor atrair a vítima para uma página que executa discretamente uma requisição no navegador da vítima para um servidor no qual a vítima está logada, e o servidor acredita que a requisição foi feita pela vítima por vontade própria. Assim, sob a identidade da vítima, realiza uma determinada ação sem que ela saiba. Pode ser a alteração ou exclusão de dados, envio de uma mensagem, etc.

O Nette Framework protege automaticamente formulários e sinais nos presenters contra este tipo de ataque. Isso é feito impedindo que sejam enviados ou acionados de outro domínio. Se você quiser desativar a proteção, use para formulários:

$form->allowCrossOrigin();

ou no caso de um sinal, adicione a anotação @crossOrigin:

/**
 * @crossOrigin
 */
public function handleXyz()
{
}

No Nette Application 3.2, você também pode usar atributos:

use Nette\Application\Attributes\Requires;

#[Requires(sameOrigin: false)]
public function handleXyz()
{
}

Ataque de URL, códigos de controle, UTF-8 inválido

Vários termos relacionados à tentativa de um invasor de injetar entrada maliciosa em sua aplicação web. As consequências podem ser muito diversas, desde danos às saídas XML (por exemplo, feeds RSS não funcionais) até a obtenção de informações confidenciais do banco de dados ou senhas. A defesa é o tratamento consistente de todas as entradas no nível de bytes individuais. E, sejamos honestos, quem de vocês faz isso?

O Nette Framework faz isso por você e, além disso, automaticamente. Você não precisa configurar absolutamente nada e todas as entradas serão tratadas.

Sequestro de sessão, roubo de sessão, fixação de sessão

Vários tipos de ataques estão associados ao gerenciamento de sessões. O invasor rouba ou injeta seu ID de sessão no usuário e, graças a isso, obtém acesso à aplicação web sem conhecer a senha do usuário. Ele pode então fazer qualquer coisa na aplicação sem que o usuário saiba. A defesa consiste na configuração correta do servidor e do PHP.

O Nette Framework configura o PHP automaticamente. O programador não precisa pensar em como proteger corretamente a sessão e pode se concentrar totalmente na criação da aplicação. No entanto, isso requer que a função ini_set() esteja habilitada.

Os cookies SameSite fornecem um mecanismo para reconhecer o que levou ao carregamento da página. Isso é absolutamente crucial para a segurança.

O sinalizador SameSite pode ter três valores: Lax, Strict e None (este requer HTTPS). Se a requisição para a página vier diretamente do site ou o usuário abrir a página digitando diretamente na barra de endereços ou clicando em um favorito, o navegador enviará todos os cookies ao servidor (ou seja, com os sinalizadores Lax, Strict e None). Se o usuário clicar em um link de outro site para acessar o site, os cookies com os sinalizadores Lax e None serão passados para o servidor. Se a requisição surgir de outra forma, como o envio de um formulário POST de outro site, carregamento dentro de um iframe, usando JavaScript, etc., apenas os cookies com o sinalizador None serão enviados.

O Nette, por padrão, envia todos os cookies com o sinalizador Lax.