How Can We Help?
Issue
ASP.Net 4.0+ comes with a very strict built-in request validation, part of it checks for potentially dangerous characters in the URL which may be used in XSS attacks.
In XMPro this issue will normally occur in the following instances:
- A file was uploaded containing an invalid character in the file name and is referenced in the next activityA specific step in a process. It will be the user interface for that step (web form or a screen), for example, the Leave Application (screen interface or web form) will be the first Activity in the Leave Requisition process. The Leave Application Authorization will be the second step or Activity in the Leave Requisition process. One Process can have multiple activities. as a clickable link.
- Some HTML special characters are present in a Simple Text Box or Large Text Box control during any post back event, i.e. the AutoPostBack option is set to true on a control or when submitting the form.
Resolution
Invalid file link
- If the issue is caused by a file that was uploaded in upstream activities or another process in XMPro, check the “ProbihitedFileNameCharacters” setting in the site.config file. If the value is empty it will default to ‘#,&,+,?,/,:’. To add additional characters, supply the default value plus any additional characters separated by a comma, for example: #,&,+,?,/,:,~,’.This will prevent further files from being uploaded with invalid characters but will not change existing values. The XMPro engine will remove the invalid characters when the file is uploaded.
- If it is a link to an existing file already uploaded or references from your site there are the following options:
- The best approach is to remove the special characters from the path. These characters should cause no problem if they are passed not as part of the path but as part of the query string. This will necessitate modifying both the web page which is handling the request and those links (or services) which use it.If you absolutely need to allow one of these characters, then you can change the configuration to allow it. The setting to change is the requestPathInvalidCharacters which is part of the httpRuntime section in the web.config file.
In all likelihood even if you do have a httpRuntime section in your web.config file then you won’t have requestPathInvalidCharacters, so you will need to add it. Be aware that you are using this to specify which characters not to allow, you cannot specify which characters to allow. The default character are “<, >, *, %, &, :, \, ?”.When entering these characters remember to HTML encode them as shown below:<httpRuntime requestPathInvalidCharacters=”<,>,*,%,:,\,?” />
When setting it you can use the empty string, but it is probably better just to remove those characters which you need as show below:
<httpRuntime requestPathInvalidCharacters=”” />
In .Net versions prior to 4.0 you might need to add the requestValidationMode property as well, as shown below:
<httpRuntime requestValidationMode=”2.0″ requestPathInvalidCharacters=”” />
- The best approach is to remove the special characters from the path. These characters should cause no problem if they are passed not as part of the path but as part of the query string. This will necessitate modifying both the web page which is handling the request and those links (or services) which use it.If you absolutely need to allow one of these characters, then you can change the configuration to allow it. The setting to change is the requestPathInvalidCharacters which is part of the httpRuntime section in the web.config file.
- Correct it at the source. This means the following:
- Updating the name of the file in the Repository Directory,
- Changing the name of the file in the fcEventValue table.
- AND if referenced from another database, correct it there.
Text Box Controls
-
- If the issue is caused by XMPro reading a value from a previous activity or a database with HTML characters, there are three options available:
- Replace the Large Text Box with the new HTML Editor Control. Only available in XMPro 6.5 and higher.
- Keep the Large Text Box or Simple Text Box and try and clean the value BEFORE rendering the control using the String.Replace() method, e.g.String text = “This should break</br>this is a new line”;
activity.SetControlValue(“FI1080CheckingChars”, text.Replace(“</br>”,”\n”));The problem with the above is obviously that in the worst case scenario you will need to account for more than one type of html tag. Fortunately, only the </br> or </br > characters need removing when using the XMPro Large Text Box or HTML editor type of control. For a more complete html removal functionality search Google or try this url: https://www.dotnetperls.com/remove-html-tags.
- If the issue is caused by XMPro reading a value from a previous activity or a database with HTML characters, there are three options available:
-
-
- Replace the Large Text Box or the Simple Text Box with a Reference Label. The downside of this is that if there is a lot of content, then everything will be rendered on the form. With a Large Text Box where the ReadOnly property is set to True, a scrollbar will be shown if the content exceeds the height of the control.
-
References
RequestPathInvalidCharacters:
https://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.requestpathinvalidcharacters(v=vs.110).aspx
RequestValidationMode:
https://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.requestvalidationmode(v=vs.110).aspx
Other articles:
http://geekswithblogs.net/renso/archive/2011/08/26/a-potentially-dangerous-request-value-was-detected-from-the-client.aspx
Comments are closed.