Umbraco 7.5.0-beta2 released
Today, we're happy to anounce the second (and last) beta version of Umbraco 7.5.0. Your valuable feedback on the first beta has been very helpful in making version 7.5.0 even better than it already was. Thank you so much for your bug reports and your pull requests!
Here's a list of changes made between beta1 and beta2. Some of the notable changes, apart from some great bug fixes, are that the new package installer UI has been improved, and that we've made significant improvements to boost the performance of the XML cache, which also uses less memory.
We've made two major changes which we want to validate with the community before putting the "final" stamp on this release:
- ImageProcessor was to the latest version, which could have significant impact for upgraders depending on what features you're using from ImageProcessor
- We changed quite a few things regarding 301 URL tracking for which database changes are necessary
Following up on a much appreciated push from Kevin Giszewski and from our friends at Perplex we helped updating a known security issue with ImageProcessor. The problem was that you could send ImageProcessor any querystring and it would be processed, generated a new image and served it. Perplex even started seeing someone abusing this by them simply increasing a parameter by 1, so for example "?blur=100", "?blur=101", "?blur=102", etc.
It became painfully obvious that processing those requests that came in in fast succession quickly maxed out the CPU of the server (blurring is quite a heavy operation). To add insult to injury, all of those processed images get stored too so they are rapidly filling up the server's disk.
A few measure were taken to limit the impact of such an attack.
First of all, by default, ImageProcessor will no longer respond to any processing requests unless they are of the types:
So when you upgrade to Umbraco 7.5.0 and your image urls look like "product.jpg?blur=100", then after the upgrade your product image will no longer have a blur on it. This also goes for processors like Flip, Mask, Saturation, Watermark, etc. So the only processors that are still active by default are the ones listed above.
If you wish to re-enable some of the other processors you will need to install the NuGet package ImageProcessor.Web.Config and enable the processors you need in the configuration file.
The other change is that there's now a "ValidatingRequest" event you can hook into. This event allows you to "massage" any of the requests to ImageProcessor to your own liking. So if you'd want to never allow any requests to change BackgroundColor, you can cancel that from the event. Similarly if you have a predefined set of crops that are allowed, you could make sure that no other crop sizes will be processed than those ones you have defined ahead of time.
These changes have been made through significant effort by Shannon and James South, the creator of ImageProcessor. We very much appreciate and applaud the efforts and the help from the other people involved in the issue thread who helped puzzle together the best possible solution for everybody. These efforts show how open source and collaboration between community members can really shine and make our software better for everyone.
With these changes, we believe we've found a "happy medium" of not breaking everything but also not allowing the most processor intensive operations to run by default. If you're concerned about this for your sites right now, you should consider validating each request using anti forgery tokens in the ValidatingRequest event mentioned earlier. We'll blog about exactly how you could do this in a future blog post before 7.5.0 ships as a final release. Alternatively, CloudFlare is also great at detecting and fending off these types of attacks. This would be an easy code-free way of defending your site against any kind of denial of service attack.
In the future, we're thinking of adding a few more restrictions, for example only allowing the crops to be generated that you've pre-defined on your cropper datatype in Umbraco. We're still trying to think of solutions for responsive images however. Feedback is welcome!
We are awaiting your feedback however, we've tried to keep the solution as flexible as possible and made some painful decisions and we're willing to be challanged on those decisions. Please add your comments on the ImageProcessor issue for this if you have any concerns.
In order to make Courier deployments work with URL tracking, we needed to change a column in the database. For us to do that we will need to drop all your data from the UmbracoRedirectUrl table. If you're already relying on this data then make sure to take a backup of it. The change consists of storing the contentKey (the GUID of the content item) instead of storing the integer contentId.
Get it now
We're very excited for this release, the beta version from a few weeks ago has proven to be very stable and a joy to use. We'll give it another few weeks for people to test this second beta but we're confident that we won't need to change much more before we put the "final" stamp of approval on this release.