CODEWITHSUNDEEP
asp.netasp.net-mvcsecurityiis
Alaa Alweish
Alaa Alweish

Reputation: 9084

What are the security effects of giving the IIS_IUSRS a Full Control permission?

What are the the security effects of giving the IIS_IUSRS a Full Control permission on the root folder of ASP.NET websites?

Why can't I give the full control permission to IUSR only, which is part of IIS_IUSER group?

Any answer clarifies this conflict, is really appreciated.

Upvotes: 27

Views: 34752

Answers (2)

user2316116
user2316116

Reputation: 6814

It is easy to confuse IUSR and IIS_IUSRS because of their names but these are two different things:

  1. IIS_IUSRS is the group for IIS Worker Process Accounts. This means the identity that the application pool itself runs under.
  2. IUSR is the anonymous user identity. That means the identity that IIS believes to be the user who is accessing the site. This user is not a member of the IIS_IUSRS group by default.

In IIS 7.0, a built-in account (IUSR) replaces the IUSR_MachineName account. Additionally, a group that is named IIS_IUSRS replaces the IIS_WPG group. [...] The IUSR account resembles a network or local service account. The IUSR_MachineName account is created and used only when the FTP 6 server that is included on the Windows Server 2008 DVD is installed. If the FTP 6 server is not installed, the account is not created. http://support.microsoft.com/kb/981949

IIS_IUSRS is a built-in group has access to all the necessary file and system resources so that an account, when added to this group, can seamlessly act as an application pool identity.

Read similar thread which explains why giving an access to IIS_IUSRS has different effect than giving same access to IUSR:

Here is a good documentation about groups and users used in IIS 7.

By default, IIS_IUSRS has only read & execute (and as a result list folder contents) permissions on the wwwroot. The full control might be too much.

Upvotes: 22

to StackOverflow
to StackOverflow

Reputation: 124746

Imagine a website that allows users to upload arbitrary files, that has a bug which causes such files to be saved in the application directory.

In this case, an attacker can upload an aspx file with arbitrary code, overwrite your web.config file, etc.

Far better to give readonly access to the root folder, and only give full control to specific folders that you know won't contain executable code, for example subfolders of App_Data.

Upvotes: 12

Related Questions