Don't Ignore the HttpRequestValidationException
Index
Overview
No Sitecore implementation would be complete without an onslaught of the log error:
System.Web.HttpRequestValidationException: A potentially dangerous ______ value was detected
Where the blank might be Request.Cookies
, Request.Form
, Request.Path
, Request.QueryString
, or Request.Url
.
This class of errors is extremely common and can be caused by a variety of factors, all of which stem from the fact that an incoming request contains what .NET perceives to be potentially dangerous. It is a security feature of .NET to prevent cross-site scripting attacks and other security issues.
While many devs consider this class of errors to be a nuisance, I argue that they deserve more attention than they are given.
Error Variations
A potentially dangerous Request.Cookies value was detected from the client
A potentially dangerous Request.Form value was detected
A potentially dangerous Request.Path value was detected
A potentially dangerous Request.QueryString value was detected
A potentially dangerous Request.RawUrl value was detected
A potentially dangerous Request.Url value was detected
How to Reproduce the Issue
For whichever class of this error you are trying to reproduce, include values that contain characters such as <
>
-- those which are commonly used to exploit XSS vulnerabilities. While you're at it, you can also test a variety of other characters such as:
<
>
"
'
&
;
(
)
[
]
{
}
^
@
_
-
~
=
'
:
\/
;
!
$
#
&
\\
,
+
<
.
Dangerous Values vs. Non-Dangerous Values
The phrase 'potentially dangerous' implies that the inputs may or may not actually be dangerous. This is a critical distinction that can be forgotten because, almost always, the inputs are dangerous because they are triggered by malicious bots doing script-kiddy tier reconnaissance. But, there are also cases where the inputs are not dangerous.
When performing analysis, ask these key questions:
- Is the value actually dangerous?
- Who triggered the error? Was it a bot or a human?
- Can WAF rules be adjusted to prevent this error?
- What was the action that triggered the error (simple GET request, form submission, etc)?
The Most Concerning Variation: Form Values
Let's focus on this variation:
A potentially dangerous Request.Form value was detected
If you inspect the path by which this error is triggered, you may find that it corresponds with a custom form or a Sitecore form (via the path /formbuilder
).
If you are seeing this error on a form path, it means that your site likely returned 500 error response and that the form submission was not processed.
What if the form submission was a contact form? A lead generation form? A newsletter signup form?
Perhaps the most interesting example is a form with password field. Presumably, users should be able to enter almost any character in a password field (including <
and >
). If you are seeing this error get triggered by a form value that looks like it could be a password, then one or more of the following may be true: someone can't log in, set their password, reset their password, or create an account.
Conclusion
False positives of non-dangerous values can have brutal consequences. It can result in a loss of data, a loss of customer trust, and a loss of revenue.
Adjust your WAF rules to reduce the noise from the malicious bots. Be thoughtful when composing your WAF rules so as to not block non-dangerous values. When the errors come in after those adjustments, take them seriously. They may be a sign of a larger issue.
Stay dangerous,
MG