Option to also match requesters on same Subject (matched) but Different Senders about ticketfilter HOT 7 OPEN

You need a mix with Mail Analyzer and ticketfilter

This issue is big security problem...

from ticketfilter.

Hi @Gambware,

Sorry for the late reply. For some reason the github app didnt notify me.

If i understand correctly, you want ticket filter to be able to also validate and match the sender if a successfull match has been made and only add the update to tickets with the same requester.

I have some time on my hands this weekend.

from ticketfilter.

@AlexTR85 ,

I am not sure what you mean with 'big security problem' could you explain in more detail what you mean by that?

The plugin is currently called by the GLPI pre item add hook on the tickets object. This means the email received passed all the mailgate security checks and a ticket would have been created by GLPI either way. If you only allow tickets from known senders, the hook will not be called for emails originating from unknown senders. There is only risk of information leakage if you dont use unique identifiers (as shown in this issue).

Important notice is that the plugin assumes the 'matched' ID is unique (as is the case when communicating with upstream ticket systems or monitoring tools able to add notification IDs). If multiple tickets are found with the same identifier, there is no way the plugin knows what ticket to update, so it currently updates all found tickets.

In the provided example an asset ID is used that is not unique in relation to the tickets (as multiple tickets could be created regarding the same asset). This causes the plugin to potentially update multiple tickets if multiple are found.

Ways to cope with this:

1. easiest fix is to make sure an unique identifier is added; for example an event ID (monitoring) or ticket ID (ITSM).
2. Possible feature: prevent the plugin from updating any ticket if multiple are found causing GLPI to create new (possible duplicates) tickets.
3. Possible feature: Validate the requester email in the received email with the requesters in the matched tickets.

Currently I am implementing option 3 as a short term fix for this issue. I might consider implementing option 2 in the future.

Regards,

from ticketfilter.

The complexity here is that 'email' is not implemented uniformly. Anonymous users email is stored in glpi_tickets_users.alternative_email related to glpi_tickets; where known users have one or multiple/alternative emails stored in glpi_useremails.email related to glpi_tickets_users that is related to glpi_users. We see this implementation reflected in the populated ticketObjects passed to the plugin versus the populated ticketObject fetched by the ticket class see the snippets.

In short this gives us 2 logical points to implement this feature:

1. Match the actors when searching the database at $ticketHandler->searchTicketPool() using either multiple queries or joins and only continue processing if a succesfull match is found. the LIKE statement will perform text searches on the tickets table and will prob not benefit from db cache. This might cause considerable cpu overhead in big databases but is easiest to implement and keep the code easier to understand for others.

2. Match the actors in the ticketHandler->processTicket() using the GLPI provided objects. This is 'cleaner' because we dont need to write our own queries. Downside is that the objects are not populated identical (see sniplets below) and might prove errorprone in the future because currently I dont fully understand how the objects are populated differently in different configuration scenario's. In addition to this, if the actors dont match, we need to propagate the 'false' state back to the calling method causing these classes to becoume tightly coupled. This i would like to prevent.

3. Research if there are existing methods we can use in the fetched ticket object to validate the rights to add an followup based on the email/users found in the received email.

Currently I will go for implementation option 3.

snippet:
Fetched ticketObject with an assigned 'known' user and some random email (anonymous user).

**["users":protected]**=>
  array(2) {
    [1]=>
    array(2) {
      [0]=>
      array(6) {
        ["id"]=>
        int(113)
        ["tickets_id"]=>
        int(65)
        ["users_id"]=>
        int(7)
        ["type"]=>
        int(1)
        ["use_notification"]=>
        int(1)
        ["alternative_email"]=>
        string(0) ""
      }
      [1]=>
      array(6) {
        ["id"]=>
        int(126)
        ["tickets_id"]=>
        int(65)
        ["users_id"]=>
        int(0)
        ["type"]=>
        int(1)
        ["use_notification"]=>
        int(1)
        ["alternative_email"]=>
        string(15) "[email protected]"
      }
    }

TicketObject from the mailgate:

**["_actors"]=>**
    array(3) {
      ["requester"]=>
      array(1) {
        [0]=>
        array(5) {
          ["itemtype"]=>
          string(4) "User"
          ["items_id"]=>
          string(1) "0"
          ["use_notification"]=>
          int(1)
          **["alternative_email"]=>
          string(15) "[email protected]"
          ["default_email"]=>
          string(0) ""**
        }
      }

from ticketfilter.

After some research this seems to be a viable way to get and compare the users from both the matched ticket and the update from the mailgate.

// Get users from object passed by the pre_item_add hook.
 foreach($item->input['_actors']["requester"] as $key => $usr){
            echo "<pre>";
            print_r($usr);
   }

// Get users for fetched ticket
   $linkclass = new $this->ticket->userlinkclass();
   foreach ($linkclass->getActors($this->getId()) as $users) {
            print_r($users);
   }

It returns a limited array of assigned users with fields that can be compared against the passed ticketObject.

The logic is something like this:

• Does the pattern config dictate that we match the requesters of both the email and the found tickets?
• if So:
• Is the user_id higher then 0?
• then compare the user_id with the user_id fields in passed Object.
• Is the user_id equal to 0?
• then fetch the 'alternative_email' field and compare that with the 'alternative_email' values in the passed Object.
• If any of the previous matches, then allow processing, if not, return false to the calling object.
• if Not:
• skip previous codeblock.

from ticketfilter.

Hi @Gambware,

I have implemented the requested feature but have not yet released it. I have tested various scenario's and could not detect any issues. Could you please test the feature in your situation and report any findings back to me?

You should be able to download the current source from the repository and update the existing plugin.
https://github.com/DonutsNL/ticketfilter/archive/refs/heads/master.zip

Migration should be seamless but please do make a backup of any configuration you have or use a test environment.

Whats changed:
I changed a configuration item in the dropdowns>ticketfilter>patterns configuration. If you toggle the option: only apply with identical sources to true, ticketfilter will now evaluate all requesters in the evaluated ticket with the requesters in the tickets with the found pattern. If no user matches with those in the existing ticket, the ticket will be skipped and no followup will be added.

Please let me know if this works for you.

from ticketfilter.

@Gambware

I created a prerelease for testing, could you please test this version and provide feedback if this fixes your issue?
https://github.com/DonutsNL/ticketfilter/releases/tag/v1.3.2

from ticketfilter.