Fix vendor product IDORs and consolidate ownership checks in Grand.Web.Vendor

[KrzysztofPajak]

Type: bugfix

Issue

Two IDOR vulnerabilities were found in Grand.Web.Vendor product sub-resource mutations:

1. BundleProductModel field mismatch (ProductViewModelService.UpdateBundleProductModel/DeleteBundleProductModel): the model carries two ids — ProductBundleId (the parent product actually loaded and mutated) and ProductId (the bundled component). The global IProductValidVendor ownership filter only validates ProductId. A vendor could submit their own product as ProductId to pass validation while mutating another vendor's bundle-product list via ProductBundleId.
2. ProductRelatedValidVendor OR-bypass: the validator behind IProductRelatedValidVendor accepted ownership of eitherProductId1 or ProductId2, but RelatedProductUpdate/Delete and SimilarProductUpdate/Delete only ever read/mutate ProductId1's mapping list. A vendor owning any product could supply it as ProductId2 to pass validation while editing/deleting another vendor's ProductId1 mapping entry.

Separately, ownership checks across this area were duplicated ad hoc (~50 inline entity.VendorId != CurrentVendor.Id comparisons, plus a private CheckAccessToProduct on ProductController that reimplemented an existing shared helper), which is how issue #1 above stayed unnoticed — the check that matters is easy to miss or misplace when it isn't consolidated.

Solution

• Added an explicit ownership check on the loaded parent product in UpdateBundleProductModel/DeleteBundleProductModel.
• Changed ProductRelatedValidVendor to require ownership of ProductId1 only, matching what the consuming actions actually mutate.
• Consolidated all ownership checks in the Vendor area onto the existing IWorkContext.HasAccessToX(entity) extensions in Extensions/HasAccess.cs (checking the loaded entity right before mutation, not a request DTO field), removing the duplicated inline comparisons and the redundant CheckAccessToProduct. Added HasAccessToVendorReview/HasAccessToMerchandiseReturn for the two controllers that had no shared helper yet.
• Documented the pattern and the failure mode with XML doc comments on HasAccess.cs and IProductValidVendor.cs so a future model with more than one product-id-shaped field doesn't reintroduce the same bug.

Breaking changes

None. ProductRelatedValidVendor becomes stricter (was accepting an alternative ownership path that was never intentionally needed by any current caller); all other changes are behavior-preserving refactors of duplicated checks onto a single existing helper.

Testing

1. Check out this branch and run dotnet build src/Web/Grand.Web.Vendor/Grand.Web.Vendor.csproj — builds clean, 0 warnings/errors.
2. As vendor A, create a bundle-product mapping row id on vendor B's product (e.g. by inspecting the grid's hidden Id/ProductBundleId fields via devtools on a page you have access to, or via direct POST), then POST to BundleProductUpdate/BundleProductDelete with ProductBundleId = vendor B's product and ProductId = one of vendor A's own products. Before this fix: request succeeds and mutates vendor B's product. After: request throws/returns a permission error.
3. As vendor A, POST to RelatedProductUpdate/RelatedProductDelete (or the Similar-product equivalents) with ProductId1 = vendor B's product (and an existing mapping Id on it) and ProductId2 = one of vendor A's own products. Before: request succeeds. After: request is rejected by ProductRelatedValidVendor.
4. Regression-check normal vendor flows: editing/adding/removing categories, collections, related/similar/bundle/cross-sell/recommended products, pictures, and spec attributes on a vendor's own products still works as before.

No dedicated Grand.Web.Vendor.Tests project exists yet, so this is verified via manual testing and dotnet build rather than an automated test run.

🤖 Generated with Claude Code

[Copilot]

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