Zend Core for i5/OS renforce la protection de votre système. Le System i utilise le langage de programmation Web bien connu, PHP. Il est donc normal qu’il exécute une grande variété de logiciels de type PHP pour le Web. Comme l’ouverture est inhérente à Internet, tout administrateur système prudent qui déploie des applications Web dans l’environnement Zend Core for i5/OS, est soucieux de sécurité.
Quelles précautions doit-il prendre ? Bien que l’architecture de System i protège déjà contre les débordements de buffer, les virus et les vers, et bien que Zend Core PHP fournisse d’autres protections que celles du PHP générique, vous devez aussi vous prémunir contre d’autres dangers.
Remarque : La sécurité sur le Web est en constante évolution. Toutes les recommandations que je fais ici sont considérées exactes au stade Zend Core for i5/OS version 2.0.1 (c’est-à-dire PHP 5.2.1).
Les sites Web basés sur PHP, de complexité variable, présenteront le plus souvent un mélange de fichiers externes et internes. Les navigateurs accèdent aux fichiers externes via des URL que les utilisateurs tapent dans leurs navigateurs ou sur lesquels ils cliquent en tant que liens.
Les fichiers internes, quoiqu’utilisés par vos applications (et peut-être même affichés aux yeux des utilisateurs) ne sont pas directement accessibles par les navigateurs, mais ne devraient être extraits que par le code applicatif. En effet, les fichiers internes directement accessibles par les utilisateurs présentent des risques.
Parmi les exemples de fichiers externes, on trouve index.php, les feuilles de style, et autres fichiers (PHP ou non) que le navigateur Web demandera. Ces fichiers peuvent être mis en toute sécurité dans la racine du document, comme la valeur par défaut de Zend, /www/zendcore/ htdocs. Comme exemples de fichiers internes, citons ceux qui sont utilisés par votre application, comme des morceaux de code « inclus » qui s’exécutent dans vos fichiers internes, mais sont stockés séparément.
Les fichiers de configuration contenant des mots de passe sont souvent inclus eux aussi. Il faut les stocker à l’extérieur de la racine document (htdocs), là où ils ne pourront pas être exécutés ni visualisés par les utilisateurs. Voici un exemple d’inclusion (exécution) d’un fichier à partir d’un emplacement sûr, comme sur le site de /www/zendcore/ : Il existe une autre catégorie à risque : tout ce qui peut être téléchargé par les utilisateurs. Il ne faut jamais mettre des fichiers fournis par l’utilisateur dans la racine document.
Pour vous en convaincre, imaginez un utilisateur malveillant téléchargeant un script nocif puis l’exécutant à partir de votre serveur ! Choisissez un dossier en dehors de la racine, du genre /www/zendcore/uploads. Pour plus de protection, ce répertoire doit être en écriture seule pour empêcher que même votre application puisse lire ou exécuter les fichiers qui s’y trouvent.
Pour extraire les fichiers téléchargés, utilisez un script batch non PHP. De plus, veillez à ce que votre application s’oppose à toute tentative d’imbriquer implicitement des requêtes de création de répertoires dans les fichiers téléchargés. Par exemple, votre application devrait détecter et rejeter un nom de fichier tel que hackerslair/mygoodies/file1.
Téléchargez cette ressource
Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
