Vulnerability in EPiServer.Forms
Recently upgraded to CMS 6 R2 and seeing the following error coming through surrounding EPiServer.Web.PageExtensions.AntiForgeryValidation. This occurs when I access the EPiServer edit mode and navigate the tree sructure.
Here is my set up:
This issue only arises with the site that doesn't have www's. Also, if I go direct to EPiServer edit mode on each box it works fine. So this issue only arises when load balanced and on the non www domain.
Have you set the same machine key on both machines? Please see http://aspnetresources.com/tools/machineKey
Confirmed that machine keys are the same on both boxes. All the other sites in the same installation work fine. I'm pretty sure it's to do with the fact this site is not served on www whereas the others are. We don't see this issue when we use an individual machine directly.
I solved this issue by correcting the domain in the httpCookies section in web.config. The AntiForgery system works by adding a value to a hidden field, and setting a cookie with the same value. It then compares these values on postback
The HttpCookie is created based on the domain setting in web.config. In this instance it was set to the incorrect domain, if you are running on a subdomain, you will need to prefix the domain with a .
<httpCookies domain=".mydomain.com" />
Hope this helps
Today i had the same problem, but only in Internet Explorer. In Chrome and Firefox it just worked as expected.
We solved this by removing the underscore from the subdomain we were was running this instance of EPiServer on. Apparently Internet Explorer blocks cookies from domains with an underscore in it!
Kasper, underscore is not a valid character in a domain. It's valid in the path and query though.
We have been getting this issue in a secured CMS / Composer / Relate Intranet that uses a federated authentication process. Interestingly, it only happens from computers running IE behind the clients firewall and remote access. It does not happen when using a (decent) browser that connects directly via the federated authentiation process. I think we'll simply disable it, since the site is already highly secure and all users must be authenticated via the federated system.
See thread at http://world.episerver.com/Modules/Forum/Pages/thread.aspx?id=50746
See also thread at http://world.episerver.com/Blogs/Per-Bjurstrom/Archive/2010/4/Using-the-CSRF-page-extension-in-CMS-6/