I guess I’m on a security hardening binge for 2019, since I’ll share a hot-off-the-presses security hardening measure from Sitecore today. I don’t want to say too much about the vulnerability, but this article explains in general terms and applying it to all Sitecore server roles for version 8.2 through any current 9 releases is emphasized as the best practice. I’d do it at the next opportunity.
I created a gist with the PowerShell necessary to apply this patch, just update line #8 with the path to your Sitecore website:
Set-ExecutionPolicy –Scope Process –ExecutionPolicy Bypass | |
Import-Module WebAdministration | |
$url = "https://kb.sitecore.net/~/media/7A638A36A71D4494981A8655E297AD23.ashx?la=en" | |
$tempLocation = "C:\tempLocation" | |
$zippedPatch = "$tempLocation\SitecoreSupportPackage.302938.zip" | |
$unzippedPatch = "$tempLocation\SitecoreSupportPackage" | |
$sitecoreRoot = "C:\InetPub\Your\Sitecore\Website" | |
if (!(Test-Path $tempLocation)) | |
{ | |
New-Item –ItemType Directory –Path $tempLocation | |
} | |
Invoke-WebRequest –Uri $url –OutFile $zippedPatch | |
Expand-Archive –Path $zippedPatch –DestinationPath $unzippedPatch –Force | |
Copy-Item "$unzippedPatch/website/*" –Destination $sitecoreRoot –Recurse –Force | |
Write-Host "Patch applied to $sitecoreRoot" | |
Remove-Item $unzippedPatch –Recurse | |
Remove-Item $zippedPatch –Recurse |
Our team has internal automation taking the above a bit further and using another layer of abstraction, and that’s secret Rackspace sauce I won’t share publicly, but the snippet above should have your environment patched in just a few seconds.
One of the key elements to the patch involves an update to the /sitecore/admin/logs.aspx page which, if you dig into it, reveals a grip-load of additional C# validation logic and other stuff going on . . .
There’s a lot to unpack in there if you’re curious, but suffice it to say that Sitecore’s keeping all your bases covered and isn’t trusting user input (using a broad interpretation of that principle).