The Partition cookie is enabled for 3rd-party cookies in Teams desktop client.

Question

Hi,&nbsp;We've noticed an issue with the latest Teams macOS client regarding cookie handling in the Teams Tab App (loaded in an iframe). Specifically, cookies are being partitioned with a unique partition key, even though the Partitioned attribute has not been explicitly set.Interestingly, if a 3rd-party cookie isn’t set within the Teams Tab App (i.e., the iframe), the cookie doesn’t get partitioned. This can result in two cookies with the same name but different values being set in the same browser. When both cookies are sent to the server, the non-partitioned cookie appears first in the Cookie header, causing the server to always use this one. To make it worse, the cookie set without the partition key will never be updated.&nbsp;Here’s the scenario we encountered:1. We have both a Teams Bot and a Teams Tab App.2. The Teams Bot sends a card message to a personal chat, which contains an image hosted on our web server.3. When the card message is rendered, the image is loaded from our server, and the server sets a LoadBalancer cookie.4. The Teams client saves this LoadBalancer cookie without a partition key.5. When the user opens the Teams Tab App, the client loads the Tab App from the same server in an iframe.6. The server sets another LoadBalancer cookie for requests coming from the Tab App.7. However, this time, the Teams client saves the LoadBalancer cookie with a partition key.8 The Teams client then sends both cookies to the server, but the server always uses the non-partitioned cookie since it appears first9. One workaround we’ve tried is using a base64 encoded image in the card message, but this isn’t an ideal solution as it increases the size of the message, especially for larger images.&nbsp;We would appreciate it if the Teams client could:1. Always set the partition key for 3rd-party cookies, not just when the cookie is set within the Tab App (i.e., iframe). The current behavior doesn’t seem to align with the CHIPS specification.2. Proxy the image in the card message through the Teams domain, rather than loading the 3rd-party image directly. We’ve noticed that the Teams client already does this for some cards but not consistently across all cards.&nbsp;&nbsp;

zyue_mstr · Answer

Sayali-MSFT&nbsp;&gt;Image should never load directly from 3rd party endpoint. We've been using URLP or AMS (for b64 images) to proxy images.&nbsp;Thanks for the response. This is what we expected Microsoft to do. The third-party image should be proxied for security reasons. However, I'm afraid there is a corner case where you missed proxying it.&nbsp;We found a case where&nbsp;MSFT doesn't proxy the images when embedded in the Adaptive Card (The reproducible code is attached). Below is an Adaptive Card sent from the bot. As you can see the image URL is not proxied. Is this expected?&nbsp;&gt;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.&nbsp;We know that. Our image doesn't rely on Cookie and doesn't have any state-dependent. But the reality is complicated. When we or our customers set up an LB (e.g., the AWS ALB) in front of our servers, all the requests will be responded to with an LB stickiness cookie, even though the image doesn't rely on cookies.&nbsp;Since MSFT doesn't proxy this image, the cookies will persist without the partition key. If we open our Teams Tab App (i.e., an iframe), these cookies will also be included in the requests sent in the Teams Tab App. This will cause the duplicated LB cookies (one is partitioned and another is not partitioned). Leading to tricky issues with our application as the session can never be sticky.&nbsp;You shall not overlook the image-proxying problem.&nbsp;

sayali-msft · Answer

zyue_mstr-Thanks for reporting the issue, we will check this with the internal team and let you know the update.

sayali-msft · Answer

zyue_mstr&nbsp;-&nbsp;This behavior is expected. We force partition all embedded/iframed app cookies in the Teams Desktop Client (for both Mac and Windows) in order to support isolation of cookies and other offline storage across the multiple user accounts that the New Teams Client supports.The most viable short-term mitigation here is to use different domain/path for the images used in their adaptive cards vs their tabs. That would avoid causing collisions between their partitioned and unpartitioned cookies.

zyue_mstr · Answer

Sayali-MSFTI 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.&nbsp;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?&nbsp;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.&nbsp;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?&nbsp;&nbsp;

sayali-msft · Answer

zyue_mstr -We will check this with the engineering team and let you know the update.

Forum Discussion

The Partition cookie is enabled for 3rd-party cookies in Teams desktop client.

Share

Resources