wheels: Nested properties let a form update, reassign or delete another record's child rows

Impact

With nestedProperties(), the nested save looks up each posted associated record by the primary key submitted in the request, and does not check that the record belongs to the parent being saved. A user who can submit the form for their own parent record can therefore include the key of a record that belongs to someone else:

• **hasMany: the posted child row is deleted** (when the association uses allowDelete=true, the usual setup for hasManyCheckBox join models), or updated with the posted values. Because the nested save then sets the child's foreign key to the current parent, the row is also moved under the attacker's parent.
• **hasOne**: the same delete, update and move of another parent's record.
• **nested belongsTo: any record of the associated model can be edited** by posting its key.

For composite primary keys that are not made up of foreign keys, the posted key values of new child rows are also kept, so a request can choose the identity of a new row.

Patches

Fixed in 4.2.0. A nested record found by a posted key is only used when it belongs to the parent being saved (scoped by the parent's persisted key, so posting the parent's own id or foreign key can't retarget it); otherwise it is treated as not found. Posted primary-key values on new child rows are cleared, except the join-identity foreign keys.

Workarounds

• Don't use allowDelete=true on nested associations whose child keys come from untrusted input.
• Before saving, verify in the controller that every posted nested child key belongs to the parent being edited, or rebuild the nested struct server-side from the parent's own children.