Copied to clipboard

Flag this post as spam?

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


  • Richard Galt 64 posts 230 karma points
    Dec 08, 2014 @ 15:51
    Richard Galt
    0

    Contour XSS vulnerability

    Last week we had external penetration testers check our new site and they identified a cross-site scripting vulnerability which allows you to embed an iframe and then execute scripts from an input field.

    Out of the box should Contour have some form of server side sanitisation / html encoding of the response?

    I must admit there was not adequate client side validation of the input field but this is easy enough to implement.

    Any help would be much appreciated.

  • Comment author was deleted

    Dec 08, 2014 @ 15:53

    Hey Richard,

    The entries viewer should sanitize this input, so it should not be possible to run this script in the contour section of the backoffice, of course if you are outputting records in your frontend make sure to do the html encoding there to

  • Richard Galt 64 posts 230 karma points
    Dec 08, 2014 @ 16:01
    Richard Galt
    0

    Hi Tim,

    The issue is with the front end (completing the form). If say for example this code <iframe src=//hx.lc> is input into a field it gives a response e.g.

    before

    after

  • Comment author was deleted

    Dec 08, 2014 @ 16:06

    Ok there is no client side sanitition of the fields before they are submitted to the server... is this what you say is missing?

  • Richard Galt 64 posts 230 karma points
    Dec 08, 2014 @ 16:22
    Richard Galt
    0

    No the problem occurs when you submit the form to the server the response is uuencoded and executed.

    Pen testers comments:

    Tainted data submitted to the application is insecurely embedded within the page body. To exploit this flaw the attacker could submit HTML mark-up designed to execute JavaScript.

    The execution of the user defined script code appears to be prevalent across multiple form parameters within the affected application, and it should be ensured that each parameter is correctly validated for input and that all appropriate characters are HTML encoded if used to form part of the applications response message.

    The form fields within the application are vulnerable to Cross Site scripting attacks because although input validation appears to be detecting inappropriate input being supplied by the user, the response from the application still reflects that input within its response message without adequate HTML encoding. The reflected user input does seem to be restricted to a 20 character maximum, however this is still enough to allow for the execution of script code.

  • Comment author was deleted

    Dec 08, 2014 @ 16:36

    Ok thanks for the extra details but can't reproduce when I create a form and then enter the iframe code it does output the potentially dangerous message but it doesn't output the field, so not sure how  your form is setup, do you have a test install I could take a look at?

  • Richard Galt 64 posts 230 karma points
    Dec 08, 2014 @ 16:48
    Richard Galt
    0

    Tim unfortunately we don't have a test environment available externally. Do you have any ideas where I should start looking?

  • Comment author was deleted

    Dec 08, 2014 @ 16:49

    Or if you can provide steps in which to reproduce, since I can't get the script to alert like in your example

  • Richard Galt 64 posts 230 karma points
    Dec 08, 2014 @ 16:50
    Richard Galt
    0

    I have just created a new form with a single text field and no workflow stages. I've added the form to a content page using the rich text editor macro and still have the same issue.

  • Comment author was deleted

    Dec 08, 2014 @ 16:51

    ok will give it another shot

  • Comment author was deleted

    Dec 08, 2014 @ 16:59

    Which browser are you using?

  • Richard Galt 64 posts 230 karma points
    Dec 08, 2014 @ 17:00
    Richard Galt
    0

    I'm using Internet explorer 10 10.0.9200.17148

  • Richard Galt 64 posts 230 karma points
    Dec 08, 2014 @ 17:19
    Richard Galt
    0

    But the latest version of chrome and firefox still render the iframe even if the script is not executed.

  • Comment author was deleted

    Dec 09, 2014 @ 12:24

    Are you outputting the submitted record data? Since I don't seem to be able to render the iframe with the default settings

  • Richard Galt 64 posts 230 karma points
    Dec 09, 2014 @ 12:38
    Richard Galt
    0

    No, thats the strange thing.

  • Richard Galt 64 posts 230 karma points
    Dec 10, 2014 @ 11:41
    Richard Galt
    0

    Hi Tim,

    Have you got any ideas what I can check?

  • Comment author was deleted

    Dec 10, 2014 @ 15:48

    On the form settings, do you have anything special on the thank you message on submit? 

    If possible can you send me the site tthat way I can debug locally (tg at umbraco dot com)

  • Richard Galt 64 posts 230 karma points
    Dec 10, 2014 @ 16:03
    Richard Galt
    0

    Hi Tim,

    there is nothing special about the thank you message on submit. I have spoken to Kevin at Jumoo as he has provided some custom workflows for us and he will be responding to this post with his findings and we will go from there.

    Thanks

    Rich

  • Comment author was deleted

    Dec 10, 2014 @ 16:04

    Ok thanks

  • Kevin Jump 2309 posts 14673 karma points MVP 7x c-trib
    Dec 15, 2014 @ 11:37
    Kevin Jump
    0

    Hi

    I can recreate this problem on a blank Umbraco 7.1.9 build with Contour 3.0.23-Build20 with a single text entry from, a basic template that just renders a content block for the form to be in no workflow, no prevalues, just a single entry form. 

    As Richard said on Chrome you just get a frame and on IE11 you get an alert box pop up.

    when potentially dangerous code is detected in the field, the error writes that code out as part of the message 

    A potentially dangerous Request.Form value was detected from the client (d0351455-99e4-40b5-9b50-8ae16b61ab3a="<codehere>").

    I can't find a Contour setting to turn this off or change the message, and the error is trapped before any of the views are called so you can't change the message or do anything with it there either. 

    Kevin 

     

     

     

     

  • Comment author was deleted

    Dec 15, 2014 @ 11:45

    Ok thanks for the additional details, will see if I can get the same result

  • Richard Galt 64 posts 230 karma points
    Dec 17, 2014 @ 14:27
    Richard Galt
    0

    Hi Tim have you had a chance to look at this yet?

    Thanks

    Rich

  • Comment author was deleted

    Dec 17, 2014 @ 15:51

    Yup currently looking into this, will have an update later this week and will post it here

  • Jasper Neve 2 posts 22 karma points
    Dec 18, 2014 @ 17:01
    Jasper Neve
    0

    We just reproduced the reported issue and then found this post. Although not exploitable, <script> insertion are generally regarded as very dangerous and will not be regarded well by our clients.

    Is there any idea about when a fix might be issued, or a known workaround?

    Thank you!

     

  • Richard Galt 64 posts 230 karma points
    Jan 05, 2015 @ 10:11
    Richard Galt
    0

    Hi Tim,

    Hope you had a good Christmas and happy new year.

    Have you managed to replicate this issue yet?

    Thanks

    Rich

  • Comment author was deleted

    Jan 05, 2015 @ 12:32

    Hey Rich,

    Happy 2015 :) yes I'm able to reproduce it now. Looks like this will need to be handled in the Umbraco Core since the error isn't outputted by Contour but by the core code handling macros. I'll add this to the issue tracker

  • Jasper Neve 2 posts 22 karma points
    Jan 05, 2015 @ 12:40
    Jasper Neve
    0

    Hi Tim, Rich,

     

    Thank you both for your posts on this topic, saved us lots of time trying to research. 

    Looking forward to a future update.

     

     

  • Richard Galt 64 posts 230 karma points
    Jan 05, 2015 @ 12:41
    Richard Galt
    0

    Hi Tim,

    oh good news, it's not just me :)

    Can you link the issue when you log it for my reference. As a Government organisation there are strict security checks we have to make every year and with this identified our Beta site can't be published until this is fixed.

    Do you know how long this will take to be fixed? Are we talking weeks or months?

    Thanks

    Rich

  • Comment author was deleted

    Jan 05, 2015 @ 12:42

    Sure thing the issue is http://issues.umbraco.org/issue/U4-6069 , will check with Core team but looks like an easy fix so not that long

  • Sebastiaan Janssen 5044 posts 15475 karma points MVP admin hq
    Jan 07, 2015 @ 09:45
    Sebastiaan Janssen
    0

    I would recommend for the time being to go into your umbracoSettings.config file and setting <MacroErrors>silent</MacroErrors>. If you do that no errors whatsoever will be shown any more so I also recommend handling the errors either using the umbraco.macro.Error event or the .net Application_OnError event. Using those events you can log errors and perform other actions you want.

    While this won't allow you to replace the default error message that's inline to the page, you could (and probably should) then throw an exception. You could also set <MacroErrors>throw</MacroErrors> to make ALL failing macros throw an exception.

    I hope this helps for now until the issue can be fixed in an upcoming release of Umbraco.

  • Richard Galt 64 posts 230 karma points
    Jan 07, 2015 @ 10:21
    Richard Galt
    0

    Thanks Sebastiaan I will do that for now.

  • Shannon Deminick 1524 posts 5269 karma points MVP 2x
    Jan 08, 2015 @ 02:10
    Shannon Deminick
    0

    I'm working on a fix now but you will actually have to use your own custom error hander as a work around since this issue comes from ASP.Net itself when we call ExecutePageHierarchy to execute this macro ASP.Net performs an entire server pipeline execution for the macro and outputs what it needs to. The exception cannot actually be caught. Here's a couple of references:

    http://romsteady.blogspot.com.au/2007/06/how-to-catch-httprequestvalidationexcep.html

    http://stackoverflow.com/questions/5028206/how-to-catch-httprequestvalidationexception-in-production

    That said, I'm working on a fix that will automatically handle this but in the meantime you'll need to handle it on your own. To do this properly you'll need to creat

    Umbraco.Web.UmbracoApplication

    Then you'll need to override OnApplicationError to handle the error (like in those links mentioned above)

    Then you'll need to update your global.asax file to use your custom class instead of the Umbraco.Web.UmbracoApplication class.

  • Shannon Deminick 1524 posts 5269 karma points MVP 2x
    Jan 08, 2015 @ 06:20
    Shannon Deminick
    0

    Hi all,

    I've updated this issue with complete details on why this is happening:

    http://issues.umbraco.org/issue/U4-6069

    It is a Contour issue after all, not a core issue.

  • Comment author was deleted

    Jan 22, 2015 @ 14:21

    Latest nightly includes the fix http://nightly.umbraco.org/Umbraco%20Contour/3.0/, we'll release a new version today

  • Comment author was deleted

    Jan 22, 2015 @ 14:43

    Version 3.0.24 is out containing the fix, upgrade instructions can be found here http://our.umbraco.org/projects/umbraco-pro/contour/documentation/Installation/Upgrade

Please Sign in or register to post replies

Write your reply to:

Draft