best way to secure asp 3.0 site's folder - asp.net

I have requested to fix login problem on the classic asp site.
Configuration is 2008 server and IIS 7.0
I've found that admin directory of the site has basic authentication, however there is no any NT Accounts for requested loginName.
I don't want to create any Windows account for this site and I know that basic auth is insecure (Site doesn't use ssl).
What is the best way to solve this problem? Is it possible to use asp.net security for asp 3.0 site?

You should use SSL.
Without SSL, ASP.Net WebForms auth is no better than Basic HTTP Auth.
To answer the question, yes; you can set it up in IIS admin.

I think that it is better to use WebForms auth in any case.
It is easier then I thought. I just added login.aspx page and config file to classic asp site and authentication is working.
Just one notice that by default htm and asp pages don't process by asp.net.
It is required to add following node in config.
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
And I've found that authorization nodes must be in webserver node in IIS7.
Here is full config in case it will be useful for someone.
<configuration>
<location path="admin">
<system.webServer>
<security>
<authorization>
<add accessType="Deny" users="?" />
</authorization>
</security>
</system.webServer>
</location>
<system.web>
<authentication mode="Forms">
<forms loginUrl="login.aspx">
</forms>
</authentication>
</system.web>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
</configuration>

Related

What is the scope of system.webServer and system.web settings in a web.config file stored in a web application's folder in IIS?

I've added an Application in IIS Manager beneath the Default Web Server. I want to confirm that the system.webServer and system.web settings in the application's web.config are scoped to the application and have no effect on the settings of the Default Web Server or on other applications. Is that correct?
For example, if windowsAuthentication is enabled for this particular application, that setting will affect this application and only this application:
<system.web>
<authentication mode="Windows" />
<authorization>
<allow roles="myDomain\mySecurityGroup" />
<deny users="?" />
</authorization>
</system.web>
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
Yes, you are right, only does this application, it also contains the application located in the virtual directory of the website.
Besides, the system.web section is for configuring IIS6.0 and the system.webserver is used to configure IIS7.
Check these links for more details.
Difference between <system.web> and <system.webServer>?
http://arcware.net/use-a-single-web-config-for-iis6-and-iis7/
Feel free to let me know if there is anything I can help with.

Url Authorization with MVC and ASP.NET Identity

