Let's say I have the following in a web.config:
<allow roles="Developers" />
<deny users="*"/>
This locks down access on .aspx, .asmx, and other .NET file types, but it's still allowing unauthorized users to open static files like image.jpg. I understand why the web.config isn't asked for authorization information when someone asks for image.jpg (it's not a .NET type, and IIS can bypass it), but how can I lock down a whole application?
Advice I've found online includes:
create a <location> entry for the directory in question and IIS / .NET will pick it up. (It doesn't seem to.)
you need to write your own ISAPI filter and map all sensitive files' extensions to that.
you don't need to write your own ISAPI filter - just mapping the extensions to aspnet_isapi.dll will do it.
you don't need to edit IIS at all, just create an httpHandler entry in the web.config for your extensions. (I'd really rather not try to do this for every extension in the application.)
None of this works quite as easily as I remember it being in Apache. What's the simplest thing that might work to ask a visitor for a password and not serve any files (static or not) to any user that doesn't have it?
Enable wild card mapping for IIS 6. This will send all files through the ASP.NET pipeline, guarantee form auth happens for all files. It will degrade performance (dunno how much).
For IIS 5, um, upgrade to IIS 6.
You list 4 ideas:
location only works if you have wild card mapping (or specific extensions mapped).
Who wants to write an isapi filter? You can't easily do it in managed langauges unless you have IIS7. And who wants to write a c++ isapi filter?
wild card mapping does work with the above caveat (performance)
Again, last option wont work without registering those specific extensions with IIS and routing them through aspnet.
A nice simple way is to upgrade to IIS 7- it now has an integrated pipeline.
Related
I have a ASP.NET 4.0 WebForms webapp running on a IIS6 webserver. I'm not allowed to make any changes to the webserver. I have a flex app embedded in this file called:
myapp.contoso.com/mysubapp/mysubapp.aspx
I'd like to only require the user to use the URL:
myapp.constoso.com/mysubapp
to reach the application and essentially hid the mysubapp.aspx permanently. I've been checking out URLRewrite and URLRewriting.net... It all looks to be a little much for this once instance in which I need it (if I need to add more rewrites in the future I'll use one of those frameworks). Is there a simple way to achieve this? I've checked out similar posts... it seems that I may need to write a simple one myself?
URL Rewriting using iis6 with no extensionless urls
How to deal with extensionless Url in ASP.Net and IIS6
The simplest thing I can think of is to rename your web page from mysubapp.aspx to default.aspx. This will allow users to request myapp.constoso.com/mysubapp and get your page. This should work if you have not removed default.aspx from the default document list in IIS.
Alternatively, you can add mysubapp.aspx to the list of default documents in IIS.
BTW this is not something I am want but is a requirement I must follow. My requirement is to create a user interface that will allow users to disable Classic ASP while allowing ASP.NET 1-4 applications run. Can anyone think of a use case were a user would want to do this?
Sure, if you were a web-host offering partial access to a webserver through an application that emulated some of the relevant IIS options, then not only would customers not want the added risk of unneeded script/executable systems running, but you wouldn't either, so you'd want it turned off unless they went in and explicitly turned it on because they needed it.
Indeed, software for this use-case already exists.
Jon's comments about reducing a site's attack surface by removing unwanted features is very valid. You should ideally just run what you need and no more.
There are a number of ready made commercial solutions to this problem such as Plesk, but they may provide too much functionality for your needs.
You could write your own functionality:
If this is IIS6 then you should take a look at the ADSI API which is surfaced via the System.DirectoryServices namespace:
Using System.DirectoryServices to Configure IIS
To enable/disable scriptmaps you need to manipulate the ScriptMaps metabase property for a site:
ScriptMaps Metabase Property (IIS 6.0)
If this is IIS7 then take a look at the Microsoft.Web.Administration managed API. In IIS7 you want to manipulate the handler mappings for a site:
Handlers <handlers> - IIS.NET
In all cases, the user must be a member of the machine's Administrators group.
I am wondering how one goes about creating/rerouting my custom developed .ASPX pages on IIS 6.0 pages to something totally custom w/o the .aspx extension, say, .vato? For example, instead of my page saying: Default.aspx?ID=123, I would like users to see: Default.vato?ID=123.
What concept is? Is this doable? Where can I research more on this topic?
Yeah, read this:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/4c840252-fab7-427e-a197-7facb6649106.mspx?mfr=true
Create a new entry for your new extension and map it to the same executable as the .aspx handler.
The common one is to add a wildcard. This allows you to have URLs without extensions at all. IMO, that's much preferred because extensions make little sense on the internet.
It's not so much a .net question as it is an IIS question.
Basically, IIS looks at what extension is being requested and responds accordingly.
There is a list of all file extensions and what actions should be taken when these are requested. In terms of .net, these are .aspx, .ascx, asmx, etc. These are basically ISAPI filters.
Depending on your version of IIS. If you open IIS Manager, choose the website in question, go to Properties, then Home Directory, then Configuration, under Mappings you will see all file extensions and the application that will be called to action this request.
Therefore, if you add an entry for .vato, and point it to your version of .net, such as C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll then the .vato file will then be treated the same as a .aspx files.
In IIS (6.0) click on "Configuration" on your Web Site page and you can add mappings there. It must reference the same ASP.NET ISAPI DLL as for example the ASPX pages.
You can also add * and have all requests route to a HTTP module but that's a little more advanced and useful for the likes of REST.
I've got a virtual directory with a vast subfolder hierarchy and thousands of classic ASP files, all of which have varying permissions set at the NT folder level (don't ask.. shakes head).
Is there any way to setup all these virtual directories with their own web.config so i can control access via configuring system.web.authorization parameters therein and doing away with folder level permissions?
I've tried and so far have only been able to have this work on asp.net files, not classic ASP.
If it isn't possible, can someone offer some alternatives?
Because clasic ASP has no idea about the ASP.NET runtime due to the fact that it is a) classic and 2) isn't .NET, you can't use the .NET configuration to manage the permissions.
Your options though would be:
Upgrade to IIS7
Rename all you asp pages to aspx
Change your asp handler to aspnet_isapi.dll (which is the .net handler)
While 2 and 3 may work you will need to completly test these pages to make sure that they still work as intended.
I would say the best bet would be to just use the file system ACLs to control who can access the folders. Just because you don't understand them doesn't mean that they don't have their place.
You can use wildcard mapping so that all file types will be handled by the ASP.NET runtime in IIS6; however, even with this turned on permissions are not handled through the web.config. Windows authentication in both classic and .NET uses the file permissions to determine access.
I have an application that uses Forms Authentication to authenticate one type of user. There is a section in this application that needs to be authenticated for another type of user using a different table in the database. The problem happens if the second type of user's session times out, she is taken to the login page defined in the Forms Authentication section of the main Web.Config instead of the login page for the second type of user. I am looking for solutions to this problem. One idea is to create an application in IIS for the section and create a Web.Config for the folder and add another Forms Authentication section. In my experiments, it seems this doesn't work. Am I missing something obvious? Any insights?
IIRC, the authentication works per folder. So you should be able to do it if all of the pages that require the 2nd type of authentication live in a specific sub-folder with it's own config.
Not 100% sure on this, though, so if someone more knowledgeable can contradict me I'll just delete the response.
You may need to double check me on the syntax, but the top level web.config can have any number of tags.
<location>...</location>
Inside you can specify separate config parameters for whatever folder/file you want. Look here for a reference.
EDIT: Apoligies, I neglected to format the code properly
You cannot have an <authentication> section inside of a <location> tag, so you must have the subfolder set up as an IIS (and ASP.NET) application of it's own. So, you should be able to run the subsection on it's own.
I think 500.19 is the "can't read or parse web.config" error - does it have details? You may need to turn on remote errors (or check Event Viewer) to see them. If you're still having issues, post a snippet of web.config.
As an aside - I've never been a fan of nested apps, and would probably prefer having your normal Login.aspx page handle it either with as a MemberOf or perhaps redirecting to a SpecialUserLogin.aspx or something. Nested apps are a PITA to setup and test, IME (for instance - I don't think you can even get it working under Cassini - though you can do 2 separate projects for it, and combine when you deploy).
Yes you can. The Web.config files have a tree-like inheriting arhitecture with override capabilities. Meaning you can modify the settings inside a sub-folder by placing a web.config file there and specifying different configuration settings.
The way I understand this problem, you have two solutions and the first is to look at Roles and the whole Provider Model would be a great place to start. Otherwise, the best bet would be to separate the application into two parts, breaking out the second user type area and then including it back into the main project via a Virtual Directory. Just remember that Virtual Directories inherit their permissions from the parent directories web.config, so you will need to use the <Location>tags to remove authentication for the virtual directory and then within the virtual directories web.config define your new forms authentication. This works well if you need Windows Authentication (NTLM) under Forms Authentication.