Protection contre les vulnérabilités

De temps à autre, une faille de sécurité majeure est annoncée, voire exploitée, sur un autre site important. C'est désagréable. Si vous tenez à la sécurité de vos applications web, Nette Framework est sans conteste le meilleur choix.

Cross-Site Scripting (XSS)

Le Cross-Site Scripting est une méthode de perturbation des sites web qui exploite des sorties non échappées. Un attaquant peut alors injecter son propre code dans la page et ainsi la modifier, voire obtenir des données sensibles sur les visiteurs. La protection contre le XSS exige un échappement systématique et correct de toutes les chaînes affichées. Si votre développeur l'oublie une seule fois, tout le site peut être compromis.

Un exemple d'attaque consiste à fournir à un utilisateur une URL modifiée qui injecte du code dans la page. Si l'application n'échappe pas correctement ses sorties, le script s'exécute dans le navigateur de l'utilisateur. On peut ainsi, par exemple, lui voler son identité.

https://example.com/?search=<script>alert('Attaque XSS réussie.');</script>

Nette Framework introduit la technologie révolutionnaire de l'échappement contextuel, qui élimine définitivement le risque de Cross-Site Scripting. Elle échappe automatiquement toutes les sorties selon le contexte, si bien qu'un développeur ne peut rien oublier par mégarde. Un exemple ? Un développeur crée ce template :

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

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

La notation {$message} signifie l'affichage d'une variable. Dans d'autres frameworks, il faut échapper explicitement chaque sortie, et même différemment à chaque endroit. Dans Nette Framework, rien n'a besoin d'être échappé : tout se fait automatiquement, correctement et de façon systématique. Si nous définissons la variable $message = 'Largeur 1/2"', le framework génère le code HTML suivant :

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

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

Cross-Site Request Forgery (CSRF)

Une attaque Cross-Site Request Forgery consiste, pour l'attaquant, à attirer la victime sur une page qui exécute discrètement, depuis son navigateur, une requête vers un serveur sur lequel elle est connectée. Le serveur croit que la requête a été faite volontairement par la victime. Sous l'identité de celle-ci, il effectue donc une action à son insu. Cela peut être la modification ou la suppression de données, l'envoi d'un message, etc.

Nette Framework protège automatiquement les formulaires et les signaux des presenters contre ce type d'attaque en empêchant qu'ils soient envoyés ou déclenchés depuis un autre domaine. Si vous voulez désactiver la protection, utilisez pour les formulaires :

$form->allowCrossOrigin();

ou, dans le cas d'un signal, ajoutez l'attribut :

use Nette\Application\Attributes\Requires;

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

Cette protection repose sur l'en-tête Sec-Fetch-Site (Fetch Metadata), que le navigateur envoie automatiquement et qu'il est impossible de falsifier, même avec une faille XSS côté serveur. L'article The browser finally solves CSRF le décrit en détail.

Attaque par URL, codes de contrôle, UTF-8 invalide

Différents termes désignant la tentative d'un attaquant d'injecter une entrée malveillante dans votre application web. Les conséquences peuvent varier fortement, de la corruption des sorties XML (par exemple des flux RSS qui ne fonctionnent plus) à l'obtention d'informations sensibles de la base de données ou de mots de passe. La défense consiste à valider systématiquement toutes les entrées au niveau des octets. Et soyons honnêtes : combien d'entre vous le font réellement ?

Nette Framework le fait pour vous, automatiquement. Vous n'avez rien à configurer et toutes les entrées seront assainies.

Session Hijacking, Session Stealing, Session Fixation

Plusieurs types d'attaques sont liés à la gestion des sessions. Un attaquant vole l'ID de session de l'utilisateur ou lui en impose un, et obtient ainsi l'accès à l'application web sans connaître son mot de passe. Il peut alors effectuer n'importe quelle action dans l'application à l'insu de l'utilisateur. La défense réside dans une configuration correcte du serveur et de PHP.

Nette Framework configure PHP automatiquement. Le programmeur n'a donc pas à réfléchir à la façon de sécuriser correctement la session et peut se concentrer pleinement sur le développement de l'application. Cela exige cependant que la fonction ini_set() soit activée.

Les cookies SameSite offrent un mécanisme permettant de reconnaître ce qui a conduit au chargement de la page, ce qui est essentiel pour la sécurité.

Le drapeau SameSite peut prendre trois valeurs : Lax, Strict et None (cette dernière exige HTTPS). Si une requête pour une page vient directement du site, ou si l'utilisateur ouvre la page en la saisissant directement dans la barre d'adresse ou en cliquant sur un favori, le navigateur envoie tous les cookies au serveur (c'est-à-dire ceux portant les drapeaux Lax, Strict et None). Si l'utilisateur arrive sur le site par un lien venant d'un autre site, les cookies portant les drapeaux Lax et None sont transmis au serveur. Si la requête est émise autrement, par exemple par l'envoi d'un formulaire POST depuis une autre origine, un chargement dans une iframe, l'usage de JavaScript, etc., seuls les cookies portant le drapeau None sont envoyés.

Nette envoie par défaut tous les cookies avec le drapeau Lax.