Hi I need an answer for a security test which has revealed they can create errors (but say they don't have time to exploit it) by adding xpath query to the end of urls.
I've found a response from Niels which seems reasonable, but is from 2006 - could someone verify this for me? I need to get the project live, and the client won't go live without some response.
Here's the deal - you can't inject xpath because the way umbraco uses the
url is by splitting it by slashes and inserting each section in the
following syntax:
node [@nodeName "text"]
So the only thing you can change is the text between the quotes. IIS and
.NET doesn't allow you to add quotes (or even escaped ones) to the url (only
as a part of a querystring, so you can't inject xpath syntax, only suggest
that the nodeName should have a weird title.
Even if you could - what could happen? The runtime only runs on published
data, xpath is only for reading - not modifying input, so the worst case
scenario (which isn't even close) would be that you could see a published
page that wasn't linked. But even there the internal protection mechanism in
umbraco would start if the page was protected (which it should if it's
sensitive and published) you'd still be asked for password etc.
At least in 4.11.5 the XPath is built by splitting the string at slashes, then contatenating. For /foo/bar that would give something like:
/* [@isDoc and @urlName="foo"]/* [@isDoc and @urlName="bar"]
Now, if a fragment of the path contains either a quote or an apostrophe, then the XPath will be something like:
/* [@isDoc and @urlName=$var1]/* [@isDoc and @urlName=$var2]
And we're using XPath variables for the values, thus avoiding the potential injections -- same as SQL parameters.
Is that the type of answer you're looking for? If so, you'll need to tell me which version you're running so I can tell you if it has that mechanism in already. If it has not... then I guess it is possible to inject things into the XPath query. But as Niels said, then what? You'd find another node. If it's public then no big deal, if it's protected then the protection will protect it anyway.
I'm not sure I see the problem... an error is totally valid when a bad url is input. There's no "security" risk there.
Of course you can make a custom 404/Not Found page for your site so you get a "Sorry, the page you're looking for isn't available" kind of page rather than the "this page intentionally left ugly" default error page in Umbraco. Or the standard .NET error page (generally a YSOD saying you can't use illegal characters in the url), which again isn't a security risk.
Can anyone provide a sample url that causes a legitimate concern?
Good idea, I'll suggest that too, this is an example response currently - created by adding a'a to the url. I need to check if the 404 is setup correctly, this error is simply a bad page request, then the output should be able to be switched off in the web.config and perhaps I've missed it somewhere.
[XPathException: '/root/* [@isDoc]/* [@isDoc and @urlName='a'a']' has an invalid token.]
The thing here is that it's not raising a 404, it's throwing An unhandled exception occurred during the execution of the current web request. So how do I stop it doing that? and get it to raise a 404?
Great example! Not that anything is revealed that is sensitive. Still... to get rid of the YSOD's being display you'd need to update your web.config to show a custom error page (which can be the same page you use for your 404's if you like)
You can also use RemoteOnly and other settings on the customErrors tag but I'll leave that to you and google to figure out what options you might prefer to use.
My only concern here is that the issue isn't handled like a bad page request by the code, but creates an unhandled error, that's got to be wrong surely? I can hide it of course, but it doesn't solve the issue that it should raise a 404, not an unhandled exception.
Yes - I can confirm this behaviour - it's throwing an YSOD page - rather than a 404...
Happens in 4.11 but not in 4.5
I guess for security reasons it's best to make sure custom Errors are on for production - but perhaps this should be raised as a bug - so that the previous 404 behaviour is replicated, as this is more meaningful for a user - rather than a generic 'server error' page.
yes, I'll implement the changes and a 404 page, and see if that get's it through the test, it happens in 6 too, but not in 4.7. How do I raise it as a bug?
Xpath Injection Vulnerability
Hi I need an answer for a security test which has revealed they can create errors (but say they don't have time to exploit it) by adding xpath query to the end of urls.
I've found a response from Niels which seems reasonable, but is from 2006 - could someone verify this for me? I need to get the project live, and the client won't go live without some response.
Which version?
At least in 4.11.5 the XPath is built by splitting the string at slashes, then contatenating. For /foo/bar that would give something like:
Now, if a fragment of the path contains either a quote or an apostrophe, then the XPath will be something like:
And we're using XPath variables for the values, thus avoiding the potential injections -- same as SQL parameters.
Is that the type of answer you're looking for? If so, you'll need to tell me which version you're running so I can tell you if it has that mechanism in already. If it has not... then I guess it is possible to inject things into the XPath query. But as Niels said, then what? You'd find another node. If it's public then no big deal, if it's protected then the protection will protect it anyway.
Stephan
Thanks for the reply, I'm using 4.11
I'm not sure I see the problem... an error is totally valid when a bad url is input. There's no "security" risk there.
Of course you can make a custom 404/Not Found page for your site so you get a "Sorry, the page you're looking for isn't available" kind of page rather than the "this page intentionally left ugly" default error page in Umbraco. Or the standard .NET error page (generally a YSOD saying you can't use illegal characters in the url), which again isn't a security risk.
Can anyone provide a sample url that causes a legitimate concern?
cheers,
doug.
Good idea, I'll suggest that too, this is an example response currently - created by adding a'a to the url. I need to check if the 404 is setup correctly, this error is simply a bad page request, then the output should be able to be switched off in the web.config and perhaps I've missed it somewhere.
[XPathException: '/root/* [@isDoc]/* [@isDoc and @urlName='a'a']' has an invalid token.]
MS.Internal.Xml.XPath.XPathParser.CheckToken(LexKind t) +5123977
MS.Internal.Xml.XPath.XPathParser.ParsePredicate(AstNode qyInput) +92
MS.Internal.Xml.XPath.XPathParser.ParseStep(AstNode qyInput) +412
MS.Internal.Xml.XPath.XPathParser.ParseRelativeLocationPath(AstNode qyInput) +21
MS.Internal.Xml.XPath.XPathParser.ParseRelativeLocationPath(AstNode qyInput) +80
MS.Internal.Xml.XPath.XPathParser.ParseRelativeLocationPath(AstNode qyInput) +80
MS.Internal.Xml.XPath.XPathParser.ParseLocationPath(AstNode qyInput) +136
MS.Internal.Xml.XPath.XPathParser.ParsePathExpr(AstNode qyInput) +62
MS.Internal.Xml.XPath.XPathParser.ParseUnionExpr(AstNode qyInput) +27
MS.Internal.Xml.XPath.XPathParser.ParseMultiplicativeExpr(AstNode qyInput) +41
MS.Internal.Xml.XPath.XPathParser.ParseRelationalExpr(AstNode qyInput) +29
MS.Internal.Xml.XPath.XPathParser.ParseEqualityExpr(AstNode qyInput) +29
MS.Internal.Xml.XPath.XPathParser.ParseOrExpr(AstNode qyInput) +27
MS.Internal.Xml.XPath.QueryBuilder.Build(String query, Boolean allowVar, Boolean allowKey) +
91
System.Xml.XPath.XPathExpression.Compile(String xpath, IXmlNamespaceResolver nsResolver) +53
System.Xml.XPath.XPathNavigator.Select(String xpath) +21
System.Xml.XmlNode.SelectSingleNode(String xpath) +88
Umbraco.Web.DefaultPublishedContentStore.GetDocumentByRoute(UmbracoContext umbracoContext, S
tring route, Nullable`1 hideTopLevelNode) +884
Umbraco.Web.Routing.LookupByNiceUrl.LookupDocumentNode(PublishedContentRequest docreq, Strin
g route) +1887
Umbraco.Web.Routing.LookupByNiceUrl.TrySetDocument(PublishedContentRequest docRequest) +422
Umbraco.Web.Routing.PublishedContentRequestBuilder.<LookupDocument>b__1b(IPublishedContentLo
okup lookup) +86
System.Linq.Enumerable.Any(IEnumerable`1 source, Func`2 predicate) +149
Umbraco.Web.Routing.PublishedContentRequestBuilder.LookupDocument() +753
Umbraco.Web.Routing.PublishedContentRequest.ProcessRequest(HttpContextBase httpContext, Umbr
acoContext umbracoContext, Action`1 onSuccess) +685
Umbraco.Web.UmbracoModule.ProcessRequest(HttpContextBase httpContext) +1211
Umbraco.Web.UmbracoModule.<Init>b__7(Object sender, EventArgs e) +172
System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
+270
I agree with Doug - add a custom 404 and then it won't seem to be an error page.
Also - security guys don't like YSODs - it could reveal the server name or internal IP which is a big PCI-DSS no-no apparently.
None of our site scans have ever revealed an xPath vulenerability...
I like this site for checking your website for standard stuff - like YSODS etc:
https://asafaweb.com/
The thing here is that it's not raising a 404, it's throwing An unhandled exception occurred during the execution of the current web request. So how do I stop it doing that? and get it to raise a 404?
Great example! Not that anything is revealed that is sensitive. Still... to get rid of the YSOD's being display you'd need to update your web.config to show a custom error page (which can be the same page you use for your 404's if you like)
<customErrors mode="On" defaultRedirect="/en/404.aspx" />
You can also use RemoteOnly and other settings on the customErrors tag but I'll leave that to you and google to figure out what options you might prefer to use.
cheers,
doug.
My only concern here is that the issue isn't handled like a bad page request by the code, but creates an unhandled error, that's got to be wrong surely? I can hide it of course, but it doesn't solve the issue that it should raise a 404, not an unhandled exception.
Yes - I can confirm this behaviour - it's throwing an YSOD page - rather than a 404...
Happens in 4.11 but not in 4.5
I guess for security reasons it's best to make sure custom Errors are on for production - but perhaps this should be raised as a bug - so that the previous 404 behaviour is replicated, as this is more meaningful for a user - rather than a generic 'server error' page.
yes, I'll implement the changes and a 404 page, and see if that get's it through the test, it happens in 6 too, but not in 4.7. How do I raise it as a bug?
@Nick - Please report it at http://issues.umbraco.org. Thanks!
Note to all: the error that appears (fatal error) is fixed already in 4.11.5.
Hi, I have the error in 6.0
Then a bug it is, please create an issue and report the number of the issue here, and I'll address it.
is working on a reply...