It states that you must return a success and a node id, so if one would use the current http context and do a server.transfer instead, is this a very bad idea? Hate adding a custom error node to all our Umbraco installations, as that would be a real pain in the a..
You can redirect to anything you want (just do a response.redirect and make sure to set a 301 header if you want search engines to know that the redirect is permanent). But why not just use the patch provided by Umbraco? It'll receive an update in a few hours, so you might want to hold off a little longer.
I suspect that it will make use of an Umbraco node to work, or? That will not work when patching over 150 Umbraco installations of various versions also. I cant go around all 150 sites and install pacthes, Need something that I can use the file system to get it running.
It could definitely be automated, I'm using a tool called ssr to change things in .sln and .csproj files to convert between VS2008 and 2010, you could probably make a regex that will change all of your web.configs.
Just make sure you have a back-up because your current settings won't be saved.
Am I vulnerable if I have my own custom error module?
If the responses that are sent out from your custom logging module do not let the client distinguish between error responses either through its content or time that it takes to serve out, then such a module is an adequate replacement for the customErrors workaround. These responses include both the entire HTTP response and the HTTP error code. If any of the above is not true at all times, then this is not sufficient. Instead you should send out the same error response for all errors until the security update is available to fix the underlying vulnerability.
Not found handler, ASP.NET Security Vulnerability
As one is supposed to return the same error page for 404's and 500's. I thought of writing a custom "Not found handler" to redirect to a generic error page for all our Umbraco sites, but when reading this: http://umbraco.org/documentation/books/not-found-handlers/creating-a-custom-not-found-handler
It states that you must return a success and a node id, so if one would use the current http context and do a server.transfer instead, is this a very bad idea? Hate adding a custom error node to all our Umbraco installations, as that would be a real pain in the a..
What do you think?
You can redirect to anything you want (just do a response.redirect and make sure to set a 301 header if you want search engines to know that the redirect is permanent). But why not just use the patch provided by Umbraco? It'll receive an update in a few hours, so you might want to hold off a little longer.
I suspect that it will make use of an Umbraco node to work, or? That will not work when patching over 150 Umbraco installations of various versions also. I cant go around all 150 sites and install pacthes, Need something that I can use the file system to get it running.
No, it changes the web.config to and redirects both 50x and 40x errors to /umbraco/plugins/poetpatcher/CustomError.aspx.
You will HAVE to modify EACH web.config file in every one of your sites as per Microsoft's recommendation, there is currently no other way.
Yes, but that can be "automated" with some nifty search and replace. Hmm, that sounds good. Will ait until it comes and see how I can make use of it.
It could definitely be automated, I'm using a tool called ssr to change things in .sln and .csproj files to convert between VS2008 and 2010, you could probably make a regex that will change all of your web.configs.
Just make sure you have a back-up because your current settings won't be saved.
FYI from ScottGu's blog:
Am I vulnerable if I have my own custom error module?
If the responses that are sent out from your custom logging module do not let the client distinguish between error responses either through its content or time that it takes to serve out, then such a module is an adequate replacement for the customErrors workaround. These responses include both the entire HTTP response and the HTTP error code. If any of the above is not true at all times, then this is not sufficient. Instead you should send out the same error response for all errors until the security update is available to fix the underlying vulnerability.
Comment author was deleted
Updated patch is out: http://our.umbraco.org/projects/developer-tools/aspnet-security-vulnerability-patch
Tim, nice. What response status are you setting when displaying the error page?
is working on a reply...