Forum Discussion
The Partition cookie is enabled for 3rd-party cookies in Teams desktop client.
I understand you force partition all embedded/iframe app cookies in the Teams Desktop. However, it looks like the implementation has ignored the third-party cookies set from the personal chat pannel.
It happens when a message card contains an image which is loaded from a third-party web site. If the image request set a cookie, then that cookie is not partitioned. Is this a flaw or a potential security hole since the 3rd-party cookies are not completely isolated across multiple accounts?
For example, the picture below will load an image from the personal chat. And this image request will set a third-party cookie, this cookie is not partitioned by the Teams client and it is shared by all accounts opened the same website.
Another problem is that we found that Teams has rewritten some images' URL from the same site. The pie chart image in the picture below is also loaded from our website, but the Teams client rewrites it. You can see the domain is no longer ours. However, it doesn't rewrite the image URL in the above picture. Both images' URL are built from the same domain and included in the Adpative Card. One image URL is rewrited while another is not. Is this a problem?
MicrosoftTo explain the second problem more specifically, we found that the Teams will rewrite the image URL included in the Message Extensions response card. Take the snapshot below as an example, the original value of the "url" field has been rewritten by Teams. However, this is not achieved in the Adaptive Card sent by the Teams bot. From the security perspective (e.g., to avoid the third-party web server setting tracking cookies via an image URL. Otherwise, once set, the cookie is shared by all accounts signed in the same Teams client.), the team's client should rewrite the URL embedded in the Adaptive Card.
- Sayali-MSFT
zyue_mstr - We got the reply from engineering team that,
Image should never load directly from 3rd party endpoint. We've been using URLP or AMS (for b64 images) to proxy images.
The image should not rely on Cookie. To follow our designed principle, it should be super straightforward - card images should be always publicly accessible directly without any state dependent.
For the other issue they are investigating, we will let you know once we have any updatesHi Sayali-MSFT, is there any update on this? Can you reproduce the problem with the code provided? Thanks.