Bonjour,

Je travaille actuellement pour une entreprise qui souhaite mieux sécuriser ses applications PHP en appliquant les préconisations définies lors d'un audit. Ces recommandations insistent, entre autres, sur l'utilisation de l'ESAPI.

Les nouvelles applications seront développées à l'aide de Jelix. Il s'agira déjà d'un progrès considérable en matière de sécurité, néanmoins je me pose quelques questions :

Jelix repose-t-il sur ESAPI pour l'implémentation de certaines briques ?
Est-ce que Jelix prend en charge la canonicalisation des données saisies ou faut-il quand même utiliser les encoders ESAPI ?

Merci d'avance pour vos réponses.

Bonjour,

Jelix repose-t-il sur ESAPI pour l'implémentation de certaines briques ?

non. Jelix a ses propres mécanismes de sécurité. (Je ne connais pas ESAPI).

Est-ce que Jelix prend en charge la canonicalisation des données saisies ou faut-il quand même utiliser les encoders ESAPI ?

Je ne comprends pas la question. Que veux dire "canonicalisation" ? Et c'est quoi un encodeur ESAPI ?

Et pourquoi utiliser ESAPI ? Elle a quoi de particulier cette lib ?

Désolé si je n'ai pas été assez clair.

En fait l'OWASP (Open Web Application Security Project) est un organisme à dimension internationale dont le domaine de compétences est la sécurité des systèmes infomatiques. Ils produisent différentes ressources sur le sujet (articles, tutoriels, référencements, statistiques) mais également des API comme l'ESAPI (OWASP Enterprise Security API).

Il s'agit donc d'une bibliothèque libre et open source disponible dans plusieurs langages de programmation dont le PHP. Son objectif est de fournir aux développeurs des mécanismes sûrs de contrôle et de validation de données par exemple.

Donc je reviens à mes moutons. Je suis prestataire de services et la société pour laquelle je travaille a fait intervenir un consultant en sécurité informatique qui préconise l'utilisation d'ESAPI.

En parallèle, les futures applications PHP de mon client tourneront de plus en plus avec Jelix. La question qu'on me pose est donc : « Jelix traite-t-il de façon transparente les problèmes de sécurité soulevés lors de l'audit ».

J'ai déjà répondu partiellement à la question mais je me permets d'ouvrir le débat ici, d'une part parce que je considère que c'est intéressant et d'autre part pour avoir un peu plus d'informations au sujet de la canonicalization. Je ne connaissais pas ce concept non plus avant. À priori il s'agit de traiter les données entrantes dans l'application de façon à s'assurer qu'elles sont conformes à un format ou un encodage prédéfini.

Je me demandais si vous connaissiez ces techniques et donc si vous pouviez m'en dire plus.

Je ne connais pas ESAPI, et je n'ai pas trop le temps de me pencher dessus, donc je ne peux rien en dire, et ni dire si Jelix contient toutes les fonctionnalités similaires de ESAPI.

Jelix a bien entendu des mécanismes de sécurités, contre par exemple les problèmatiques CSRF, XSS et d'autres, avec des fonctions de filtrage automatique, sur les contenus HTML soumis par exemple.

Faudrait voir après si il est possible d'utiliser ESAPI avec une appli Jelix, mais je n'ai pas le temps de me pencher dessus. Probablement d'ailleurs que ça ferais doublons sur pas mal de chose dans jelix, en plus d'apporter l'aspect usine a gaz de cette lib ESAPI, quand je vois le nombre de classes, de lib dépendantes etc. Bonjour les perfs.

Si tu pouvais me dire quels sont les points particuliers sur lesquels la sécurité doit être mise, je pourrais te dire si jelix les prends en compte ou non.

Je ne sais pas si la librairie est optitmisée, ou même si elle est exempte de bugs :)

Et puis Jelix répond déjà à pas mal de problèmes, il y a juste pour la « canonicalization » que je me demandais. Pour être plus précis, voici la partie des préconisations qui en parle :

Normaliser les données en entrée peut permettre de simplifier la validation de données et de >la rendre plus robuste.

Si les données en entrée sont encodées d’une façon qui n’est pas correctement gérée par les >filtres de validation, un agresseur pourrait avoir la possibilité de contourner le mécanisme >de validation. Avant d’utiliser les données il faut donc toujours les convertir dans un format >d’encodage bien défini. Cette façon de traiter les données est appelée « canonicalisation ».
Pour exemple, un même caractère « interdit » pourrait se présenter de façon différente selon >le type d’encodage utilisé par l’agresseur : $#x3E et %3e sont équivalent au caractère « > ». >Un filtre de validation conçu pour éviter à un utilisateur de saisir le « > » pourrait être >contourné si une phase de « canonicalisation » n’est pas effectuée.

Un exemple de « canonicalisation » réalisé avec la librairie OWASP ESAPI est le suivant :

$encoded = "%3Cscript>alert%28%27xss&#39%29%3C%2Fscript%3E";
$encode = ESAPI::getEncoder();
try{
$canonical = $encode->canonicalize($encoded);
} catch( IntrusionException $e ) {
<code>
	$userMessage = $e->getUserMessage();
	$logMessage = $e->getLogMessage();

}

Il y a aussi une autre fonctionnalité intéressante c'est la génération de « jeton » dynamique pour se protéger des CSRF. Elle est disponible sur certains outils ou CMS.

Voici un exemple d'implémentation sur Joomla. Je ne crois pas que Jelix propose ça.

En ce qui concerne la canonicalisation, jelix, ET php le gère déjà, à priori. Il y a les API pour le faire (à moins que tu ais des exemples plus tordu ?)

Dans Jelix, comme je l'ai dit, en utilisant jForms, et pour les champs qui acceptent du HTML, il y a déjà un nettoyage automatique qui est fait par l'objet jFilter, pour ne garder que les balises et attributs autorisés. Et pour les autres types de valeur, il y a aussi une vérification du contenu reçu, pour savoir si il correspond au type demandé.

On peut aussi utiliser les fonctions filter de PHP (ou encore jFilter) pour faire aussi d'autres types de nettoyage, de "sanitisation".

Quand on récupère les paramètres HTTP, on a la possibilité d'utiliser intParam(), floatParam() et autre au lieu de param() pour "sanitiser" certains types de données. (ce qui revient à 2 lignes de code dans l'implémentation, pas besoin de charger une lib de je ne sais combien de classes pour faire ça).

Et dans les templates une simple application du modificateur eschtml (qui revient à un simple appel à htmlspecialchars) sur les variables que l'on affiche, suffit à inhiber toute tentative d'attaque du style indiqué dans ton exemple.

Pour les CSRF, jForms gère également ce type d'attaque, automatiquement, comme je l'ai dit dans mon message plus haut, avec un système de token à durée limitée etc.

Dans tout les cas, il me semble qu'il y a tout les outils qu'il faut dans Jelix ou PHP, pour que dans ton contrôleur tu fasses les vérifications et nettoyages nécessaires. Je n'ai pas l'impression que cette lib soit rééllement nécessaire.

Si il manque des trucs, je suis intéressé de le savoir, afin d'améliorer le framework en ce sens si c'est nécessaire.

C'est un peu la conclusion à laquelle j'étais arrivé également.

L'utilisation de cette librairie ne me parait pas vraiment justifiée pour les projets basés sur Jelix et, au pire, si quelque chose de spécifique manque on peut se brancher à différents endroits pour l'ajouter.

Merci pour ces réponses en tout cas.