C'est une erreur de sécurité gravissime que de permettre l'écriture dans le dossier C:\inetpub\wwwroot\.... à un utilisateur connecté à IIS.
Ce n'est pas pour rien que cela est fermé par défaut.
Un utilisateur pourrait, par exemple y uploader un fichier aspx avec du code exécutable, puis appeler cette page avec son navigateur, ce qui, via C#, va s'exécuter en donnant accès à toute la machine.
Dans votre exemple, une fois déployé, il suffira d'appeler
www.mon_site.com/Documents/docs/le_aspx_que_je_viens_d_uploader.aspx
pour exécuter n'importe quel code C# ou VB à même le serveur.
Certes, on peut se protéger de CE scénario, mais il en existe tout un tas et la moindre faille, ou oubli dans un test, donnera des droits important à n'importe quel utilisateur distant.
Le plus simple et que wwwroot reste read-only
On défini un chemin ailleurs sur la machine (paramétré dans web.config) ou vont être écrit et lu les fichiers utilisateurs.
Généralement cela oblige à un index en base de données.
Tous les accès se font ainsi à travers notre code qui est le seul à savoir où se trouve les fichiers.
Ainsi, les fichiers n'ont pas d'URL d'accès direct et ne peuvent pas être appelé directement depuis un navigateur, ce qui protège de l'exécution d'un document 'actif'.
Pour accéder à un fichier uploadé, cela se fait à travers une page du type :
www.monsite.com/mes_documents.aspx?doc_id=12345
qui va va lire le fichier et renvoyer le flux et le type mime correspondant dans la réponse.
Ainsi, quels que soient leurs types, les fichiers ne sont jamais que des flux d'octets et rien d'autres.
Mais si tenez à faire une bêtise il faut effectivement donner des droits à des comptes comme IUSR, IIS_IUSRS, LOCAL SERVICE ou NETWORK SERVICE.
Mais j'insiste : c'est une très mauvaise idée.
(IUSR_machine_name n'existe plus sur les versions récente d'IIS)
Partager