Chaque processus de travail s'exécute comme un Compte du pool d'applications . Il fait ça principalement lorsqu'il démarre et qu'il ne se fait pas passer pour quelqu'un d'autre.
Lorsqu'une demande arrive et que l'authentification anonyme est activée, IIS demande au fil de la demande de se faire passer pour le compte d'utilisateur anonyme (par défaut, IUSR) ou de ne rien faire (si vous avez configuré l'authentification anonyme pour utiliser le compte du pool d'applications).
Supposons qu'il n'y ait rien de très intéressant du point de vue des modules d'application, du routage et des composants bizarres, et que la requête
GET /quelquechose.htm
fait simplement référence à un fichier sur le disque, à l'intérieur de la racine du site web. Pour obtenir autant de travail, si vous voulez être absolument pathologique en matière de permission, vous devriez :
- Créer un dossier sur un lecteur non-Système
- Théoriquement, nous allons supprimer toutes les permissions sur ce dossier et désactiver l'héritage sur ce dossier, donc nous partons des premiers principes. (si vous venez de faire cela dans le GUI des permissions NTFS, ne commit pas le changement jusqu'à ce que vous ayez votre remplacement en place, sinon la vie devient Difficile)
Que voulez-vous ? Eh bien, les permissions de base pour n'importe quel dossier sont les suivantes :
- Administrateurs : Contrôle total
- SYSTÈME : Contrôle total
On peut sans doute réduire cela à d'autres combinaisons, mais les administrateurs et le système peuvent faire n'importe quoi de toute façon, ce qui ne constitue pas une barrière solide.
Si vous ne faites pas partie de l'un de ces groupes, vous devez probablement ajouter votre groupe d'administrateurs Web ThisSite à cette liste.
Pour IIS 7 et les versions ultérieures, vous devez au moins web.config doit être accessible à cet endroit afin que le processus de travail (avant l'impersonnalisation, donc le compte App Pool) puisse établir ce qu'est la configuration.
N'ayant modifié aucune autre valeur par défaut, nous pouvons simplement faire ceci :
Mais c'est un peu imprécis et pourrait permettre à une autre application web de lire le contenu et la configuration du site :
- IIS AppPool \App Nom du pool : Read
Couvre le démarrage de notre processus de travail et la lecture de la configuration. Le fait de définir la lecture à la racine du site a l'heureuse coïncidence de rendre l'ensemble du site en lecture seule, sauf pour les administrateurs ou le système (comme nous l'avons déjà couvert avec les autorisations NTFS). Ainsi, au lieu de chercher à rendre les choses "en lecture seule", vous cherchez plutôt à permettre à certaines personnes seulement d'écrire des choses.
Pour en revenir au sujet des lectures et des anonymes, si le compte Anon est IUSR, nous devrons ajouter
à tout élément ou contenu auquel nous souhaitons que le compte d'utilisateur anonyme ait accès, de manière explicite.
Si le compte Anon est le compte du pool d'applications, c'est réglé car nous l'avons déjà ajouté.
A ce moment-là :
- Une requête arrive pour /quelquechose.htm .
- Si le pool d'applications n'est pas en cours d'exécution, il est démarré à la demande en tant que compte de pool d'applications.
- le fichier web.config est tenté d'être lu à partir de la racine du site (et de tout sous-segment de l'URL).
- Le pool d'applications (fil de travail) usurpe l'identité du RSU (ou ne fait rien selon la configuration de l'authentification anon) lorsque la demande est reçue.
- Le fil de travail tente d'accéder à la ressource demandée
- si elle réussit, elle renvoie le contenu
- en cas d'échec, et si l'authentification HTTP est configurée, il demande des informations d'identification.
- ou échoue simplement si aucune méthode d'authentification n'est sélectionnée.
--
Pour en revenir à votre question, il semble qu'il y ait des hypothèses intégrées qui ne se vérifient pas dans tous les cas. Dans la liste ci-dessus, il semble que vous ayez ce qui ressemble à une décharge de contenu d'application censée être illisible sous la racine du site, mais quelque chose doit avoir le droit d'écrire dessus.
Si c'est pour des informations "sécurisées" qui ne sont jamais demandées via le web :
- ne le placez pas sous la racine du site Web (tout ce qui se trouve sous la racine d'un site Web peut devenir inutilisable à un moment donné en raison d'une mauvaise configuration).
- mettez-le quelque part en dehors de la racine du site
- ne pas autoriser les utilisateurs anonymes à y écrire
Il y a aussi une dll ISAPI ( ? est-ce que c'est ? Qui l'appelle ? Peut-elle être installée ailleurs et script mappée à la place ? "Non" est une réponse légitime) qui pourrait nécessiter des autorisations de lecture du compte App Pool (déjà triées dans la liste ci-dessus) et pourrait nécessiter l'autorisation d'exécution du gestionnaire IIS (note : ce n'est pas la même chose que l'autorisation de lecture et d'exécution NTFS, et vous voulez généralement éviter l'autorisation d'exécution du gestionnaire pour les répertoires Web, car c'est la façon dont les gens parviennent à télécharger et à exécuter du code effrayant sur le serveur Web s'il n'est pas sécurisé).
J'aurais aimé vous donner un guide "facile" pour ce qui précède, mais la meilleure réponse est la suivante : je ne pense pas que vous souhaitiez nécessairement faire ce que vous avez demandé comment faire. Si vous voulez le faire de cette façon, faites-le avec les autorisations NTFS. S'il s'agit d'une application tierce, demandez un guide qui a été écrit pour IIS 7, car le 6 utilise une terminologie surchargée.
