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 »
In one of my previous posts I described how to create reports in Sitecore PowerShell Extensions (SPE for short) that allow you to leverage the joint power of Sitecore and PowerShell to deliver complete and elegant reports in little to no time. In this post I?ll tell you how to take this a step further and operationalize them into full blown Sitecore Desktop applications.
The secret sauce is in the actions you can place on the report, the additional parameters that I haven?t mentioned in the previous post, and the use of Sitecore rules engine with some rules that come with SPE.
For the purpose of this post I will limit the scripts to samples that are (mostly) in the vanilla SPE deployment.
Let?s begin with describing the actions and how you can configure them to appear in your reports.
What are report actions?
Actions are simply commands powered by scripts and with visibility dependent on certain conditions like the .Net class of the object that is displayed or perhaps other session settings.
You define an action as a script located in an SPE script library and appears in the Actions panel. In the simplest scenario the action would appear when the script library name matches the .Net class name of the items displayed. In the above scenario the actions are placed under /Platform/Internal/List View/Ribbon/Item/ where Platform is the module and Item is a script library. Let?s take a look at the script here /Platform/Internal/List View/Ribbon/Item/OpenRead the rest of this article »
April 13th, 2015 by Adam Najmanowicz | 54 Comments
This post describes how you can deliver JSON/XML/HTML APIs quickly with Sitecore PowerShell Extensions.
Technically this was also available earlier but the API was not refined to the state it is now.
As Sitecore is constantly progressing from predominantly serving as a CMS towards becoming a mobile and web application delivery platform (which is very apparent by the recent increase of SPEAK popularity, the introduction of Item Web API and the app centric nature of the new Sitecore 8 interface there is an increased need to rapidly deliver APIs for those those front end applications to work seamlessly with the CMS back-end.
PowerShell Extensions can help you with that move by enabling rapid prototyping of APIs that are either JSON or XML in nature.
How to make scripts available for the Web API?
This functionality is available in Sitecore PowerShell Extensions starting from version 2.5, however I was never happy with how it worked and how the URLs were structured. With the Modules functionality introduced in 2.8 it was a good time to model it properly for SPE 3.0.
To make a script callable through the v2 of the API you need to place it in an Enabled module in the Web API integration point library.
Find-Item cmdlet allows you to leverage the glorious new search API Sitecore introduced in the 7.0 version of its CMS to retrieve items using the Sitecore Content Search indexes.
You will find the available parameters on it as follows:
-Index – index name – ISE supports index name auto completion
-Where – Dynamic Linq syntax as specified in this blog
Last night I needed to reproduce really quickly a site structure we will be moving from another CMS and create a matching item hierarchy in my Sitecore instance… I could face an hour or so of boring clicking and copying and pasting and hoping I’ve not missed anything or… I could write a short PowerShell script to do the work for me… Guess which path I chose?
Before you use the script you should customize the script parameters:
$sitemapUrl – url of the sitemap of the site you want to clone
$prefix – wither site root or a branch you want to copy
$postfix – if a site has postfixes like .php or .aspx you want to get rid of – define it here
$itemTemplate – the template that should be used for items the script will create
Or just run the script and enjoy the glorious cognifide.com page structure reproduced in your Sitecore… now how cool is THAT!?
Kieranties must be the biggest PowerShell nerd (together with yours truly) I?ve had a privilege to chat with (I guess this implies I talk to myself?). So it shouldn?t be a surprise when the two started talking PowerShell/Sitecore pixie dust started sparkling.
This time ? events integration.
What does it take to integrate PowerShell with Sitecore events?
This is a fairly easy task that Sitecore pretty thoroughly describes in the ?Using Events? SDN article. So there is little point for me to reiterate it here.
The integration requires to add some entries to the include files. I?ve added definitions for most of the item related events to the Cognifide.PowerShell.config file, but commented them out, because I don?t want you to have any performance penalty associated with the PowerShell Console installation and by default it has some scripts defined for you to try out.. All you need to do to enable it is to uncomment the <events> section of the config file and scripts will start firing up.
Implementation is pretty straightforward – the console has well defined place within its script libraries where your scripts should be placed:
There are 2 more ways I?ve managed to find and implement that you can control data sources with PowerShell:
rendering data source roots
rendering data source itself
The motivation would be similar to what I?ve described in the ?Part 1? blog post. So without further ado let?s cut to the meat?
Rendering Data Source Roots
You might want your roots to be dynamic and you can deliver those using a PowerShell script!
Sitecore allows you to specify a place in the content tree where content for your rendering or sublayout can be selected from. More over it allows you to specify more than one of those roots. What?s even greater ? this is done through a pipeline defined in web.config, which means we can hook into it with? PowerShell!
A cool part of the experience is that you can have multiple roots, which means that your scripts can be more liberal in what roots they expose.
There is a lot of new stuff in the imminent 2.0 release of the PowerShell Console for Sitecore. Some of it is fairly obvious like the improved console window, some of it not so much. The aim of the console has always be to enable Sitecore developers to extend the CMS in new exciting ways. For this to happen it had to become a mini-platform on its own. So far you could use it to add scripts to ribbons and menus, write scripted tasks and execute scripts just by launching them from a URL call.
That?s extending Sitecore with PowerShell but what about PowerShell itself?
One of the coolest features introduced in 2.0 is the ability to write your own commandlets. Sure you could always use PowerShell to do it and write commandlets in script. But then the caveat was that you had to attach such commandlets to your own scripts (or put them in the initial script that would have to execute prior to the console). Now I?m talking about writing the real commandlets, just like those that come with the PowerShell console itself. Starting from 2.0 the console does not default to only attach commandlets that come with it, but can also scan other assemblies to attach your commandlets. To add your own all you have to do is well.. write them but then? all you have to do is to use the standard Sitecore include mechanism to enable the console to find them.
Including my own commandlets into Sitecore PowerShell Console
Where the type parameter is just a regular Sitecore type reference with a slight twist ? you can use wildcards in it. So with the above example, the console will scan the Cognifide.PowerShell assembly and allow you to use all the commandlet classes that are tagged appropriately.
March 31st, 2012 by Adam Najmanowicz | 30 Comments
While I?m updating it on a separate page I thought for the purpose of having a record and further tracking – it would be interesting to capture the state of the PowerShell knowledge in the Sitecore community here as well.