Does Survey123 create vulnerabilities?

[AdamAull]

Suppose a Survey123 form was set to collaborate (shared) with everyone. This form contains text boxes, etc and includes the option to attach files. Additionally the form sends data to a hosted feature layer on a local ArcGIS Portal. Is the form vulnerable to malicious attacks? The attacks would include SQL Injection and macro attachments. In other words, how vulnerable is the local Portal to attacks when Survey123 is shared for crowdsourcing data?

[JamesTedrick]

Hi,

The question about preventing attacks from data is one that affects all editing applications, not just Survey123.  This is addressed through the configuration of the ArcGIS Server settings. In particular, your ArcGIS Server should have 'Standardized Queries' enforced (this is the default for ArcGIS Server) - this will mean that the submissions will be checked for potentially malicious queries and that only a select subset of keywords are allowed.

Aside from this, I would also encourage removing the query capability on submission feature services/feature layer views that are shared publicly - this will prevent data from the feature service from being extractable from the submission endpoint.

Looking at ArcGIS Enterprise overall, I would also encourage you to review ArcGIS Enterprise implementation guidance—ArcGIS Trust Center | Documentation from our Trust/Security center; also feel free to raise questions in Esri Software Security & Privacy or Implementing ArcGIS 

[ThomasColson]

I had (still have) a very similar question. From IIS 8.5 Site Security Technical Implementation Guide :: Version 1, Release: 9 Benchmark Date: 25 Oct 2019: " "Allow unlisted file name extensions" check box is checked, this is a finding."

But from Problem: Unable to connect to basic functionality in Portal for ArcGIS: "Portal for ArcGIS and its underlying processes use many custom file extensions. Access to these file extensions is limited when the 'Allow unlisted file name extensions', 'Allow unlisted verbs', and 'Allow high-bit characters' options are disabled in the Request Filtering section of IIS Manager. Group policy dictates the enabled/disabled settings in IIS Manager, and they may be disabled for security purposes."which "appears" to be in conflict with the STIG. There's a reason why group policy turns those settings on. 

If you really wanted to sleep secure, I'd tweak Request Filtering on your IIS instance to allow only what file extensions you want coming in with your surveys. Or, put your survey on AGOL and use Jame's syncing python thingy, which I'm hoping he updates to Py 3.6 soon! to sync the survey results to an on prem instance where you scan the file attachments on the way (that's what I do). 

With recent world events resulting in a sky-is-falling response in the ITSEC community, I suspect this topic will command my attention soon. 

[JamesTedrick]

Hi Thomas,

This would be best to bring to the Esri Software Security & Privacy‌ or Implementing ArcGIS‌ to address these ArcGIS Enterprise configuration concerns.

[RandallWilliams]

The Esri Software Security and Privacy team has a list of file extensions to add to the 'allowed' list that is currently available upon request. The document is currently in a raw format and is intended to be included in an upcoming ArcGIS Enterprise hardening guidance document.

[MattFancher1]

Sorry to dig up this old thread, but how do you request the list of allowed file extensions? Via support? Also has the "ArcGIS Enterprise hardening guidance document" mentioned above been published?