Answered by:
Infopath 2010 Forms Services Input Sanitization (Cross Site Scripting protection)

Question
-
I am working on a project that makes heavy use of Infopath Forms in SharePoint.
During a security evaluation, it was noted that a Cross Site Scripting vulnerability exists in the application due to the fact that Infopath does not seem to do any sort of checking for "suspicious" characters < > " ' % ; ( ) & + that might indicate a possible attempt at a XSS injection attack.
Can Infopath Forms Services be configured to reject / cleanse submissions contains such content?
If not, are there any recommendations for how to achieve a similar result using code?
Thursday, June 28, 2012 4:16 PM
Answers
-
Can you give me a little more detail in where you're seeing this risk?
The only control in an InfoPath form that would potentially accept a script block would be the rich text control, because it works with XHTML. Let's say I start with scripted content like this:
<html>
<body>
Text before script block.<br>
<script language="vbscript">alert("a")</script>
Text after script block.
</body>
</html>If I open that content in Internet Explorer, I get a little popup dialog, so we know the script is active. If i copy that content from Internet Explorer and paste it into a rich text control in an InfoPath browser form, I get:
Text before script block.
Text after script block.
If I save the form and then open it with a text editor like notepad, I see that the raw data is:
<html xmlns="http://www.w3.org/1999/xhtml" xml:space="preserve"><p><span id="ms-rterangepaste-start"></span>Text before script block.<br />Text after script block. </p><p><span id="ms-rterangepaste-end"></span></p></html>
Note that the script block is missing. In fact, it can be demonstrated that he script block was never even sent to the server when the browser form was saved.
Are you seeing some other vector by which script could be injected into an InfoPath form?
Regards, Joel Alley - Microsoft Online Community Support
- Proposed as answer by Joel Al - MSFT Monday, July 2, 2012 7:55 PM
- Marked as answer by 许阳(无锡) Tuesday, July 10, 2012 10:58 AM
Monday, July 2, 2012 7:55 PM
All replies
-
Hi JimDavisGray,
Thanks for posting in the MSDN Forum.
I will involve some experts into your issue to see whether they can help you out. There might be some time delay, appreciate for your patience.
Have a good day,
Tom
Tom Xu [MSFT]
MSDN Community Support | Feedback to us
- Proposed as answer by Sujit Sukumaran MCP Wednesday, March 6, 2013 5:31 PM
Friday, June 29, 2012 5:25 AM -
Can you give me a little more detail in where you're seeing this risk?
The only control in an InfoPath form that would potentially accept a script block would be the rich text control, because it works with XHTML. Let's say I start with scripted content like this:
<html>
<body>
Text before script block.<br>
<script language="vbscript">alert("a")</script>
Text after script block.
</body>
</html>If I open that content in Internet Explorer, I get a little popup dialog, so we know the script is active. If i copy that content from Internet Explorer and paste it into a rich text control in an InfoPath browser form, I get:
Text before script block.
Text after script block.
If I save the form and then open it with a text editor like notepad, I see that the raw data is:
<html xmlns="http://www.w3.org/1999/xhtml" xml:space="preserve"><p><span id="ms-rterangepaste-start"></span>Text before script block.<br />Text after script block. </p><p><span id="ms-rterangepaste-end"></span></p></html>
Note that the script block is missing. In fact, it can be demonstrated that he script block was never even sent to the server when the browser form was saved.
Are you seeing some other vector by which script could be injected into an InfoPath form?
Regards, Joel Alley - Microsoft Online Community Support
- Proposed as answer by Joel Al - MSFT Monday, July 2, 2012 7:55 PM
- Marked as answer by 许阳(无锡) Tuesday, July 10, 2012 10:58 AM
Monday, July 2, 2012 7:55 PM -
Joel,
We are building a case management application where we are using InfoPath as the primary data collection vehicle (i.e. a forms builder), but in which the data collected is utilized many places outside of the InfoPath form. Here is one simple expample of a use case we need to tighten up...
The InfoPath form used to create a new case has a text field called CaseName (along with many other fields). When the form is submitted, a new case is created in the system.
We have another screen called CaseOverview that renders a top line overview of any given case. This page (which is not an infopath form) contains a link that is built from the case name. Clicking on the link opens the full infopath view of the form. When"My Case Name" was used as the name of the case it will render like this...
<a href="FormViewer.aspx?CaseId=103">My Case Name</a>
What we have noticed is that if you build the case name correctly, it is possible to inject arbitrary script into the page (XSS). If we enter...
</a><script>alert("Hello XSS");</script>
as the CaseName when initiating the case, the script will fire when the CaseOverview screen loads.
If we need to write code to check / manage this sort of input on our side, that can definitely be done but I wanted to make sure I wasn't missing something that is built into the platform before doing so.
Thanks,
Jim
Monday, July 2, 2012 9:33 PM -
Hi Jim,
It sounds like there is a cross-site scripting vulnerability in your CaseOverview page, rather than in InfoPath. It's true that InfoPath does not verify that user input doesn't contain HTML script (except in the cases I've already mentioned with the Rich Text control), but it never puts user content in a place that it could run, so there is no risk. Since your CaseOverview page does put user content in a place where it could run, you need to verify it's safe first.
That being said, InfoPath can definitely help you with that validation. One easy way would be with a validation rule. Try this:
- Open the form template in design mode.
- Select the "MyCaseName" field in your form.
- On the "Home" tab of the ribbon, click "Manage Rules" in the "Rules" group.
- Add a new "Validation" rule.
- Set the ScreenTip to warning text to tell your user what's wrong: "HTML characters are not accepted", or whatever else you might like.
- Set the condition of the rule to be true when the field has unacceptable characters. For example, I used:
"MyCaseName" "contains" "<" or "MyCaseName" "contains" ">"
Now, when users fill out the form, if they enter a "<" or ">" character, the validation rule will flag the field as invalid and will prevent them from submitting the form until they correct the problem.
Regards, Joel Alley - Microsoft Online Community Support
- Proposed as answer by Joel Al - MSFT Wednesday, July 18, 2012 2:58 PM
Wednesday, July 18, 2012 2:58 PM -
I work with an app that has a similar vulnerability, but it's SP/InfoPath 2007. Does the same config fix apply to that technology? Apologies if its an obvious question, but as my employer outsources all our development I'm not close enough to the technology to know the specifics...
Tuesday, September 25, 2012 7:23 AM