I noticed that CKEditor (the extra ajax plug-in) impersonate the IUSR_machinename user account to operate with files and directory. Have you do it intentionally or what? Why don't operate with NetworkSecurity account that's the standard one for every w3wp process?
Using hte IUSR_* one means decrease the security of the data stored into the web server and expose them to potential hackers.
Is there some way to change that?
Thanks
Andrea
Using hte IUSR_* one means decrease the security of the data stored into the web server and expose them to potential hackers.
Is there some way to change that?
Thanks
Andrea
Re: Impersonalization
What's "CKEditor (the extra ajax plug-in)" ?
CKEditor is the new version, but I don't think that you are using it because it isn't even beta.
In my tests it seems to me that the default user for the IIS server is the IUSR_ account, not NetworkSecurity. And FCKeditor doesn't tries to change the user account, you are the one that must provide the requiered priviledges to the folders if you want to use the file manager.
Re: Impersonalization
Re: Impersonalization
Ok, now it's clearer.
That's not exactly a plugin. You can use it without FCKeditor, and its name is CKFinder. Its forum is below this one: CKFinder forum
According to your description you are talking about the asp.net version, and one important thing is that the code isn't impersonating any user, it's using just the default configuration from your server, so you could post a message requesting for this new feature.
Anyway, I fail to understand how impersonating the NetworkSecurity account can be safer rather than using the default configuration. I guess that you will need to set write privileges for the files folder for that account anyway, and maybe in shared hosting systems it might be harder to do it, but it's clear that they offer the ability to set write privileges for the IUSR_ account as that's what most of the people will use, so this should be just an option if it's ever implemented.
Re: Impersonalization
It's safer for two reason:
1) NetworkSecurity is the standard user used by every IIS process, and by default it has read/write permission. Certainly they should again changed into special, to grant it also delete file and folders, otherwise it will work just for the half taks
2) NetworkSecurity is never used by the process used by the surfer. This mean that browser will continue to be able just to read file and nothing more, networkSecurity could do the rest. Enabling, wrongly, the write permission to IUSR_machinename user the write permission, could result in some posssible hacking.
Just to do an example bit complicate. Image a standard .net project with its own App_Data folder. By default that folder hasn't any sort of privileges also for IUSR. Now, imagine that you previously decided to save your image files (as I did) in the App_Data folder for backup convenience as well as for standard security reason. In this way I could get access to that files only through an handler designed for the specific purpose.
Enabling the read permission will break this simple rule, and every file into the app_data folder starts to be accessible via a simple url call. Definitely not the best scenario I can imagine for a project.
That's the reason I think it should start to support the impersonation.
Do you think I should suggest the thing also to the other forum, or do the author read also these topics?
Re: Impersonalization
There is a couple of options:
1. Remove IUSR from the list of users that are allowed to access your restricted folder and add another Windows user who can access the folder. This way IIS will prompt you for credentials when you request files from this folder. Enter the name of the Windows user who can access this folder and off you go.
2. Use client certificate mapping (see Properties > Directory Security > Secure Communications)
On the topic of impersonation, you would have to maintain your own database of non-Windows users and your own access control lists. This is a job not for a faint-hearted and if not done right, will expose your server for an attack. One way to do this is to have code within IIS running as an ISAPI filter. Once the filter starts, it will run as Network Service and you can start its own thread(s), which also will run as Network Service. At run time, IIS worker threads running as IUSR will make requests to the filter thread(s), which will have all access Network Service does and will do the job on behalf of the impersonated user, but within the limits imposed by filter threads.
Re: Impersonalization
Thanks for clarification.
I'm thinking on a possible hosting scenario, and your 1 option isn't applicable due to the fact that generally the various hoster never allow permission changes nor change the default guest user (IUSR) with a new specific privileged one.
About the second option, it's what I was saying. Impersonation done into the compiled dll that CKEditor will use. IUSR will interact with that assembly that act with different privileges; it does the task and return a result to the client through the XML RPC call it does.
I think - but not sure - that in this case all the risks you are claiming, never became true. In any case, some additional lines of code that will check about the path where the assembly operate definitely remove all security risks.
Re: Impersonalization
I think ASP.Net still relies on Windows user names/passwords NTFS permissions:
http://msdn.microsoft.com/en-us/library/xh507fc5(VS.71).aspx
Re: Impersonalization
I think that my idea could work, but I'm not able to find more information about the token switch.
I mean, IUSR will ask for CKEditor.dll via an XML-RPC to do something. I think that code impersonation just enabled for that dll, will then start to use NetworkService (or another account according to a possible configuration file), do the tasks and then ... I don't know what's happen to the token.
I suppose, since the operations are remotely called, once the cose has ended the upload/rename or whatelse operation, the code terminate the process and so do with the token, but as I said, I'm not able to find any supporting information to this theory.
Re: Impersonalization
Only Microsoft products. Many other products rely on their own permission mechanism, similar to what I described earlier, so it's easier to manage users in a hosting environment.
A DLL runs within the process' address space (i.e. IIS worker process in this case) and there's no need to use XML RPC because you would be able to call DLL functions directly.
I can't comment on CKEditor.dll - don't know anything about it. Sorry.
Re: Impersonalization
Well, yes. in this case I was referirng to MS.
It,s one solution, but as far as I see, this browser use an XML call.
We probably should wait for the author answer.
Re: Impersonalization
Talking about XML-RPC and verifying the location of the CKFinder dll makes me think that you haven't looked deeply at the code. The basic idea is the same one available in the FCKeditor file manager the difference is that this dll does include more functionality, but at a very rough level they are just the same: the js code calls a page in the server, that page usually returns an XML response, but that's all. The same code that runs in a dll could be run directly in the page, so if the dll was able to change the user account, then any other code could do the same.
Yesterday I was using a Plesk control panel for windows, and in the security for folders I was able to adjust the privileges for the IUSR_ account, but there was no "Network Service" to use.
Re: Impersonalization
Well I think your going out topic, because I'm not able to see any relationship between a standard CMS and what I'm saying.
To be honest, no I didn't do very deep analysys about what code really does. I just saw that it call a standard ckfinder.html file that will make a call to an aspx page (connector) that elaborate an XML request specifying what to do. All the action are then made by the assembly that return an XML response to the connector and then again to the standard html page that will be refreshed to show the results.
In this context, if the assembly will impersonate a different user, to be able to write to the standard App_Data folder, perform what he need, close the impersonation process, and above all will check that the request is to work only to application relative path, I don't see all these risks.
I'm not following you. The dll can be called only by an aspx web page. This means that only a web programmer who has access on the specific server (don't consider external possibility) can upload other file that can allow surfer to make call to that dll. What are the risks? It could be the same than a web page erroneously get access to a local db using the sa password.
This doesn't mean that all hosting service let you access to the security and NTFS permission of the IUSR account.
Re: Impersonalization
As I said, every CMS will need to write some files to the server. And it's in the best of their interests to be as secure as possible, so it just logical that if impersonating the Network Service is better than using the default IUSR_ account, then it should be easy to find out documentation about how to do it and long essays explaining the benefits of that move.
Ok, but there's no need to do anything related to XML-RPC, and the checks should be part of the normal process of writing anything to the server, you just can't trust any input from the user.
No, you should consider the dll part of the aspx page. You can place the raw source code in an aspx page and it will be automatically compiled, or you can distribute the code already compiled, but there's no difference if the code is in one form or another, it will be executed in just the same way.
No, it just mean that I can't use the "Network Service" with Plesk. My point is: what ISPs allow to change the priviledges of a folder for the Network service account?
Re: Impersonalization