Ticket hover preview loads remote content

saz commented 1 year ago

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Is there an existing issue for this?

[X] I have searched the existing issues

Version

10.0.6

Bug description

If there's a ticket with content from an email, the remote content will be loaded. I've stumbled upon this issue, as a request has been blocked by my browser due to mixed content.

This looks like a potential leak of data to some third party, if there are tickets created by mail.

Relevant log output

Mixed Content: The page at 'https://glpi.example.com/front/ticket.php' was loaded over HTTPS, but requested an insecure element 'http://tracking.example.com/wf/open?upn=o6Ks<...reducted...>O-2BT9Uvj0m5y-2FAnbyvlMY1aBeIROuQpk-3D'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html

Page URL

https://inventar.example.com/front/ticket.php

Steps To reproduce

No response

Your GLPI setup information

No response

Anything else?

No response

cedric-anne commented 1 year ago

Hi,

Could you please export, into eml format, an email that may be used to reproduce your issue?

saz commented 1 year ago

Please review your recent purchase of DearFlip WordPress Plugin.zip

@cedric-anne I hope, I've not redacted to much and it's still working. If not, please let me know

cedric-anne commented 1 year ago

I cannot import the email due to an error (Error during message parsing (Not a valid Mime Message: End Missing)), I guess it has been redacted too much.

Anyway, as far as I see, the problem here is that it contains an image that have src attribute that uses http protocol in your GLPI that uses the https protocol (<img src="http://click.freemius.com/wf/open?upn=XXX">).

IMHO, we should not try to do anything to fix this, as there is no good solution, if we consider that some images are legitimate to be displayed in the ticket (this one is not, but sometimes people may copy/paste an HTML page in their mail and it may contains important images).

If we decide to remove protocol on links to ensure they are using the same protocol as GLPI (i.e. http://click.freemius.com/ -> //click.freemius.com/), it may break display of images that are hosted on a server that does not support HTTPS.
If we decide to fetch images on the GLPI server, it may not work due to firewall restrictions, and it may also be a security issue as most of anti-spam/anti-virus applications are probably not checking remote URLs from src attribute of img tags.

@orthagh @trasher Any opinion on this?

saz commented 1 year ago

I'm sorry for that, but your explanation is right. I still see this as a possible information leak and - in my opinion - remote resources should be handled the same way as mail clients are doing it these days: asking, if they should be loaded.

An attacker might create an email to see, if the target has opened the email, as the image will be loaded by the target browser. I've not checked, if any JS in a mail will be stripped or not.

cedric-anne commented 1 year ago

We could indeed add an option to filter external content.

A solution would be to keep the image tag, remove its src attribute (so it would display a broken image) and store its value into a data-src attribute, to be able to detect these images on ticket page and propose to the user to show blocked images. Same should probably do for all kind of medias (audio, video, ... tags).

Unless I am wrong, the only potential leak here is to get URL of GLPI from the referer attribute of the request (but there are many more ways to parse the internet to detect GLPI instances), and maybe to get the end-user IP (not sure it has any value).

saz commented 1 year ago

Depending on how everything's set up, the referer might contain more sensitive data, for example, if you're accessing the ticket overview (or the ticket view) from a completely different system. At the same time, not all GLPI installations must be public.

I'm aware, that this might be an edge case, but at the same time, it's completely unexpected, that external requests are happening like that (maybe it's also enough to make people aware of that in the documentation? :thinking: )

PiLoT650 commented 1 year ago

Hi there, we had the same problem this week - got several emails from hacked companys - where the domains for the companys were on AV blacklists - since you can adjust outlook like @cedric-anne described above - can be set to not download external content would be really nice in glpi too.

So far we got our EDPR warnings for every it-admin which opend this ticket - and this is not what you want. And you will also leak the information this email address exists and or your public ip address - and maybe (not sure there) load more dangerous stuff if there's a browser bug?

Since we are still on 9.X.X we added some rules via ticketcleaner to rewrite <img src links to hXXp - so external content won't get loaded. Maybe also an option for you @saz

saz commented 1 year ago

@PiLoT650 Thanks for the recommendation, but, sadly, I'm on GLPI 10 and ticketcleaner looks quite unmaintained.

I still think, this is something, which should be resolved within GLPI.

glpi-project / glpi