I want to secure specific folders and resources in my application that are outside of the routes for my mvc application. I want these resources to only be available to authenticated users (which role is not of concequence as long as they are authenticated).
Initially it seemed that the UrlAuthorizationModule would be the answer. I followed this article, Understanding IIS 7.0 URL Authorization, and I can get the module to work in the sense that it responds to the configuration elements in the web.config.
My current problem is that I think it is enacting the rules based on the anonymous user in IIS and not the authenticated user in asp.net identity.
Test Environment
I use a standard html file for testing instead of trying to load a script as this would also be loaded outside of the MVC pipeline.
In Visual Studio 2015.
New default .net 4.6.2 web project
MVC template
Authentication = Individual User Accounts
IIS 8 (for testing outside Visual Studio)
Authentication -> Anonymous Authentication (enabled)
Add to web.config
<configuration>
...
<location path="Data">
<system.webServer>
<security>
<authorization>
<clear/>
<add accessType="Deny" users="*"/>
<add accessType="Allow" users="?"/>
</authorization>
</security>
</system.webServer>
</location>
...
</configuration>
Add to folder structure
/Data/Protected.html // this file just has some basic Hello World content to display so you can see if it is loaded or not.
Observed Results
With this configuration everything in the Data path is always denied, it does not matter if the user is authenticated or not.
The same is true if I switch the 2 lines for Deny and Allow in the web.config.
If I completely remove the line with Deny then access is always allowed even when the user is not authenticated.
If I add a role and use roles with the role name instead of users attribute the role is also completely ignored.
Now What?
What am I missing? How can I get the Url Authorization module to work with MVC/WebAPI and ASP.NET Identity Individual user accounts or is this simply not doable?
I am open to alternative ideas as well, maybe the answer is to write a custom HttpModule or HttpHandler?
Side notes
Why & Specifics
These resources are javascript files, in short only a portion of the scripts should be available to unauthenticated users. There are 2 directories in the root, one for the authenticated part of the app and one for the non-authenticated part of the app. The reason for this has nothing to do with user authorization or security in the application, it is to limit the exposed surface area of the application to non-authenticated requests.
[TL;DR;]
Go to "Complete root web.config" section to see the needed web.config setup.
Test this in incognito-mode to prevent browser caching issues!
And use Ctrl+F5 because scripts and html files get cached.
First deny access to all anonymous users in the root web.config.
<authorization>
<deny users="?"/>
</authorization>
The web.config here allows one folder to be publicly accessible. This folder, in my example here, is called css and sits in the root of the MVC application. For the css folder I add the following authorization to the root web.config:
<location path="css">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
You can add more of these location paths if you want more public folders.
While all other files will not be accessible until the user logs in, the css folder and its contents will always be accessible.
I have also added a static file handler to the root web.config, This is critical as you want the request to be managed by the asp.net pipeline for the specific file type(s):
<handlers>
<add name="HtmlScriptHandler" path="*.html" verb="*" preCondition="integratedMode" type="System.Web.StaticFileHandler" />
</handlers>
Complete root web.config
<system.web>
<authentication mode="None" />
<authorization>
<deny users="?"/>
</authorization>
<compilation debug="true" targetFramework="4.6.2" />
<httpRuntime targetFramework="4.6.2" />
</system.web>
<location path="css">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
<system.webServer>
<modules>
<remove name="FormsAuthentication" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
</modules>
<handlers>
<add name="HtmlScriptHandler" path="*.html" verb="*" preCondition="integratedMode" type="System.Web.StaticFileHandler" />
</handlers>
</system.webServer>
ASP.NET by default will only apply the allow and deny rules to files handled by the managed handler. Static files are not managed by the managed handler.
You could also set: (Don't do this, if not really needed!)
<modules runAllManagedModulesForAllRequests="true">
With runAllManagedModulesForAllRequests="true" all the HTTP modules will run on every request, not just managed requests (e.g. .aspx, ashx). This means modules will run on every .jpg ,.gif ,.css ,.html, .pdf, ... request.
One important thing
You don't have to add the UrlAuthorizationModule to the modules section as it is already part of the ASP.NET pipeline. This means, it will run only for managed files, not static!
If you now remove and then re-add the UrlAuthorizationModule to the modules section, it will run under precondition "integratedMode" and not under "managedHandler" anymore! And will therefore have access to static files.
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
If you set the precondition to managed:
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="managedHandler" />, then the UrlAuthorizationModule will not restrict access to static files anymore.
You can test this by accessing a script file in the scripts folder successfully while being logged out. Hit Ctrl+F5 to make sure you get a fresh copy of the script file.
Difference between ASP.NET UrlAuthorization <--> IIS URL Authorization
It is important to keep in mind that the managedHandler precondition
is on the ASP.NET UrlAuthorization module. The precondition tells you
that the URL authorization module is invoked only when the code that
handles the request is mapped to managed code, typically an .aspx or
.asmx page. IIS URL Authorization, on the other hand, applies to all
content. You can remove the managedHandler precondition from the
ASP.NET Url Authorization module. It is there to prevent a performance
penality you have to pay when every request (such as a request to
.html or .jpg pages) would have to go through managed code.
P.S.: Some web.config attributes are case sensitive!

ASP.Net 4 Forms Authentication in IIS 7.5 - Default Document No Longer Working

I've recently migrated a web app from .Net 3.5 to .Net 4 and changed the app pool to Integrated mode in IIS 7.5. This app has 2 parts: the first is open to the public and the second is by login only. I use forms authentication for login which is configued thusly in the root web.config:
<authentication mode="Forms">
<forms loginUrl="~/private/login.aspx" protection="All" timeout="20" name=".ASPXAUTH" path="/" requireSSL="false" slidingExpiration="true" defaultUrl="~/private/default.aspx" cookieless="UseCookies" enableCrossAppRedirects="true" />
</authentication>
In the root web.config I have the default authorization to to deny unauthenticated users, thusly:
<authorization>
<deny users="?" />
</authorization>
BUT I have the setting below configured in the root web.config to allow everyone to see the welcome page:
<location path="Default.aspx">
<system.web>
<authorization>
<allow users="?,*" />
</authorization>
</system.web>
This has been working great for years but now, if I don't explicily put Default.aspx in the URL, the forms redirect module causes the login page to be served. I've verified that I have my default pages configured correctly and they are enabled in IIS7. I have also tried specifying them in web.config. I have verified that the DefaultDocumentModule is sequenced before the DirectoryListing module.
If I remove the element the problems "goes away" but the effect would be to default to allow all users and this is completely undesireable.
I'm out of ideas. Suggestions?
Thanks
I
Seems like some kind of default doc issue. If you look in IIS Manager at the site, what is in the "Default Document" list. Is it possible that something other than Default.aspx is higher in the list? If something matching this is found in your root web, it will attempt to go there first and thus be redirected to login.
Are you explicitly setting the default document in your web.config? as in:
<defaultDocument enabled="true">
<files>
<clear />
<add value="Default.aspx" />
<add value="Default.htm" />
<add value="index.htm" />
<add value="index.html" />
<add value="iisstart.htm" />
</files>
</defaultDocument>
OK, I had a Microsoft Premier Support Engineer dig into this for me. We sat down together at my workstation and went through (a) the environment and app configuration and (b) possible solutions.
He referenced this MS "Fast Publish" article which suggests that I remove the ExtensionLessURL handlers from IIS via MMC. Well, we're a huge organization with servers out the wazoo and I could not guarantee that this change would always be honored so I didn't want to do that. We tried using web.config to remove them but that did not work.
So, I showed him this solution from another StackOverflow thread (posted by Dmitry.Alk) and he said it was a good work-around for now. It works great for this particular situation.
The Fast Publish article references this hotfix A update is available that enables certain IIS 7.0 or IIS 7.5 handlers to handle requests whose URLs do not end with a period which I've got to sell to our IT "department".
I don't call what I've written here an "answer" but I wanted to share what I've come to learn in case others happen upon this thread.

The system.webServer/security/authorization in my IIS 7 web.config is not working

In the root of my Admin folder, I have the following in my web.config:
<system.webServer>
<security>
<authorization>
<remove users="*" roles="" verbs="" />
<add accessType="Allow" users="" roles="Admin" />
</authorization>
</security>
</system.webServer>
This is almost verbatim from IIS documentation, but I changed the role to be "Admin" instead of "Administrators",because that's the role in my app.
I have ensured that the ASP.NET UrlAuthorization module is not running via a <remove name="UrlAuthorization" /> in the modules element of my root web.config. I just installed IIS7 UrlAuthorization, so I know it is running.
The problem is that even though I explicitly allow the Admin role and have validated my Admin user is logged in, the Admin gets an unauthorized error. What am I misunderstanding?
Note, since I started writing this questions, I resolved the issue my explicitly enumerating every disallowed role and removing the remove users="*", but I don't know why it worked.
It doesn't look like there's going to be an answer to this. But in case anyone else runs across the same issue, I ended up having to change my approach and manage security externally from the ASP.NET pipeline.

Authorize a directory for anonymous users IIS 7.5?

I'm trying to add a directory for anon access in IIS 7.5. It works under Web Dev but not IIS 7.5
I'm currently using this web.config in the directory. This is a directory with style sheets:
<?xml version="1.0"?>
<!--
Note: As an alternative to hand editing this file you can use the
web admin tool to configure settings for your application. Use
the Website->Asp.Net Configuration option in Visual Studio.
A full list of settings and comments can be found in
machine.config.comments usually located in
\Windows\Microsoft.Net\Framework\v2.x\Config
-->
<configuration>
<appSettings/>
<connectionStrings/>
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</configuration>
Update:
I've went to the folder and under Authentication, I've changed anonymous authentication from IIS_USR to pool. This seems to have correct it.
I will reward anyone who provides a very good explanation and resources for understanding this setting. Also, how to apply it globally would be good to know -- for all folders.
Since you answered your own question, here is the explanation that might help
Authorization deals with who IIS will offer resources to. Those resources, however, have their own security as they are just files on a file system.
The Authentication element in the config assists in determining how IIS will identify a user's requests after its accepted and as it accesses resources beyond/external to IIS.
This is set at the site level, typically in the applicationHost.config file for your server. It can, if properly setup, be overridden at the site level.
IIS.net pages about this:
http://www.iis.net/ConfigReference/system.webServer/security/authorization/add
http://www.iis.net/ConfigReference/system.webServer/security/authentication/anonymousAuthentication
The .config version of what you did in the UI is:
<location path="/yourSite">
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="true" username="" />
</authentication>
</security>
</system.webServer>
</location>
On the anon. auth method, the username field is who IIS will impersonate when resources are accessed. When you don't specify one, it defaults to use the identity of the apppool.
Now, as to why this mattered ... check the actual file on disk (the .css). If this fixed the problem that would mean IUSR doesn't have access to read that file.
You don't have a location defined for your authorization. You also don't specify what sort of authentication you're using within the web.config (if any).
<location path="/">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>

Resources