The post is related to the image resize vulnerability fix introduced in Sitecore 7.5. To read more about the Sitecore fix go to the Release notes page and search for “Media request protection”. While I was holding off for a number of months on the publication of the post as it puts the attack vector in plainer sight that I would like it to be (while the community figured out how to work with Media Resizing in a neat way) – but recently I’ve seen voices raised considering turning the Media Request protection off which I hope you will not be doing after reading this post. The post will also tell you how to enable such security on your older versions of Sitecore.

So here’s the story…. At some point in Cognifide we have performed a research around Sitecore security and one of my colleagues (Marek) found out that you could easily kill any Sitecore instance by performing an image resize attack on it. While the CMS did some rudimentary checks and limited the values of height and width you could still perform an attack by harvesting the images from the site and perform multiple parallel & iterative size increase or just plain use the scale parameter to achieve any image size. A result of such attack would be a a denial of service due to 100% CPU & memory usage and would potentially allow for filling the server drive by creating the endless number of scaling calls.

Marek was even kind enough to provide a proof of concept code that confirmed the hypothesis by performing attack on a few of our internal servers. The program would load the home page; parse to find images linked from it and perform resizing of the images in a number threads.

Psst… Mike made me add the image – supposedly without it I’m not as cool as Stephen!

Following the discovery I’ve attempted to remedy the problem and as a consequence came up with the solution which I have recently put on GitHub – ImageGuard which signs the rendered media links that use any of the resizing/scaling capabilities and filters all request that try to resize/scale, allowing the sizing only when the hash matches and provided it to Sitecore.

This solution is nowhere as complete as the one that was later provided by Sitecore – starting from version 7.5 – still I think it’s still worth making it public to allows for older versions of Sitecore to be guarded against this type of attacks.Read the rest of this article »

A while ago Jakob suggested that putting the Sitecore PowerShell Console in Visual Studio might not be a bad idea. He even provided me with the boilerplate code that served as a stub for the module (Thanks a million Jakob!).

So after some struggling on my part the new module is now on the Sitecore Marketplace. There is really not much to write about. If you like PowerShell and Sitecore Rocks you will find it pretty neat. Otherwise I’m afraid those are not the droids you are looking for

Basically what it does is: it allows you to enjoy PowerShell automation while still skipping the web interface (that effectively is why you’re using rocks, right?).

Installation is fairly straightforward. Once you download the zip file – unpack it somewhere on your drive and run the install.bat within it. Once you restart your Visual Studio you’ll be able to do the following:

All of the PowerShell blog posts so far were about using the console. Being the developer however, you probably think – well that’s good for admins, but what’s in it for me? How can I benefit from it in my code? Well you can. With the latest update you can run the PowerShell environment in your application and take advantage of its scripting power, by getting the results out of it and pulling them into your app.

Last week or so ago a couple of friends in another project in Cognifide has run into a wall while trying to load test their website. the problem was as follows: The website is highly AJAX based – the page merely loads a stub in the initial request but then loads the rest of its data in a dynamic matter therefore a traditional web testing tools are fairly useless. What they tried was to setup a number of Selenium clients to pound the server, but that turned out to be fairly challenging to the machine doing the testing. It was not possible to set up more than 10 clients on a fairly strong machine.

Also there are other limitations like time to wait for the server to timeout and time between clicks, which I am not sure the tool allowed them to adjust. Talking to them I recalled a tool for grabbing website thumbnails long time ago. one way for them would be to to make a batch file with it. The tool would grab the sites’ thumbnail and stress it, but they would still have to setup a number of clients. Also it creates and tears down an instance of IE every time, making it’s not optimal for that task.

So a couple of evenings later (and a few back-s and forth-s during the testing sessions) out comes SoakIE:

I’ve just read a blog about a few new additions to C# 3.0 and in the context of what we’ve already learned about the whole “Orcas” project that is the simplest conclusion.

Microsoft .Net Framework designers and coders are just a bunch of programmers who you can clearly see enjoy hat they do. I can’t stress enough how many times I’ve been annoyed to be forced to wrap some private variables in the obvious public properties. No longer!

Instantiating a class followed by a bunch of setting of properties? Now done in one line. Shweet.

One may argue that C# is a set of such syntactic sugar. But then again, I am sure that’s why so many programmers really like it. Even some of the most Java oriented programmers (Yes Albert I’m looking at you!) in our company are looking forward to work on .Net.

It is the general perception here that, comparing to Eclipse, Visual Studio is a weak IDE in terms of pure code-writing-helpers, refactoring, and discovery of code dependencies. Only the next version will even be able to target more than 1 .net framework version… Please fix that crap… But the language designers are continually doing a great job.

EPiServer is an Interesting technology we’ve started working on recently. I will try to blog my impressions and the progress over the course of learning the solution.

Since I just seem unable to learn by reading docs I chose to build an email obfuscating (antispam) control and a paged search as an exercise and a way to learn the guts of the EPiServer.

A couple of loose thoughts for a start…

Translation

I am not sure I fully appreciate the way the translation is performed for the parts of the system that is editor independent . The translation is done by means of xml files stored on the disk in the /lang folder.

Basically what that means is that it’s much more prone to missing translations and thus is not as translation friendly as it could fairly easily be.

For the content I can always fall back to the e.g. english version and look what’s the original value there. not so much for the framework translations. Is there a tool for that? I will investigate that later as we’ll probably want to create a number of controls for the website we’ll be working on soon, and that will need to be translated to many languages. And not just that but also the original template files – we will need much more than what’s available originally in EPiServer.

in which you defined where the translation is to come from. (In this case the path is: “/templates/emailobfuscator/obfuscate”) you need to edito the template framework file and add the translation there with the XPath defined in the control. Which looks along the lines of:

<?xmlversion=“1.0“encoding=“utf-8“standalone=“yes“?>

<languages>

<languagename=“English“id=“EN“>

<templates>

<emailobfuscator>

<obfuscate>Obfuscate</obfuscate>

</emailobfuscator>

…

</templates>

…

</language>

</languages>

The most annoying part of it though is that it needs to be done for alll the languages if you want the site to be fully translated, which without a tool is not fun.

I will look more into that later. One would expect that a tool like that may exist already.

Technology

I am really looking forward to EPiServer 5.x to be released. It’s to be based on ASP.NET 2.0 which most probably means (I hope)that a number of EPiServer specific technologies will be replaced by a .Net generic technologies. As the ElektroPost notices:

Also the EPiServer seems to be really hard to develop for in VS.Net 2005. I still didn’t Indeed ElektroPost suggests VS 2003 as the development platform, but once switched to 2005 I personally can’t deal with VS 2003 any longer.

The good news though is that it is compatible with .Net 2.0 in a way that you can simply add an ASP 2.0 control and with just slight modifications work with it. You can also use .Net 2.0 partial classes – which means much cleaner code.

Overall the EPiServer is a really positive experience. I’m looking forward to work more with it.

The article is based on the knowledge I’ve gathered and work I’ve performed for Cognifide. Cognifide is an official partner EPiServer and the real contributor of the the control.