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

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.

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

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.

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?

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

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

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.

ok will give it another shot

Which browser are you using?

I'm using Internet explorer 10 10.0.9200.17148

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

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

No, thats the strange thing.

Hi Tim,

Have you got any ideas what I can check?

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)

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

Ok thanks

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 

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

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

Thanks

Rich

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

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!

Hi Tim,

Hope you had a good Christmas and happy new year.

Have you managed to replicate this issue yet?

Thanks

Rich

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

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.

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

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

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.

Thanks Sebastiaan I will do that for now.

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.

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.

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

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

is working on a reply...