Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Nick Renny 31 posts 63 karma points
    Feb 27, 2013 @ 14:13
    Nick Renny
    0

    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.

    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.

  • Stephen 767 posts 2273 karma points c-trib
    Feb 27, 2013 @ 14:28
    Stephen
    0

    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:

    /* [@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.

    Stephan

  • Nick Renny 31 posts 63 karma points
    Feb 27, 2013 @ 14:29
    Nick Renny
    0

    Thanks for the reply, I'm using 4.11

  • Douglas Robar 3570 posts 4711 karma points MVP ∞ admin c-trib
    Feb 27, 2013 @ 14:32
    Douglas Robar
    0

    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. 

  • Nick Renny 31 posts 63 karma points
    Feb 27, 2013 @ 14:39
    Nick Renny
    0

    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

  • Ian Smedley 97 posts 192 karma points
    Feb 27, 2013 @ 14:43
    Ian Smedley
    1

    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/

     

  • Nick Renny 31 posts 63 karma points
    Feb 27, 2013 @ 14:50
    Nick Renny
    0

    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?

  • Douglas Robar 3570 posts 4711 karma points MVP ∞ admin c-trib
    Feb 27, 2013 @ 14:52
    Douglas Robar
    0

    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. 

     

  • Nick Renny 31 posts 63 karma points
    Feb 27, 2013 @ 14:55
    Nick Renny
    0

    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.

     

  • Ian Smedley 97 posts 192 karma points
    Feb 27, 2013 @ 14:55
    Ian Smedley
    0

    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.

  • Nick Renny 31 posts 63 karma points
    Feb 27, 2013 @ 14:57
    Nick Renny
    0

    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?

  • Douglas Robar 3570 posts 4711 karma points MVP ∞ admin c-trib
    Feb 27, 2013 @ 15:02
    Douglas Robar
    0

    @Nick - Please report it at http://issues.umbraco.org. Thanks! 

  • Stephen 767 posts 2273 karma points c-trib
    Feb 27, 2013 @ 16:38
    Stephen
    0

    Note to all: the error that appears (fatal error) is fixed already in 4.11.5.

  • Nick Renny 31 posts 63 karma points
    Feb 27, 2013 @ 16:40
    Nick Renny
    0

    Hi, I have the error in 6.0

     

  • Stephen 767 posts 2273 karma points c-trib
    Feb 27, 2013 @ 16:41
    Stephen
    0

    Then a bug it is, please create an issue and report the number of the issue here, and I'll address it.

Please Sign in or register to post replies

Write your reply to:

Draft