Fix cross-store IDOR gaps in Grand.Web.Store

[KrzysztofPajak]

Resolves: no tracked issue - internal security audit of the store-owner/store-manager panel (Grand.Web.Store), analogous to the earlier Grand.Web.Vendor audit (#782).
Type: bugfix

Issue

Audited every controller in src/Web/Grand.Web.Store (the store-owner/store-manager panel, scoped by WorkContext.CurrentCustomer.StaffStoreId) for IDOR-style gaps: entities loaded by an id from the request and mutated without verifying they belong to the current store manager's store.

Found:

• ProductController: ~20 sub-resource mutation actions (category/collection/related/similar/bundle/cross-sell/recommended/associated product mappings, pictures, spec attributes, prices, tier prices, attribute mappings/values) had no ownership check at all, even though the paired GET/list action next to each of them did. A store manager could mutate these sub-resources on any product in any store.
• CategoryController/CollectionController: ProductUpdate/ProductDelete/ProductAddPopup mutate the product's category/collection list, not the category/collection entity - the missing check was on the product, not the category/collection.
• MerchandiseReturnController.MerchandiseReturnNoteAdd: an unchecked orderId parameter was used to build a customer-facing notification email, letting a manager forge/misdirect it using another store's order data.
• NewsController.List: scoped by request host (StoreContext.CurrentStore) instead of StaffStoreId, letting the result set diverge from the manager's actual store depending on which host the panel is reached through.
• ShippingController.RestrictionSave: mutated restricted-countries/restricted-groups on global (store-independent) shipping methods returned alongside store-owned ones, not just store-owned methods.
• MessageTemplateController.Edit/Delete and SettingController's IsStoreOwnerAccessAllowed (used by MerchandiseReturnReason/Action) used a non-exclusive "is my store one of the assigned stores" check instead of requiring exclusive ownership, letting one store's manager edit-and-reassign-away or delete an entity another store still depends on.

Along the way, also found and cleaned up a related code-quality issue the user flagged: ViewBag used as an untyped data carrier between controller and view in this area.

Solution

• Added entity.AccessToEntityByStore(StaffStoreId) / entity.StoreId == StaffStoreId checks on the loaded entity immediately before every mutation identified above, matching the pattern already used consistently elsewhere in each file.
• Where a shared *ViewModelService method (also used by Admin) mutates entities referenced by an id list (e.g. InsertAssociatedProductModel/InsertCategoryProductModel/InsertCollectionProductModel), the Store controller now pre-filters that list to store-owned entities before calling the shared service.
• MerchandiseReturnController.MerchandiseReturnNoteAdd now validates order.Id == merchandiseReturn.OrderId.
• SettingController.IsStoreOwnerAccessAllowed now additionally requires exclusive ownership (Stores.Count == 1), fixing all four MerchandiseReturnReason/Action call sites at once; MessageTemplateController now calls AccessToEntityByStore directly instead of its own looser check.
• Updated ShippingControllerTests fixtures that encoded the old (vulnerable) behavior and added RestrictionSave_GlobalShippingMethod_NotUpdated as a regression test.
• Separate commit: replaced the ViewBag data carriers that actually cross the controller-to-view boundary (IsReadOnly, RefreshPage, ShowCopyButton, FilterByBlogPostId) with typed model properties, following the two patterns already established in this area (XxxStoreModel : XxxModel subclass + AutoMapper profile, or a property added directly to the shared model when it's a generic UI flag). Removed 17 dead ViewBag.AllLanguages/ViewBag.productIdsInput assignments that nothing ever read (also fixing two missing-await calls hidden inside that dead code). Left ViewBag.Title (152 of the original 183 occurrences) untouched - it's the standard Razor <title> idiom, set only in views.

Breaking changes

None. All changes are internal to Grand.Web.Store request handling, plus small additive (non-breaking) properties on shared Grand.Web.AdminShared view models (PageModel.ShowCopyButton, OrderModel.UploadLicenseModel.RefreshPage, PaymentTransactionModel.RefreshPage) that default to false and are unused by Admin/Vendor.

Testing

1. dotnet build src/Web/Grand.Web.Store/Grand.Web.Store.csproj - 0 errors, 0 warnings.
2. dotnet build src/Web/Grand.Web.Admin/Grand.Web.Admin.csproj and src/Web/Grand.Web.Vendor/Grand.Web.Vendor.csproj - 0 errors, 0 warnings (both reference the touched shared Grand.Web.AdminShared models).
3. dotnet test src/Tests/Grand.Web.Store.Tests/Grand.Web.Store.Tests.csproj - 18/18 passing.
4. Manual repro of the fixed IDORs (e.g. ProductCategoryUpdate/RelatedProductUpdate/etc. with a productId belonging to another store, or RestrictionSave against a global shipping method) now redirect/no-op instead of mutating the foreign entity.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.