Quels sont les effets sur la sécurité de l'autorisation IIS_IUSRS d'un contrôle total?
Quels sont les effets sur la sécurité de l'octroi à IIS_IUSRS d'une autorisation de contrôle total sur le dossier racine des sites Web ASP.NET?
Pourquoi ne puis-je pas accorder le contrôle total à IUSR uniquement, qui fait partie du groupe IIS_IUSER?
Toute réponse clarifie ce conflit, est vraiment appréciée.
Il est facile de confondre IUSR et IIS_IUSRS en raison de leurs noms, mais ce sont deux choses différentes:
- IIS_IUSRS est le groupe pour IIS Worker Process Accounts. Cela signifie l'identité sous laquelle le pool d'applications s'exécute.
- IUSR est l'identité de l'utilisateur anonyme. Cela signifie que l'identité IIS croit être l'utilisateur qui accède au site. Cet utilisateur n'est pas membre du groupe IIS_IUSRS par défaut.
Dans IIS 7.0, un compte intégré (IUSR) remplace le compte IUSR_MachineName. En outre, un groupe nommé IIS_IUSRS remplace le groupe IIS_WPG. [...] Le compte IUSR ressemble à un réseau ou compte de service local. Le compte IUSR_MachineName est créé et utilisé uniquement lorsque le serveur FTP 6 inclus sur le DVD de Windows Server 2008 est installé. Si le serveur FTP 6 n'est pas installé, le compte n'est pas créé. http : //support.Microsoft.com/kb/981949
IIS_IUSRS est un groupe intégré qui a accès à toutes les ressources de fichiers et système nécessaires pour qu'un compte, lorsqu'il est ajouté à ce groupe, puisse agir en toute transparence comme identité de pool d'applications.
Lire thread similaire qui explique pourquoi donner un accès à IIS_IUSRS a un effet différent que donner le même accès à IUSR:
Ici est une bonne documentation sur les groupes et les utilisateurs utilisés dans IIS 7.
Par défaut, IIS_IUSRS n'a que les autorisations de lecture et d'exécution (et en tant que contenu du dossier de liste de résultats) sur wwwroot. Le contrôle total pourrait être trop.
Imaginez un site Web qui permet aux utilisateurs de télécharger des fichiers arbitraires, qui a un bogue qui provoque l'enregistrement de ces fichiers dans le répertoire de l'application.
Dans ce cas, un attaquant peut télécharger un fichier aspx avec du code arbitraire, écraser votre fichier web.config, etc.
Il est préférable de donner un accès en lecture seule au dossier racine et de ne donner le contrôle total qu'aux dossiers spécifiques dont vous savez qu'ils ne contiendront pas de code exécutable, par exemple les sous-dossiers d'App_Data.