I have a normal Windows Server 2008 installation with II7. Each website has it's own application pool. But there is a security realated problem.
There is no restriction for an asp.net application to write a file into C: or any other directorys.
In IIS 6 before this could happen I would have to set those rights in the windows folder secuity permissions and allow the ASPNET_Usr to do that.
What is the best practice for hosting asp.net applications and not allowing them to write an read files in eg c:?
EDIT
Anonymous Auth. is enabled and the User specified is "ISUR". All other Authentications are disabled. In the application pool I use as Process Identity "Network Service".
I created a new User on the Server (not in the domain) "www.xyz.test" and deleted all his group memberships. Changed the Process identity to this user and made the anonymous authetication use the app pool identity and was still able to write to C:.
Changing the trust level is in my case not an option because we use an 3rd party application
It all depends on what user account your asp.net website is running on. I.e. is it Network Service? As far as I am aware, if I want to be able to write to the web directory then I give my website account write access solely to the directory where I want to save files. The account I use is the one used for Anonymous Authentication.
I.e. I have a website called mycompany.com . I create this user account as part of the domain user group. I add this as the anonymous authentication credentials and give it access to the web root, and also write access tot he nested folder which I want to write too.
The User account would be called mycompany.com so i know that it has a reponsibility solely for permissions related to the web and that particular website.
Sounds like the web site permissions (in IIS) are set to either
- Windows Auth: And you are logging in with someone who has permissions to those folders
or
- Anonymous Auth: And the account that is being used for impersonation has permissions
Best practice would be to make sure the account which is being used to access the site (i.e. if windows auth - your account or if anonymous then the account which is impersonated) does not have permissions on the folders.
You could also raise the trust level to medium, high or full in the machine.config for additional security enforcement policies - however use with caution as it can cause some ASP.NET apps to fail.
Related
I have an IIS6 And II7 servers under my management.
all my application pools are running under a custom account which is a member of the IIS_IUSRS
Some of the websites on the webserver were hacked and malicious asp.net files was uploaded to the server.
Those files were used to act as a medium between the attacker and the OS to execute code
I have noticed that the user under which the application pool was running was able to list all the directories of my server and was actually a part of "Authenticated users" and hence "users" group which by default have permissions to execute files/create folders etc.
The hackers were able, using the application pool credentials, to be authenticated as an authenticated user and since authenticated user is part of the users group they were able to do what they want
you can easily recreate the issue by using process explorer to view a worker process security groups.
My Questions are:
How should I secure correctly my server if I want to run the application pool as custom user and not as the built in identitty pool identity ? ( the reason I need to is because I'm using websitepanel management software )
Is something wrong in my config or is it possible that on every MS server that uses custom user as the identity and has some security flaw in the website, a hacker can cause havoc to the entire server ?
Short version:
For IIS 7.5 web applications with Windows Authentication does the end
user need to have Read file access?
Long version:
I have an intranet ASP.NET web app that uses windows authentication. It's installed at dozens of different companies and normally the authentication works fine: users navigate to the site e.g. http://appserver/MyApp, the app recognizes who they're logged in as and displays pages accordingly. I just installed it at a new client and encountered a problem:
When connecting e.g. to http://appserver/MyApp I'm prompted for windows credentials but after entering them I'm repeatedly prompted. After several re-entering credentials I'm shown a 401 error page saying "401 - Unauthorized: Access is denied due to invalid credentials.". So not only is it not passing through my identity but even when entering the username & password it's still denying access.
Giving Read & Execute permissions to the end users of the app solves this problem, but I don't think this should be necessary at all.
In the windows Application Event Log there's a message "File authorization failed for the request" along with Thread account name: NT AUTHORITY\NETWORK SERVICE and User: [the correct workstation users's domain account]. This suggests that the file access is being performed with the User's identity, not the AppPool identity of Network Service. Sure enough if I grant the end user Read & Execute permission (I didn't try Read only) to the application's directory then everything works correctly: when the user browses to the site they're authenticated automatically, not prompted, and the web site correctly recognizes their identity! Therefore my workaround solution is to give Read & Execute permission to Everybody on the application directory...but this is not an ideal solution.
This seems very strange. I've never needed to do this before in IIS 7.5, so far as I recall, and definitely never needed to in IIS 6 or IIS 7. Is this a new IIS7.5 thing? The documentation says that Impersonation is turned off by default. I added a element to the web.config to be sure, removed file permissions other than Network Service, but the problem remained.
Any thoughts? Is it normal for Windows Authenticated sites on IIS 7.5 for end users to need file permissions on the web server files?
Some relevant details:
Network Service
has Full Control file permissions to the app folder.
When connecting from the server itself I was prompted for credentials
but after entering them i'm authenticated and the application works
correctly including displaying my windows login and connecting and
retrieving data from the db. I later determined that it was prompting
for credentials because http://localhost was in the trusted sites
and therefore not recognised as the Intranet Zone and thus not
passing identity through. I also determined that it was working as
this user identity because it's an admin user who has file
permissions.
The web server is running Windows Server 2008 R2 / IIS
7.5. It didn't have IIS on it until I installed it. I installed the default features as well as Windows Authentication, ASP.NET, and
possibly a couple of other items. A separate WCF app I installed that
uses IIS, anonymous authentication & .net 2.0 is working fine on
that web server.
The app install process is a manual copy of files,
creation of IIS App Pools & web apps, updating connection strings,
etc.
I checked the IE security settings. It was recognizing the
server as in the Intranet zone and had the option 'Automatic logon
only in Intranet zone' selected. Also on Advanced Settings the
'Enable Integrated Windows Authentication' option was checked.
After
installing IIS I ran aspnet_regiis -i for .net 2.0 and
aspnet_regiis -iru for .net 4.0.
Anonymous authentication is
disabled for my app and Windows Authentication enabled.
The app is
running on ASP.NET v4 but there's another app I installed
experiencing the same issue running ASP.NET v2.
The app is running
with Identity = Network Service and in 32-bit mode.
Database
connection string includes Trusted Connection=True and database
permissions are granted to the web server account [domain]\[server]$
e.g. DGM\MyServer$.
In IIS > Authentication > Windows Authentication > Providers the list was Negotiate first then NTLM. I tried reordering so NTLM is first.
In the Windows Security Event Log there
were a series of Microsoft Windows security auditing events: Logon
and Logoff. They indicated that the Logon was successful and was
displaying the User Id of the workstation user. This are from when
I'm connecting from another workstation and receive a 401
Unauthorized after several attempts.
I see someone has had this problem reported here but with no solution. Originally I posted in the ASP and then the IIS forums with no answers so far.
Update:
This msdn article says
When Windows authentication is enabled but impersonation is disabled, ASP.NET performs file access checks in the file authorization module using the credentials that are sent from the browser (my emphasis). Impersonation does not need to be enabled, because the FileAuthorizationModule module ensures that the requesting user is allowed read access or write access to the resource, depending on the request verb (for example, GET or POST) before executing the request. This behavior applies to any requests that enter managed code. In earlier versions of ASP.NET, accessing files based on URIs such as "Default.aspx" triggered the access check. In ASP.NET MVC applications, where access to resources is typically performed using extensionless URLs, this check typically does not apply, because there is not a physical file to check. In that case, the FileAuthorizationModule class falls back to checking access-control lists (ACLs) for the folder.
This does suggest that the end user needs permissions to the files (in the case of .aspx) or the folder (for MVC) ... although still this seems slightly tucked away and non-definitive. This article about App Pools says they're used as the identity for securing resources, which contradicts the idea of needing to grant privileges to end users. Unless the rules are different for App Pools and NETWORK SERVICE, which could be the case but would be surprising.
Are authenticated users allowed to the app folder?
We were also fighting with this issue, and started setting up security groups so we could give our users file level permissions. Then one of our server admins stumbled across a couple of new properties that allow the app to authenticate to the file system under set credentials, and resolved the need for the users to have access. Here is what he came up with…
There are two IIS settings that control this:
Physical Path Credentials Physical Path Credentials Logon type
By default, Physical Path Credentials is set to Application User
(Pass-through authentication). This means that IIS doesn’t do any
impersonation when handling Windows Authentication requests. This can,
however, be set to a specific user (though not, unfortunately, the
application pool identity, which would be ideal). Physical Path
Credentials Logon Type is set by default to Clear-Text. For my testing
I set this to Interactive (though this may not be the correct value).
Possible values are Clear-Text, Batch, Interactive, and Network.
To set this up I did the following:
Created a local account (IIS-AccessUser)
Granted IIS-AccessUser read and execute access to the /home directory of the site.
Added IIS-AccessUser to IIS_IUSRS group (necessary for accessing .NET temporary files)
Set IIS-AccessUser as the Physical Path Credentials
Set Physical Path Credentials Logon Type to Interactive
Doing the above allowed me to log in to the application directly,
without having to allow Authenticated Users, or me having to be a
member of any of the groups in the /home folder. It also still
preserved .NET Authorization roles, so I still could not access parts
of the site that I was not allowed to.
The short answer is NO. You are not required to grant file access permissions when using Windows Authentication in IIS 7.0 and IIS 7.5.
We were only able to discover this because our server admin smelled the security and management issues that arise from taking the route of granting file level access to users and groups.
For anyone dealing with this issue or if you are setting up a new IIS7/IIS7.5 server and/or moving from IIS 6, here is an article that gives you all of the Windows Authentication options and configurations that need to be modified to avoid granting file level access to individuals or groups.
Please read the two comments in at the end of the POST for some valid critiques of the methods used in this article.
http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk
In addition to the information in the article, please be aware that IIS 7.5 is not using the web configuration tags for system.web (at least not in my MVC 4 application).
It is looking in the system.webserver tags for authorization configuration (where you will need to list the windows domain\groups a user needs to be in to access your application).
-- DSB
I am quite confused about this and none of the texts / docs / SO questions have elucidated the matter for me.
I want my asp.net MVC app to be able to save an XML doc to a folder on the server. But I am getting an exception...
Access to the path 'D:\blah\blah\folder\xml_data.xml' is denied.
So as I understand it my application is running under a user account that does not have write permissions.
I think I had this problem before and my solution was to contact my web host and ask them to give my site permissions.
But what if I want to create my own custom set of roles with corressponding permissions? Do these have to be added into IIS? Would I have to create a list and then hand it over the the web host? What would such a list look like? As I understand it, it is not possible to configure roles and permissions in web.config, is that correct?
Once I have the roles and their permissions set up how to I set the default role for the app to run under and also how do I programitically change the role that the app is running under?
ps. I don't want to use asp.net membership I would like to know how to set this up myself.
Use asp.net membership. I don't care if you don't like it. Use it. It's easy, it's simple, and it gets security right. You will mess security up if you do it yourself and don't know what you're doing.
People give membership a bad rap, it's a good tool. Most people just make the wrong assumptions about it.
You define your roles in the membership/role API. This is stored in your database. You can't have roles without a user to apply them to, so you need a membership system of some type.
EDIT:
There are two kinds of users here. The first is the user that the ASP.NET worker process runs as under IIS. This is the user that your host must define, and allow to access various folders to access files.
The second is the IIdentity user of asp.net, this is the user that asp.net defines for the logged in web user, and this is completely seperate from the Worker process user. IIdentity users have no inherent operating system rights or privileges, other than those assigned to the worker process identity.
In other words, IIDentity based users run as the same Worker process identity in IIS.
The exception to this is when you define "impersonate=true" in the web.config, and this allows the worker process to "log on" to the OS as the user in question. In other words, the worker process will run as the web users credentials. This requires that the web user have credentials in the OS as well.
The other exception is that you can specify a specific OS user to impersonate in the web.config. But, again, there must be an operating system user to impersonate. Also, impersonation is a very expensive operation and takes a lot of system resources.
See http://msdn.microsoft.com/en-us/library/aa292118(v=vs.71).aspx
i've always read that the user you set in the IIS website/virtual directory is the user that runs the app (anonymous user identity)
But in the application pool, i can also set a user (process model, identity)
what is the difference between the two, and which one will need access if i do a file read?
EDIT:
the bounty is for this quesyion ' but if i use 'anonymous authentication', is the user i choose in the 'anonymous user identity' ever used? – ' posted as comment
Checkout this post. Quote:
The two accounts are different things.
Think of the website identity
representing the user of the site. If
you create a new website this account
is the anonymous IIS account. If you
disable "Anonymous Authentication",
your users will have to authenticate
against the website (in a
intranet/Windows domain site this
could be implicite using the network
credentials.)
The application pool identity is the
Windows account needed for running
your assemblies. Normally it is the
"Network Service" account which is a
least privileged account with limited
user rights and permissions. It does
have network credentials. This means
that you can use it to authenticate
against network resources in a domain.
You can also use it to access a SQL
Server database with integrated
security.
For example, if your ASP.NET
application has to write to a folder,
you have to grant the permission to
the application pool account, not to
the website account. For more
information on application pool
identities, read here.
Think of the website identity as a rule that defines who can access the site. If you specify an anonymous account to use, that account must have access to the site. If anonymous access is disabled, then the user's credentials must have access to the folder.
The app pool identity defines what the application can do. The app pool's worker process will run using the app pool identity; that account must be granted access to any resources (SQL Server, file shares, etc) that the app will need to access.
To answer your question: yes, the anonymous account is used. Think of the scenario where you're hosting a hundred web sites, and you don't want one customer's files to be able to access another's. You would assign separate anonymous access to each customer. Each site's anonymous account allows IIS to access only the files relevant to that particular site (provided you've configured that account's access correctly).
#Michel
if you have an Anon Access Account setup on your site (virtual dir)
AND you have
<system.web>
<identity impersonate="true" />
</system.web>
in your web.config, this will use that identity.
if you have a part of code where you can set the credentials
CredentialCache.DefaultCredentials
this will point to the Anon Account,if you want to test what user you are using try
Thread.CurrentPrincipal.Identity.Name.ToString()
have a look at this post for more information
http://blogs.iis.net/sakyad/archive/2008/11/19/process-and-thread-identity-in-asp-net-a-practical-approach.aspx
My ASP.NET MVC 2 application runs under built-in local NETWORK SERVICE account. I want to set up access permissions for the folder which resides in another computer, but in the same domain. I located that folder right-clicked to open its properties form, clicked to Security tab and pressed Add button which displayed Add user form with correct domain name in the location field. I referred to the account with following syntax:
<domain name>\<server name>$
because I learned that NETWORK SERVICE account uses machine account when connected to other computers in the domain.
However, the system couldn't find the account, so refuses to add the account. Without the domain name it adds a user, but that user seems to be local user, not web server's NETWORK SERVICE account. What am I doing wrong?
By the way, the above syntax worked when I created login for the sql server which is different computer from the web server.
OK, I will answer my own question. The above syntax \$ was correct. Just make sure to select computers checkbox in the object type, when adding user permissions.
I have been in this same situation before. I don't think I got it to work with the Server/Network Service but this might be worth a try.
Figure out the account network service is using to access the network resource.
Configure windows auditing (on the server the folder is located) to log the failed security events of the folder.
or monitor the folder with something like filemon.exe
.. from here you can try and add the account to the security settings of the forlder. (IIRC I did'nt ever get this to work)
Alternatively you can ensure the action is performed under the context of a domain user. Either by:
Impersonating the user in code and performing the action (my preference)
Setting the impersonation settings in web.config to a named user
setting the application pool to run as a domain user.