Hébergement partagé. C'est l'option bon marché, n'est-ce pas? Et pour une grande partie de la population, c'est tout ce dont ils auront besoin pour héberger leur site Web ou leur application Web. Et lorsqu'il est bien fait, l'hébergement partagé est évolutif, rapide et sécurisé.
Mais que se passe-t-il quand ce n'est pas bien fait?
Eh bien, c'est à ce moment-là que des problèmes de sécurité dangereux commencent à s'introduire. C'est à ce moment-là que votre site risque d'être corrompu ou que les données privées que vous détenez sont divulguées. Mais ne vous inquiétez pas. La grande majorité des hébergeurs ont des mesures de sécurité décentes. Il n'y a que les animateurs à la dérobée, au sous-sol, dont il faut se méfier.
Nous allons explorer les problèmes de sécurité liés à l'hébergement partagé. Mais d'abord, parlons de ce qui rend une plate-forme d'hébergement partagée sécurisée.
Qu'est-ce qu'un hôte Web sécurisé?
Il y a quelques considérations de sécurité qui devraient être faites en ce qui concerne l'hébergement partagé.
- Chaque utilisateur sur le serveur doit être isolé des autres utilisateurs et ne doit pas pouvoir accéder ou modifier les fichiers des autres utilisateurs.
- Une vulnérabilité de sécurité dans la logique d'un site Web hébergé sur le serveur ne devrait pas pouvoir affecter les autres utilisateurs.
- Le serveur est régulièrement corrigé, mis à jour et surveillé pour résoudre les problèmes de sécurité architecturale.
- Chaque utilisateur doit avoir son propre accès à la base de données isolée et ne doit pas être autorisé à apporter des modifications aux enregistrements stockés ou aux autorisations de table des autres utilisateurs.
Encore une fois, la plupart des hébergeurs répondent à ces exigences pour leurs offres partagées. Mais si vous envisagez d'héberger plusieurs sites Web sur un seul serveur, ou si vous êtes curieux de voir comment votre société d'hébergement se loge, ou même si vous envisagez de lancer votre propre société d'hébergement et êtes impatient de savoir comment sécuriser vos utilisateurs, lisez sur.
Mais d'abord, un avertissement
Avant d'aborder la question des attaques communes à un hébergement partagé, je tiens à préciser que ce post ne sera pas (et ne devrait pas être lu comme) une liste exhaustive des problèmes de sécurité potentiels.
La sécurité est, en un mot, grande. Il y a beaucoup de façons de compromettre un site. Cela va double pour l'hébergement partagé. Les couvrir dans un seul article n'était jamais sur les cartes.
Si vous êtes paranoïaque à propos de votre sécurité, procurez-vous un serveur VPS ou dédié. Ce sont des environnements dans lesquels vous avez (pour la plupart) un contrôle absolu sur ce qui se passe. Si vous n'êtes pas sûr sur les différents types d'hébergement Web, consultez ce post Les différentes formes d'hébergement Web expliqué [Explication de la technologie] Les différentes formes d'hébergement Web expliqué [Explication de la technologie] Lire la suite de mon collègue, James Bruce.
Je tiens également à souligner que ce message ne doit pas être interprété comme une attaque contre l'hébergement partagé. Au contraire, c'est un regard purement académique sur les questions de sécurité entourant cette catégorie d'hébergement Web.
Traversée du répertoire
Commençons par la traversée de répertoire (souvent appelée attaque par chemin). Ce type d'attaque vous permet d'accéder aux fichiers et répertoires stockés en dehors de la racine Web.
En anglais clair? Eh bien, imaginons qu'Alice et Bob utilisent le même serveur pour héberger leurs sites Web. Les fichiers d'Alice sont stockés dans / var / www / alice, tandis que les documents de Bob peuvent être trouvés dans / var / www / bob. En outre, supposons qu'il existe un autre dossier sur le serveur (/ usr / crappyhosting / myfolder) qui contient un fichier texte non crypté (que nous appellerons pwd.txt) contenant les noms d'utilisateur et les mots de passe du système.
Avec moi jusqu'ici? Bien. Maintenant, imaginons que le site Web de Bob traite les fichiers PDF qui sont générés localement, et le fichier local est référencé dans l'URL. Quelque chose comme:
http://example.com/file?=report.pdf
Que se passerait-il si je remplaçais 'report.pdf' par les paramètres UNIX qui modifient le répertoire?
http://example.com/file?=../alice/
Si le serveur est mal configuré, cela vous permettra de voir la racine du document d'Alice. Intéressant, mais nous sommes beaucoup plus intéressés par ce dossier de passeports juteux. Mots de passe Accio !
http://example.com/file?=../../../usr/crappyhosting/myfolder/pwd.txt
C'est vraiment aussi simple que ça. Mais comment pouvons-nous y faire face? C'est facile.
Jamais entendu parler d'un utilitaire Linux peu connu appelé chroot ? Vous avez probablement déjà deviné ce qu'il fait. Il définit la racine Linux / UNIX sur un dossier arbitraire, ce qui empêche les utilisateurs de le quitter. En effet, il arrête les attaques de traversée de répertoire dans leurs pistes.
Il est difficile de dire si votre hôte a cela en place sans enfreindre la loi. Après tout, pour le tester, vous accéderiez aux systèmes et aux fichiers auxquels vous n'avez pas accès. Dans cet esprit, peut-être il serait judicieux de parler à votre hébergeur et se renseigner sur la façon dont ils isolent leurs utilisateurs les uns des autres.
Utilisez-vous votre propre serveur d'hébergement partagé et n'utilisez pas chroot pour protéger vos utilisateurs? Certes, chrooter vos environnements peut être difficile. Heureusement, il existe une multitude de plugins qui rendent cela facile. Jetez un oeil à mod_chroot, en particulier.
Injection de commande
Revenons à Alice et Bob. Donc, nous savons que l'application web de Bob a quelques ... Ahem ... Des problèmes de sécurité. L'un d'entre eux est la vulnérabilité d'injection de commande, qui vous permet d'exécuter des commandes système arbitraires. Guide rapide pour démarrer avec la ligne de commande Linux Un guide rapide pour démarrer avec la ligne de commande Linux Vous pouvez faire beaucoup de choses avec des commandes sous Linux et ce n'est vraiment pas difficile à apprendre. Lire la suite .
Le site Web de Bob vous permet d'exécuter une requête whois sur un autre site Web qui est ensuite affiché dans le navigateur. Il existe une zone de saisie HTML standard qui accepte un nom de domaine, puis exécute la commande système whois. Cette commande est exécutée en appelant la commande PHP system ().
Que se passerait-il si quelqu'un entrait la valeur suivante?
example.com && cd ../alice/ && rm index.html
Eh bien, nous allons le décomposer. Cela peut vous être familier si vous avez lu notre Guide de mise en route de Linux Guide de démarrage de Linux Pour Linux Guide de démarrage pour débutants sous Linux! Vous avez probablement entendu parler de Linux, le système d'exploitation gratuit et open-source qui a poussé contre Microsoft. Lisez plus de e-book, que nous avons déjà publié en 2010, ou jetez un coup d'œil sur notre feuille de triche Linux Command Line.
Premièrement, il va exécuter une requête whois sur example.com. Ensuite, cela changerait le répertoire de travail actuel en racine de document d'Alice. Ensuite, il supprimerait le fichier appelé "index.html" qui est la page d'index sur son site Web. Ce n'est pas bon. Non monsieur.
Donc, en tant qu'administrateurs système, comment pouvons-nous atténuer cela? Eh bien, en revenant à l'exemple précédent, nous pouvons toujours mettre chaque utilisateur dans son propre environnement chrooté, isolé et aseptisé.
Nous pouvons également aborder cela à partir d'un niveau de langue. Il est possible (bien que cela puisse casser des choses) de supprimer globalement les déclarations de fonction des langues. C'est-à-dire qu'il est possible de supprimer des fonctionnalités des langues auxquelles les utilisateurs ont accès.
En regardant PHP en particulier, vous pouvez supprimer des fonctionnalités avec Runkit - la boîte à outils officielle de PHP pour modifier la fonctionnalité du langage. Il y a beaucoup de documentation là-bas. Lisez dedans.
Vous pouvez également modifier le fichier de configuration de PHP (php.ini) pour désactiver les fonctions qui sont souvent utilisées abusivement par les pirates. Pour ce faire, ouvrez un terminal sur votre serveur et ouvrez votre fichier php.ini dans un éditeur de texte. J'aime utiliser VIM, mais NANO est également acceptable.
Recherchez la ligne commençant par disable_functions et ajoutez les définitions de fonctions que vous souhaitez interdire. Dans ce cas, il s'agirait de exec, shell_exec et system, bien qu'il soit à noter qu'il existe d'autres fonctions intégrées exploitables par les pirates.
disable_functions = exec, shell_exec, système
Attaques basées sur le langage et l'interprète
Alors, regardons PHP. C'est la langue qui alimente un nombre impressionnant de sites Web. Il vient aussi avec un certain nombre d'idiosyncrasies et de comportements étranges. Comme ça.
PHP est généralement utilisé en conjonction avec le serveur web Apache. Pour la plupart, il est impossible de charger plusieurs versions du langage avec cette configuration.
Pourquoi c'est un problème? Eh bien, imaginons que l'application web de Bob a été construite en 2002. C'est il y a longtemps. C'est à l'époque où Michelle Branch était toujours en tête des charts, Michael Jordan jouait toujours pour les Washington Wizards et PHP était une langue très différente.
Mais le site de Bob fonctionne toujours! Il utilise tout un tas de fonctions PHP abandonnées et obsolètes, mais cela fonctionne! L'utilisation d'une version moderne de PHP serait effectivement briser le site Web de Bob, et pourquoi Bob devrait réécrire son site Web pour répondre aux caprices de son hébergeur?
Cela devrait vous donner une idée du dilemme auquel font face certains hébergeurs. Ils doivent trouver l'équilibre en gardant un service architectural sûr et sécurisé, tout en gardant cela en harmonie avec le fait de s'assurer que les clients payants sont heureux.
Par conséquent, il n'est pas rare de voir des hôtes plus petits et indépendants utiliser des versions plus anciennes de l'interpréteur PHP (ou n'importe quel langage, d'ailleurs).
Il n'est pas rare de voir des hôtes plus petits et indépendants utiliser des versions plus anciennes de PHP, exposant potentiellement les utilisateurs à des risques de sécurité.
Pourquoi est-ce une mauvaise chose? Eh bien, premièrement, cela exposerait les utilisateurs à un certain nombre de risques de sécurité. Comme la plupart des progiciels majeurs, PHP est constamment mis à jour pour répondre à la multitude de failles de sécurité qui sont constamment découvertes (et divulguées).
En outre, cela signifie que les utilisateurs ne peuvent pas utiliser les dernières (et les plus grandes) langues. Cela signifie également que les fonctions qui ont été dépréciées pour une raison restent. Dans le cas du langage de programmation PHP, cela inclut les fonctions mysql_ terriblement horribles (et récemment obsolètes) qui sont utilisées pour interagir avec le système de base de données relationnelle MySQL, et dl (), qui permet aux utilisateurs d'importer leurs propres extensions.
En tant qu'utilisateur, vous devriez être en mesure de voir quelle version d'un interpréteur est en cours d'exécution sur votre service. Si elle est obsolète ou contient un certain nombre de failles de sécurité, contactez votre hôte.
Qu'en est-il des administrateurs système? Vous avez quelques options ici. Le premier (et le plus prometteur) consiste à utiliser Docker pour chacun de vos utilisateurs. Docker vous permet d'exécuter simultanément plusieurs environnements isolés, comme le fait une machine virtuelle, sans avoir à exécuter un autre système d'exploitation. En conséquence, c'est rapide. Vraiment, très vite.
En anglais clair? Vous pouvez utiliser le plus récent et le plus grand interpréteur de pointe pour la majorité de vos utilisateurs, tandis que les clients qui utilisent d'anciennes applications qui utilisent des interpréteurs obsolètes et obsolètes le font sans compromettre les autres utilisateurs.
Cela a aussi l'avantage d'être agnostique. PHP, Python, Ruby. Peu importe. C'est tout pareil.
Ne fais pas de cauchemars.
Ce poste était destiné à faire quelques choses. Tout d'abord, il s'agissait de porter à votre attention le nombre de problèmes de sécurité auxquels les hébergeurs doivent faire face pour assurer la sécurité de leurs clients et de leurs données.
Il était également destiné à vous montrer comment les sites hébergés sur le même serveur peuvent s'influencer mutuellement. Voulez-vous mettre un frein à cela? Commencez à obéir à de bonnes normes de codage sécurisées. En particulier, commencez à désinfecter vos entrées à l'avant et à l'arrière.
Un bon début est avec la nouvelle fonctionnalité de validation de formulaire HTML5. Nous en avons déjà parlé dans notre guide HTML5. Collectivement, nous pouvons rendre les sites Web plus sûrs en étant de meilleurs programmeurs, plus consciencieux.
Comme toujours, je suis prêt à entendre vos pensées. Déposez-moi un commentaire ci-dessous.
Crédit photo: Tout le monde a besoin d'un pirate (Alexandre Dulaunoy), d'un autocollant sur une vitrine de taxi (Cory Doctorow), d'une salle de serveur (Torkild Retvedt), de livres et magazines Linux (library_mistress), d'éléphant PHP (Markus Tacker)