Had a head-scratcher of a problem this week. When saving a document type in the Umbraco back-office, the Umbraco database was becoming corrupted (notably, records in the tables cmsTab and cmsPropertyType). Inexplicably, certain fields (like alias, name and description) were being set to empty strings.
Any attempt to access content using the corrupted document type in the Umbraco back-office led to a server 500 error:
So what could have caused this catastrophe?
We first blamed Umbraco - maybe there was a bug causing the document type save action to fail. But no, nothing in the Umbraco log or the System event log.
I then remembered that our IT department had recently installed a Cisco ASA 5515 Intrusion Prevention System (IPS) firewall "in front" of the web-server. Hmmm... could this system, designed to prevent problems, actually be causing damage? The answer seems to be "yes".
As far as I can tell, it seems that if you POST data containing the word "select" followed somewhere in the request data with the word "from", the Cisco IPS assumes you are attempting an SQL injection attack (yes really!). Of course, there are many times when you might write these words legitimately (for example, "Please select a logo from this list").
Anyway, the IPS seems to be partially blocking or truncating the client request, so the Umbraco server was receiving unexpected data. Seems like no validation occurs server-side to check that the client has provided a name or alias for each document type property, so blank strings are saved to the database, hence the problem.
Work arounds?
With 20 years experience in IT, I have a carefully honed belief that well meaning security software and systems can often cause more trouble than they're meant to prevent.
The reason for writing the posts in this blog, is the hope that one day someone will suffer the same problem and stumble across this solution via Google. If so, I hope it helped you.
Any attempt to access content using the corrupted document type in the Umbraco back-office led to a server 500 error:
Multiple controls with the same ID 'prop_' were found. FindControl requires that controls have unique IDsThe only fix was to manually reinstate the individual field values of the affected records, based on a backup copy of the database.
So what could have caused this catastrophe?
We first blamed Umbraco - maybe there was a bug causing the document type save action to fail. But no, nothing in the Umbraco log or the System event log.
I then remembered that our IT department had recently installed a Cisco ASA 5515 Intrusion Prevention System (IPS) firewall "in front" of the web-server. Hmmm... could this system, designed to prevent problems, actually be causing damage? The answer seems to be "yes".
As far as I can tell, it seems that if you POST data containing the word "select" followed somewhere in the request data with the word "from", the Cisco IPS assumes you are attempting an SQL injection attack (yes really!). Of course, there are many times when you might write these words legitimately (for example, "Please select a logo from this list").
Anyway, the IPS seems to be partially blocking or truncating the client request, so the Umbraco server was receiving unexpected data. Seems like no validation occurs server-side to check that the client has provided a name or alias for each document type property, so blank strings are saved to the database, hence the problem.
Work arounds?
- Install an SSL certificate on the server, and do your editing via HTTPS (undecipherable by the IPS). This is probably good practice anyway.
- If possible, perform the editing of document types via a Remote Desktop connection directly to the server (using the Remote Desktop session's browser and http://localhost/umbraco/, thus avoiding the IPS).
- Use a tool such as uSiteBuilder to synchronise your document type and template changes with a Visual Studio project, instead of using the Umbraco back-office.
With 20 years experience in IT, I have a carefully honed belief that well meaning security software and systems can often cause more trouble than they're meant to prevent.
The reason for writing the posts in this blog, is the hope that one day someone will suffer the same problem and stumble across this solution via Google. If so, I hope it helped you.
Comments
Post a Comment