Vulnerability in EPiServer.Forms
What's the correct way to disable edit/admin UI on front servers? If there is no "correct" way, I'll settle with a good way ;-) We're on CMS 6 R2
What I would like to happen when I try to enter the UI URL is to return a regular 404. No login prompt should be shown.
Tried so far:
I would remove the virtual path providers in the episerver secion of config, at least the CMS one and possibly more if you want to disable online center etc as well.
Thanks, but I've already tried to remove the Virtual Path Providers... Problem is that I still get the login prompt... How do I disable online center?
Did you remove the corresponding locations as well?
Finally, with some additional assistance from EPiServer support I've managed to get a 404 when trying to access edit/admin on front servers! \o/
Just like Magnus suggested, the key is to remove the VirtualPath entries in episerver.config (~/UI/CMS/, ~/Util/, ~/WebServices, ~/UI/Shell/) AND the corresponding location entries in web.config (ui/cms and util).
There is also an article at http://world.episerver.com/Documentation/Items/Tech-Notes/EPiServer-CMS-6/EPiServer-CMS-60/Protecting-Your-Site-From-Session-Hijacking/ which mentions this in the last section.
Sorry Magnus, had to remove the answered flag as I've investigated a little more... Yes, the edit/admin will be disabled by these changes. But this will cause errors, since EPi adds references to the contextmenu-related JS files in the front page (which now gives 404) and JS code to wire the context menu. This doesn't look good at all from a SEO perspective (and the JS error which will follow).
In order for this solution to fully work, all EPi-references must be removed from the front server. How can this be achieved?
Couldn't you just remove the Util VPP and that would make it impossible to login and access the edit/admin mode as you need to be authenticated for those places?
Whenever you tried to access admin or edit you would get redirected to the login page which would of course give you a 404 as that VPP has been removed.
As Magnus pointed out, removing the appropriate sections in web.config and episerver.config will cause 404 when trying to access edit/admin... so that is fine. Problem now is that in the other end (when viewing front page), for some reason (even if I am not logged in to Episerver), he tries to load the context menu file and fail (since they also are 404)...
I don't understand why EPiServer wants to add contextmenu in this case. Is it because of the change in location tags?
OK did some more investigation now and it seems that this might be a bug in EPiServer.
Reflected the code for ContextMenu and realized that the criteria for the menu to be shown is that you have GET access to /edit path. Now, if we remove the VPP:s, you will get a 404 when trying to access /edit. This apparently counts as a valid GET and the menu is shown.
I am reluctant to changing the MasterPage to check whether we are on a front server and then programattically disable the context menu, but for now it seems to be the only solution.
Toni, I've tried to take out only the Util VPP but in some strange way Episerver still manages to redirect to /util for a login prompt. I also tried to screw up the utilUrl setting but still it seems to find its way to Util...
Surely we can't be pioneers in wanting to disable UI on front servers?...
If you removed the Util VPP then it shouldn't find the Util path. Unless you have a Util folder in your web root. How else is it finding where the Util folder is located? Seems impossible. And if you change the utilUrl it should use that when unauthorized users wants to access protected locations. If it uses another path, then the change hasn't gone through yet (restart IIS) or you are editing the wrong file.
Unfortunately that's the only advice I can think of.
It is possible to disable edit and admin mode on a front-end server by removing parts of the web.config and episerver.config, but there does seem to be a bug in EPiServer that causes the pages to try and load the context menu. I have written a blog post on this which includes a work around for that problem.
Disable EPiServer Edit/Admin secure paths on front-end servers