30 June 2015

Sitecore Rejected-By-UrlScan /sitecore/shell/Controls/Lib/jQuery/jQueryUI/1.9.2

One of our dev servers began having problems loading 2 specific files in the Sitecore backend, they returned 404 error pages instead.

~/sitecore/shell/Controls/Lib/jQuery/jQueryUI/1.9.2/smoothness/jquery-ui-1.9.2.min.css
~/sitecore/shell/Controls/Lib/jQuery/jQueryUI/1.9.2/jquery-ui-1.10.3.min.js

Changing the folder name to 1 instead of 1.9.2 made the content appear, so it was not file security related. In the IIS logs we could see Rejected-By-UrlScan

2015-06-30 08:43:17 192.168.2.21 GET /Rejected-By-UrlScan ~/sitecore/shell/Controls/Lib/jQuery/jQueryUI/1.9.2/smoothness/jquery-ui-1.9.2.min.css 80 - 192.168.1.109 Mozilla/5.0+(Windows+NT+6.3;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/43.0.2357.130+Safari/537.36 404 0 0 41352

On the 16. june 2015 an update had been released to Microsoft URL Scan 3.1
The config file for URL Scan is in a ini file in a subfolder of the IIS server. The setting AllowDotInPath seems to be the cause of the problem on the server.

  • AllowDotInPath=0By default, this option is set to 0. If this option is set to 0, URLScan rejects any request that contains multiple periods (.). This prevents attempts to disguise requests for dangerous file name extensions by putting a safe file name extension in the path information or query string portion of the URL. For example, if this option is set to 1, URLScan might permit a request for http://servername/BadFile.exe/SafeFile.htm because it thinks that it is a request for an HTML page, when it is actually a request for an executable (.exe) file with the name of an HTML page in the PATH_INFO area. When this option is set 0, URLScan may also deny requests for directories that contain periods.
Source: https://support.microsoft.com/en-us/kb/326444

This is defintively the issue.

But we found that changing the setting AllowDotInPath and restarting the IIS Service did not solve the issue. So we have been forced to uninstall URL Scan, and now need to revisit this issue later on to see if we can get this up again.

No comments: