Workflow Review: Public registration survey targeting a view layer of an internal dataset. Security concerns?

Vinzafy · ‎05-08-2023

Hey all,

Creating this post to get some feedback on whether there are any security issues with this workflow I've created for public event registration linking to an internal dataset.

Overview

For events that my organization hosts, an idea was posed to enable attendees to self-register. This puts the onus on attendees to properly enter their information and reduces the admin burden of team members to manually enter values from an attendance sheet.

As the event utilizes Survey123, the data structure is such that event details (e.g., location, date, type, etc.) are in the parent spatial layer, and attendees for that event are then stored in a related table.

The idea was to give participants the ability to add records to the related table via a public survey containing a handful of relevant fields.

Workflow

From the internal hosted feature layer, a view layer was created specifically for the attendance related table that only contained fields applicable to self-registration (i.e., name, email, etc.). The settings for this view layer enable anonymous users to only add new features and does not allow editors to see any features.

Additionally, the view layer has a filter set as another layer of security (more detail below).

A new survey was created that participants will use to self-register. The submission URL points directly to the public hosted view layer, and the form id to the attendance related table.

Additionally, there is a hidden status field which defaults all new records to "Pending". This is what the view layer is filtered for.

Back on the internal parent survey, once users self-register, they appear in the attendance repeat as that is the table the public view layer adds data to. When the internal survey is submitted, it automatically changes the status of attendance records from "Pending" to "Active" and thus filters it out from the public view layer.

Question

The main concerns I have with this workflow are if it could unintentionally expose any internal data, as a portion of the dataset is open to the public.

A test public view layer with the same settings can be found at the following link:

Testing - Public View

As a "public" user (i.e., using an account not in that organization), I'm only able to see the item page if I know the item ID but I can't see any records (this is ideal).

The area that gives the most information is the rest services directory page where I can see the schema of fields in the view layer.

There are a few operations available (screenshot below) though I'm not sure how to use those or if public users could utilize those.

Ultimately the big question is the following:

Could this workflow unintentionally expose our internal dataset or act as a channel for non-organizational users to access our internal data? If so, is there a better way to achieve this?

Sample XLSForms that are excerpts of both the public survey and internal survey are found here.

In an ideal scenario, the only info a user is able to access is the schema for the fields exposed to the public. They should not be able to see any of the data (stored in either the internal feature layer or public view layer), or add/edit any data (though I imagine folks may be able to add data via JSON if knowledgeable enough).

Any feedback or suggestions are much appreciated!

Vinzafy · ‎05-09-2023

UPDATE

After playing around with the REST services page using an external account, I tested a few things:

On the REST services page, as expected, features can be added to the layer which matches the settings (i.e., anonymous users can add new features).
I tested the update and delete operations as well and as expected, none of the features could be altered or deleted using JSON via the REST services page. This is good!
In a worst case, someone could theoretically run a loop and continuously add data to a public view layer where editing is enabled. However, that would require the user knows the unique ID of the view layer and takes the time to put that together.
If that does happen, editing can be prevented by turning off editing. Furthermore, the view layer can be deleted to prevent future submissions as the user would have obtained the item ID. Though it is possible, it does seem like an extreme case.

Some things I noticed that would be visible to anonymous users via the REST services page are the following:

The schema of the fields added to the view layer
All layers within your organization that are available to the public

There may be more, but that's what I found through some brief testing. I can't say for certain whether or not a public layer could be a potential channel for a knowledgeable user to gain access to internal data. However, it seems like there are a lot of barriers inherent to public datasets in addition to those that you can add yourself as prevention measures.