Vous êtes ici : » Accueil » World Wide Web

World Wide Web

World Wide Web

  • Qu'elle est la différence entre HTTP et HTTPS ?

    L’Hypertext Transfer Protocol (HTTP, protocole de transfert hypertexte) est le protocole fondamental du web et codifie les interactions de base entre les navigateurs et les serveurs web. Le problème posé par le protocole HTTP simple consiste en ce que les données transférées du serveur au navigateur ne sont pas chiffrées, ce qui signifie qu’elles peuvent être visualisées, volées ou modifiées. Les protocoles HTTPS corrigent cela en utilisant un certificat SSL (secure sockets layer, couche de connecteurs sécurisée). La connexion ainsi sécurisée et chiffrée entre le serveur et le navigateur protège les informations sensibles.

  • Comment activer le mode « HTTPS uniquement » dans FireFox ?

    Lorsque vous utilisez le mode « HTTPS uniquement », cela garantit que toutes vos connexions sont chiffrées et sécurisées. Vous avez donc l’esprit tranquille, personne ne peut espionner le contenu des pages que vous visitez, ni pirater votre connexion à un site web pour voler vos mots de passe, les informations de votre carte bancaire ou d’autres informations personnelles. C’est particulièrement utile lorsque vous vous connectez à Internet par un réseau WiFi public dont l’intégrité ne peut pas vous être assurée.

    Par exemple lorsque le mode « HTTPS uniquement » est activé et qu’un site web est visité tel que http://example.com, Firefox surclasse la connexion, sans rien demander, en https://example.com

    Pour activer et désactiver le mode « HTTPS uniquement » suivez le guide ci-dessous:

    1. Cliquez sur le bouton de menu New Fx Menu et sélectionnez Options

    2. Sélectionnez Vie privée et sécurité depuis le menu de gauche.
    3. Descendez jusqu’à la section Mode HTTPS uniquement.
    4. Utilisez le bouton radio pour choisir d’activer ou désactiver le mode « HTTPS uniquement », ou sélectionnez de ne l’activer que pour la navigation privée.
      EnableHTTPSMode
  • Xampp : Le serveur Apache peut subitement s'arrêter, comment éviter le problème ?Toggle Title

    Quand vous utilisez XAMPP, le serveur Apache peut subitement s’arrêter. Voici comment éviter le problème.

    Quand vous utilisez XAMPP, le serveur Apache peut subitement s’arrêter à cause d’un problème alors qu’il était en train de démarrer. Le message Error: Apache shutdown unexpectedly. s’affiche alors sur le panneau de contrôle de XAMPP. La raison la plus courante pour expliquer cette erreur est l’impossibilité pour Apache d’utiliser les ports 80 et/ou 443. Si un autre programme utilise l’un des 2 ports, celui-ci est bloqué, et Apache ne peut pas l’utiliser. Il existe alors 2 solutions : faire en sorte qu’Apache soit le seul programme à utiliser les ports 80 et 443, ou bien configurer le serveur Apache pour qu’il utilise un autre port.

  • Comment définir les autorisations de fichier de mon serveur et les racines de mes documents?

    Pour maximiser la sécurité, vous devez adopter une politique stricte de «besoin de savoir» pour la racine du document (où les documents HTML sont stockés) et la racine du serveur (où les fichiers journaux et de configuration sont conservés). Il est très important d’obtenir les autorisations directement à la racine du serveur, car c’est ici que les scripts CGI et le contenu sensible des fichiers journaux et de configuration sont conservés.

    Vous devez protéger le serveur des regards indiscrets des utilisateurs locaux et distants. La stratégie la plus simple consiste à créer un utilisateur «www» pour l’administration Web/webmaster et un groupe «www» pour tous les utilisateurs de votre système qui ont besoin de créer des documents HTML. Sur les systèmes Unix, modifiez le fichier /etc/passwd pour faire de la racine du serveur le répertoire personnel de l’utilisateur www. Modifiez/etc/ group pour ajouter tous les auteurs au groupe www.

    La racine du serveur doit être configurée de manière à ce que seul l’utilisateur www puisse écrire dans les répertoires de configuration et de journalisation et dans leur contenu. C’est à vous de décider si vous souhaitez que ces répertoires soient également lisibles par le groupe www. Ils ne devraient pas être lisibles dans le monde entier. Le répertoire cgi-bin et son contenu doivent être exécutables et lisibles dans le monde entier, mais pas en écriture (si vous leur faites confiance, vous pouvez donner aux auteurs Web locaux l’autorisation d’écriture pour ce répertoire). Voici les autorisations pour un exemple de racine de serveur:

    drwxr-xr-x 5 www www 1024 8 août 00:01 cgi-bin/
    drwxr-x --- 2 www www 1024 11 juin 17:21 conf/
    -rwx ------ 1 www www 109674 8 mai 23:58 httpd
    drwxrwxr-x 2 www www 1024 8 août 00:01 htdocs/
    drwxrwxr-x 2 www www 1024 3 juin 21:15 icons/
    drwxr-x --- 2 www www 1024 4 mai 22:23 logs/

    La racine du document a des exigences différentes. Tous les fichiers que vous souhaitez diffuser sur Internet doivent être lisibles par le serveur pendant son exécution sous les autorisations de l’utilisateur «personne». Vous souhaiterez également généralement que les auteurs Web locaux puissent ajouter librement des fichiers à la racine du document. Par conséquent, vous devez rendre le répertoire racine du document et ses sous-répertoires appartenant à l’utilisateur et au groupe “ www ”, accessible en lecture universelle et en écriture de groupe:

    drwxrwxr-x 3 www www 1024 1 juillet 03:54 contenu
    drwxrwxr-x 10 www www 1024 23 août 19:32 exemples
    -rw-rw-r-- 1 www www 1488 13 juin 23:30 index.html
    -rw-rw-r-- 1 lstein www 39294 11 juin 23:00 resource_guide.html

    De nombreux serveurs vous permettent de restreindre l’accès à certaines parties de l’arborescence des documents aux navigateurs Internet avec certaines adresses IP ou aux utilisateurs distants qui peuvent fournir un mot de passe correct (voir ci-dessous). Cependant, certains administrateurs Web peuvent s’inquiéter du fait que des utilisateurs _locaux_ non autorisés aient accès aux documents restreints présents dans la racine du document. Il s’agit d’un problème lorsque la racine du document est lisible par tout le monde.

    Une solution à ce problème consiste à exécuter le serveur comme autre chose que «personne», par exemple comme un autre ID utilisateur non privilégié appartenant au groupe «www». Vous pouvez maintenant rendre le groupe de documents restreint – mais pas lisible par tout le monde (ne les rendez pas inscriptibles en groupe à moins que vous ne vouliez que le serveur puisse écraser ses documents!). Les documents peuvent désormais être protégés contre les regards indiscrets à la fois localement et globalement. N’oubliez pas de définir également les autorisations de lecture et d’exécution pour tous les scripts de serveur restreints.

    Le serveur du CERN généralise cette solution en permettant au serveur de s’exécuter sous différents privilèges d’utilisateur et de groupe pour chaque partie d’une arborescence de documents restreinte. Consultez la documentation du CERN pour plus de détails sur la façon de configurer cela.

    Si votre serveur démarre en tant que root mais s’exécute en tant qu’un autre utilisateur, il est particulièrement important que le répertoire des journaux ne soit pas accessible en écriture par l’utilisateur sous lequel le serveur s’exécute. Par exemple, les serveurs Netscape FastTrack et SuiteSpot sont livrés avec le répertoire des journaux accessible en écriture par l’utilisateur sous lequel le serveur s’exécute (c’est-à-dire en tant que ‘personne’ si vous choisissez les valeurs de configuration par défaut). Cela peut rendre l’effet de certains bogues CGI bien pire qu’ils ne le seraient normalement. Par exemple, si un bogue CGI permet à un utilisateur distant d’exécuter des commandes arbitraires sur le serveur, alors l’utilisateur distant peut également obtenir un accès root au serveur en exploitant le bogue pour remplacer un fichier journal par un lien symbolique vers /etc/passwd. Lorsque le serveur redémarre, le lien symbolique entraînera le chown’d de /etc/passwd à l’utilisateur du serveur.

    L’utilisateur distant peut à nouveau exploiter le bogue CGI pour ajouter une entrée à /etc/passwd. La solution de contournement suggérée consiste à modifier la propriété du répertoire des journaux afin qu’il ne soit pas accessible en écriture par l’utilisateur du serveur, puis à créer des fichiers journaux et pid vides appartenant à l’utilisateur du serveur (le serveur ne démarrera pas s’il ne peut pas ouvrez ces fichiers.) Bien que cette solution ne soit pas optimale, car elle permet aux pirates de falsifier les fichiers journaux, elle est bien meilleure que la configuration par défaut. Ce bogue peut également être présent sur d’autres serveurs commerciaux.

  • J'utilise un serveur qui fournit tout un tas de fonctionnalités optionnelles. Y a-t-il des risques pour la sécurité?

    Oui. De nombreuses fonctionnalités qui augmentent la commodité d’utilisation et d’exécution du serveur augmentent également les risques de faille de sécurité. Voici une liste de fonctionnalités potentiellement dangereuses. Si vous n’en avez pas absolument besoin, désactivez-les.

    Listes d’annuaires automatiques

    La connaissance est le pouvoir et plus le pirate à distance peut comprendre votre système, plus il a de chances de trouver des failles. Les listes d’annuaires automatiques proposées par le CERN, le NCSA, Netscape, Apache et d’autres serveurs sont pratiques, mais ont le potentiel de donner au pirate l’accès à des informations sensibles. Ces informations peuvent inclure: des fichiers de sauvegarde Emacs contenant le code source vers des scripts CGI, des journaux de contrôle du code source, des liens symboliques que vous avez créés une fois pour votre commodité et que vous avez oublié de supprimer, des répertoires contenant des fichiers temporaires, etc.

    Bien sûr, la désactivation des listes automatiques de répertoires n’empêche pas les utilisateurs de récupérer les fichiers dont ils devinent les noms. Cela n’évite pas non plus l’écueil d’un programme de recherche automatique de mots-clés de texte qui ajoute par inadvertance le fichier «caché» à son index. Pour être sûr, vous devez supprimer entièrement les fichiers indésirables de la racine de votre document.

    Lien symbolique suivant

    Certains serveurs vous permettent d’étendre l’arborescence des documents avec des liens symboliques. Ceci est pratique, mais peut conduire à des failles de sécurité lorsque quelqu’un crée accidentellement un lien vers une zone sensible du système, par exemple / etc. Un moyen plus sûr d’étendre l’arborescence de répertoires est d’inclure une entrée explicite dans le fichier de configuration du serveur (cela implique une directive PathAlias ​​dans les serveurs de style NCSA et une règle Pass dans le serveur CERN).

    Les serveurs NCSA et Apache vous permettent de désactiver complètement le suivi des liens symboliques. Une autre option vous permet d’activer le suivi de lien symbolique uniquement si le propriétaire du lien correspond au propriétaire de la cible du lien (c’est-à-dire que vous pouvez compromettre la sécurité d’une partie de l’arborescence de documents que vous possédez, mais pas celle de quelqu’un d’autre).

    Le côté serveur comprend

    La forme «exécutable» des inclusions côté serveur constitue une faille de sécurité majeure. Leur utilisation doit être limitée aux utilisateurs de confiance ou complètement désactivée. Dans NCSA httpd et Apache, vous pouvez désactiver la forme exec d’inclusions dans un répertoire en plaçant cette instruction dans la section de contrôle de répertoire appropriée de access.conf:

    Les options incluent: NoExec

    Répertoires gérés par l’utilisateur

    Permettre à tout utilisateur du système hôte d’ajouter des documents à votre site Web est un système merveilleusement démocratique. Cependant, vous devez faire confiance à vos utilisateurs pour ne pas ouvrir de failles de sécurité. Cela peut inclure la publication de fichiers contenant des informations système sensibles, ainsi que la création de scripts CGI, d’inclusions côté serveur ou de liens symboliques qui ouvrent des failles de sécurité. À moins que vous n’ayez vraiment besoin de cette fonctionnalité, il est préférable de la désactiver. Lorsqu’un utilisateur a besoin de créer une page d’accueil, il est probablement préférable de lui donner sa propre partie de la racine du document dans laquelle travailler et de s’assurer qu’il comprend ce qu’il fait. Que les pages d’accueil se trouvent dans les répertoires personnels de l’utilisateur ou dans une partie de la racine du document, il est préférable d’interdire les inclusions côté serveur et les scripts CGI dans cette zone.

  • J'ai entendu dire qu'exécuter le serveur en tant que «root» est une mauvaise idée. Est-ce vrai?

    Cela a été la source de certains malentendus et désaccords sur le Net. La plupart des serveurs sont lancés en tant que root pour pouvoir ouvrir le port 80 (le port HTTP standard) et écrire dans les fichiers journaux. Ils attendent ensuite une connexion entrante sur le port 80. Dès qu’ils reçoivent cette connexion, ils bifurquent un processus enfant pour gérer la demande et se remettent à l’écoute. Le processus enfant, quant à lui, change son ID utilisateur effectif en l’utilisateur «personne», puis procède au traitement de la demande distante. Toutes les actions entreprises en réponse à la demande, telles que l’exécution de scripts CGI ou l’analyse des inclusions côté serveur, sont effectuées en tant qu’utilisateur «personne» sans privilège.

    Ce n’est pas le scénario dont les gens mettent en garde lorsqu’ils parlent de «exécuter le serveur en tant que root». Cet avertissement concerne les serveurs qui ont été configurés pour exécuter leurs _processus enfants_ en tant que root, (par exemple en spécifiant ‘User root’ dans le fichier de configuration du serveur). C’est une énorme faille de sécurité car chaque script CGI qui est lancé avec des autorisations root aura accès à tous les coins et recoins de votre système.

    Certaines personnes diront qu’il vaut mieux ne pas démarrer du tout le serveur en tant que root, avertissant que nous ne savons pas quels bogues peuvent se cacher dans la partie du code du serveur qui contrôle son comportement entre le moment où il démarre et celui où il passe un enfant. C’est tout à fait vrai, bien que le code source de tous les serveurs du domaine public soit librement disponible et qu’il ne semble pas y avoir de bogues dans ces parties du code. L’exécution du serveur en tant qu’utilisateur ordinaire non privilégié peut être plus sûre. De nombreux sites lancent le serveur en tant qu’utilisateur «nobody», «daemon» ou «www». Cependant, vous devez être conscient de deux problèmes potentiels avec cette approche:

    Vous ne pourrez pas ouvrir le port 80 (du moins pas sur les systèmes Unix). Vous devrez dire au serveur d’écouter un autre port, tel que 8000 ou 8080.

    Vous devrez rendre les fichiers de configuration lisibles par le même ID utilisateur sous lequel vous exécutez le serveur. Cela ouvre la possibilité à un script CGI errant de lire les fichiers de configuration du serveur. De même, vous devrez rendre les fichiers journaux à la fois lisibles et inscriptibles par cet ID utilisateur, ce qui permet à un serveur subverti ou à un script CGI de modifier le journal. Voir la discussion sur les autorisations de fichiers ci-dessus.

  • Je souhaite partager la même arborescence de documents entre mes serveurs FTP et Web. Y a-t-il un problème avec cette idée?

    De nombreux sites aiment partager des répertoires entre le démon FTP et le démon Web. C’est OK tant qu’il n’y a aucun moyen pour un utilisateur distant de télécharger des fichiers qui peuvent être lus ou exécutés plus tard par le démon Web.

    Considérez ce scénario: le serveur WWW qui a été configuré pour exécuter tout fichier se terminant par l’extension «.cgi». En utilisant votre démon ftp, un hacker distant télécharge un script perl sur votre site ftp et lui donne l’extension .cgi. Il utilise ensuite son navigateur pour demander le fichier nouvellement téléchargé à partir de votre serveur Web. Bingo! il a dupé votre système en exécutant les commandes de son choix.

    Vous pouvez chevaucher les hiérarchies de serveur ftp et Web, mais assurez-vous de limiter les téléchargements ftp à un répertoire «entrant» qui ne peut pas être lu par l’utilisateur «personne».

  • Puis-je rendre mon site complètement sûr en exécutant le serveur dans un environnement «chroot»?

    Vous ne pouvez pas rendre votre serveur complètement sûr, mais vous pouvez augmenter sa sécurité de manière significative dans un environnement Unix en l’exécutant dans un environnement chroot. La commande système chroot place le serveur dans une «bulle d’argent» de telle sorte qu’il ne puisse voir aucune partie du système de fichiers au-delà d’une arborescence de répertoires que vous lui avez réservée. Le répertoire que vous désignez devient le nouveau répertoire racine «/» du serveur. Tout ce qui se trouve au-dessus de ce répertoire est inaccessible.

    Pour exécuter un serveur dans un environnement chroot, vous devez créer un système de fichiers racine miniature complet contenant tout ce à quoi le serveur a besoin d’accéder. Cela inclut les fichiers de périphérique spéciaux et les bibliothèques partagées. Vous devez également ajuster tous les noms de chemin dans les fichiers de configuration du serveur afin qu’ils soient relatifs au nouveau répertoire racine. Pour démarrer le serveur dans cet environnement, placez autour de lui un script shell qui invoque la commande chroot de cette manière:

    chroot /path/to/new/root /server_root/httpd

    La configuration du nouveau répertoire racine peut être délicate et dépasse le cadre de ce document. Voir le livre de l’auteur (ci-dessus), pour plus de détails. Vous devez être conscient qu’un environnement chroot est plus efficace lorsque le nouveau répertoire racine est aussi stérile que possible. Il ne devrait pas y avoir d’interpréteurs, de shells ou de fichiers de configuration (y compris /etc/passwd!) Dans le nouveau répertoire racine. Malheureusement, cela signifie que les scripts CGI qui reposent sur Perl ou des shells ne fonctionneront pas dans l’environnement chroot. Vous pouvez réintégrer ces interprètes, mais vous perdez certains des avantages du chroot.

    Sachez également que chroot ne protège que les fichiers; ce n’est pas une panacée. Cela n’empêche pas les pirates de s’introduire dans votre système par d’autres moyens, tels que la saisie de cartes système du service d’informations réseau NIS ou la lecture de jeux avec NFS.

  • Mon réseau local fonctionne derrière un pare-feu. Puis-je l'utiliser pour augmenter la sécurité de mon site Web?

    Vous pouvez utiliser un pare-feu pour améliorer la sécurité de votre site de plusieurs manières. L’utilisation la plus simple d’un pare-feu consiste à créer un «site interne», accessible uniquement aux ordinateurs de votre propre réseau local. Si c’est ce que vous voulez faire, il vous suffit de placer le serveur À L’INTÉRIEUR du pare-feu:

    autres hôtes
                 \
    serveur  PARE-FEU  EXTÉRIEUR
                 /
    autres hôtes

    Cependant, si vous souhaitez rendre le serveur disponible pour le reste du monde, vous devrez le placer quelque part en dehors du pare-feu. Du point de vue de la sécurité de votre organisation dans son ensemble, l’endroit le plus sûr pour le placer est complètement en dehors du réseau local:

    autres hôtes
                 \
    autres hôtes  FIREWALL  serveur  EXTÉRIEUR
                 /
    autres hôtes

    C’est ce qu’on appelle une configuration «agneau sacrificiel». Le serveur risque d’être cambriolé, mais au moins quand il y est brisé, il ne viole pas la sécurité du réseau interne.

    Ce n’est pas une bonne idée d’exécuter le serveur WWW sur la machine pare-feu. Désormais, tout bogue sur le serveur compromettra la sécurité de toute l’organisation.

    Il existe un certain nombre de variations sur cette configuration de base, y compris des architectures qui utilisent des serveurs appariés «internes» et «externes» pour donner au monde accès aux informations publiques tout en donnant au réseau interne l’accès aux documents privés. Voir le livre de l’auteur pour les détails sanglants.

  • Mon réseau local fonctionne derrière un pare-feu. Puis-je franchir le pare-feu pour permettre au reste du monde d'accéder au serveur Web?

    Vous pouvez, mais si vous faites cela, vous ouvrez une faille de sécurité dans le pare-feu. Il est de loin préférable de faire du serveur un «agneau sacrificiel» comme décrit ci-dessus. Cependant, certaines architectures de pare-feu ne vous donnent pas la possibilité de placer l’hôte en dehors du pare-feu. Dans ce cas, vous n’avez pas d’autre choix que d’ouvrir un trou dans le pare-feu. Il existe deux options:

    Si vous utilisez un type de pare-feu de type «hôte filtré», vous pouvez autoriser sélectivement le pare-feu à transmettre les demandes pour le port 80 qui sont liées ou reviennent du serveur WWW. Cela a pour effet de percer un petit trou dans la digue à travers lequel le reste du monde peut envoyer et recevoir des requêtes à la machine serveur WWW.

    Si vous utilisez un pare-feu de type «passerelle à double hébergement», vous devrez installer un proxy sur la machine du pare-feu. Un proxy est un petit programme qui peut voir les deux côtés du pare-feu. Les demandes d’informations du serveur Web sont interceptées par le proxy, transmises à la machine serveur et la réponse est renvoyée au demandeur. Un petit proxy HTTP fiable est disponible auprès des systèmes TIS à l’adresse: ftp://ftp.tis.com/pub/firewalls/toolkit/

    Le serveur CERN peut également être configuré pour agir en tant que proxy. Cependant, je me sens beaucoup moins à l’aise de le recommander, car il s’agit d’un logiciel volumineux et complexe qui peut contenir des failles de sécurité inconnues.

  • Comment puis-je détecter si mon site web a été piraté?

    Pour les systèmes Unix, le programme tripwire analyse périodiquement votre système et détecte si des fichiers système ou des programmes ont été modifiés. Il est disponible sur ftp://ftp.cerias.purdue.edu/pub/tools/unix/ids/tripwire/

    Vous devez également vérifier périodiquement vos fichiers journaux d’accès et d’erreurs pour détecter toute activité suspecte. Recherchez les accès impliquant des commandes système telles que ‘rm‘, ‘login‘, ‘/bin/sh‘ et ‘perl‘, ou des lignes extrêmement longues dans les requêtes d’URL (les premières indiquent une tentative de tromper un script CGI en invoquant une commande système ; ce dernier une tentative de saturation de la mémoire tampon d’entrée d’un programme).

    Recherchez également les tentatives infructueuses répétées d’accéder à un document protégé par mot de passe. Celles-ci pourraient être symptomatiques d’une personne essayant de deviner un mot de passe.

  • Translate »