N°8606 - Check user permissions in search operation of ajax.render.php

[Lenaick]

Base information

Question	Answer
Related to a SourceForge thread / Another PR / Combodo ticket?	N°8606
Type of change?	Bug fix

Symptom

Users can access unauthorized objects via the search operation in ajax.render.php

Cause

User permissions are not checked before returning object

Proposed solution

Add a permission check before returning objects

Checklist before requesting a review

• I have performed a self-review of my code
• I have tested all changes I made on an iTop instance
• I have added a unit test, otherwise I have explained why I couldn't
• Is the PR clear and detailed enough so anyone can understand digging in the code?

[Copilot]

Pull request overview

This PR fixes a security vulnerability (N°8606) where users could access unauthorized objects via the search operation in ajax.render.php. The fix adds permission checks using UserRights::IsActionAllowed() in the GetDataForTable method before returning object data.

Changes:

• Adds a UserRights import and two UR_ACTION_READ permission checks in AjaxRenderController::GetDataForTable() — one for the main query class and one for each alias class in join queries — throwing an exception with a localized error message if the user lacks read access.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The permission check for alias classes is placed inside the while ($aObject = $oSet->FetchAssoc()) loop, meaning UserRights::IsActionAllowed is called once per row per alias. Since the check is class-based (not object-based), the result is the same on every iteration. While GetUserActionGrant has internal caching that reduces the cost, this check should be moved before the while loop (alongside the main class check at line 77) for clarity and to avoid unnecessary function call overhead on every row. You could iterate over $aClassAliases before the loop and check each class once.