Welcome to weblogs.com.pk Sign in | Join | Help

Security Concerns for Administrators Hosting Asp.Net Applications

Generally, in production, there are multiple Asp.Net applications running on a single machine. (ISP environment) The administrators usually create separate windows accounts for each application, set them as the web application’s anonymous users and set the file system ACLs accordingly.

 

Asp.Net has a worker process that runs under ASPNET user (created by .NET installation). IIS forwards the Asp.Net requests to this and it processes them and hand the response back to IIS. During the processing there can be a need that an external DLL needs to be executed (might have referenced in the application code) or other files are required to be read (for example web.config) For this reason the ASPNET user needs read/execute permission on the web application roots.

 

Asp.Net worker process also needs a temporary folder (usually Asp.Net Temporary Files under Microsoft.Net folder) and when Aspx/Ascx/Asmx etc are compiled, it stores the compiled code in the temporary folder and uses the same compiled code for the next execution (if the source files are not changed)

 

There are few problems in this scenario, firstly, if there is some smart coder, he can read the other application’s compiled code from the temporary folder and as .NET compiled code is an intermediate language and can easily be decompile, he may read the other application’s code, specially hard coded strings (connection strings for instance)

 

To solve this issue, one can direct Asp.Net worker process using web.config to store the compiled code in the subfolder of the application root. For this the administrators needs to give ASPNET user full access to web application root. This solution seems workable, but here comes the second problem. .NET has an InterOp support, using which anyone can execute native code already available on the host. There is a function called, RevertToSelf() using which any application code can revert the current principle of the thread that’s processing the request.

 

For instance if a given web application has anonymous user USERA. All the anonymous requests being served by IIS are under USERA impersonation. Calling RevertToSelf() will result ASPNET as the current principle, as Asp.Net worker process is running under this account. And as ASPNET user has access to other web application root folder, one can easily read (or write) data from other folders.

 

In case you need more in depth information, either post the request in the comment, or visit OWASP.Net page. OWASP.NET is a subproject of the Open Web Application Security Project and has details about Asp.Net security issues.

Published Monday, May 17, 2004 4:47 PM by khurram

Comments

No Comments

New Comments to this post are disabled