Remote Debugging Chrome & SameSite cookies with Chrome DevTools

When developing and delivering use-cases for Android or iOS devices, remotely debugging and inspecting how content is rendered in Google Chrome can be challenging. In the last few years, Chrome introduced a very useful feature that allows remote debugging. This functionality became infinitely useful when working on a use case that leverages cookies in a third-party context. In this blog post, we'll cover why cookies can be a headache (for all platforms), and how Chrome DevTools can be used to isolate issues on mobile devices.

Requirements:

  • Android OS with Developer Options enabled
    • USB Debugging enabled
  • USB-C Cable
    • To connect Android device to macOS / Windows device
  • Google Chrome (mobile)
  • Google Chrome (macOS / Windows device)




Context:
A use case I am involved in hosts content internally on a private cloud using VMware Tanzu (formerly Pivotal Cloud Foundry). This private cloud has its own unique domain. So while the user might be authenticating and viewing content on www.myLearning.WS1inHawaii.com, the video content displayed in an iFrame would be streaming from a different domain, like www.cdn.myHawaiiCloud.net. 

Sounds neat, right? We save on public cloud data egress costs by hosting the video content on our private cloud. Then to provide the responsive web-site for users, we host it on a provider that is more performant across all geographies - like CloudFlare or Amazon Web Services. 

The Problem
Each cookie issued by a service has a key/value pair that identifies how the cookie can be used. There are first party cookies, and third party cookies. In 2020, Google and Apple (and all browsers based on Chromium and Webkit) introduced a secure by default model for cookies used in a 3rd party context. This secure by default model protects 3rd party cookies from external access unless otherwise specified in the 'SameSite' key/value pair.

What this meant for the business is content in an iFrame would suddenly not render. On Chrome version 80 and above, all cookies without SameSite attributes will be treated as if they have 'SameSite=lax' specified. With this secure by default model, if the SameSite attribute value is set to 'lax' and is from a 3rd party, it will be blocked. When the 3rd party cookie is blocked, it will cause content from that 3rd party to not render. 

In our case, the 3rd party service internally developed did not serialize cookies with the SameSite value set. This impacted iOS, macOS, Android and Windows devices, but only devices that had newer browsers. 

It is important to note that we needed a permanent, secure, solution that works on all platforms. Google has settings temporarily available to exempt cookies from this new secure by default model. These settings are scheduled to be deprecated in late 2021 / 2022. Enabling these would be considered less secure, as it introduces a cross site request forgery attack vector. In addition, these settings are not available on all platforms (iOS is currently excluded). In our use case, the most secure solution will come by introducing a CNAME DNS record that points to our A record for the CDN hosted on Tanzu. The next most secure solution would be to serialize the cookie with the SameSite values specified as:

'SameSite=None; Secure'

Finally the least secure option would be to use Workspace ONE to introduce a client side fix with Chrome, which would allow cookies to be sent with all cross-site requests. Since this service was developed on a wrapper over Spring Boot (a popular Java framework), the codebase could be updated to serialize the cookies with the SameSite attribute set. This ultimately solved the issue on all platforms and browsers. 

So how do you even know if something like this is impacting you, especially on a mobile device? Remote Debugging with Chrome, that's how.


Remote Debugging Chrome Mobile on Android with Chrome DevTools
  1. On the Android device, enable Developer options
  2. Enable USB Debugging in Developer options
  3. Connect the Android device to your macOS / Windows host
  4. Open Chrome on the Android device
  5. Open Chrome on the macOS / Windows host
  6. On the macOS / Windows host, navigate to the URL:
    chrome://inspect/#devices
  7. On the macOS / Windows host, you should see something like this:
    The SM-T830 device has developer options enabled, and Chrome open. On the mobile device, every Chrome tab, including Chrome custom tabs, will be displayed here.


  8. Click inspect on the mobile site browser tab that you wish to inspect
  9. On the mobile device, navigate to the website that fails to render content
    • If the web browser is newer than Chrome 80, open the Google Play store and uninstall the Chrome browser. While you cannot uninstall the browser, you can downgrade the browser to the version shipped with the device. The screenshot you see below will only display on Chrome browser versions 79 or lower.  
  10. Click the 'Console' tab in Chrome DevTools. If you see references to a cross-site resource with SameSite cookies attributes properly set; the cookies serialized by the service are not sent with the values;
    'SameSite=none; Secure'

  11. To see the cookie key/value data, click 'Network', followed by 'Cookies'. Make sure 'show filtered out request cookies' is checked, in addition to 'Has blocked cookies'

    If you hover your mouse over the cookie, it will warn you about the SameSite attributes 

If you open a new browser tab on the mobile device, and you wish to inspect it; you will need to close 'DevTools' and click 'Inspect' on the new tab you opened.

To highlight how Remote Debugging works, I created this short video. In this video you see how to inspect browser tabs on remote devices, and use DevTools much like you would on a non-mobile device.



The goal of this blog post is to share the value of using Chrome DevTools to inspect how content is rendered on a mobile device. Prior to DevTools supporting remote debugging, it was much more difficult to obtain this kind of data. When DevTools is combined with Fiddler and a tool to troubleshoot AuthN/AuthZ (e.g. rcFederation), you can tackle nearly any issue.

If you are interested in learning more about Remote Debugging with Chrome DevTools, or SameSite cookies - check out some of the links below.

https://www.youtube.com/watch?v=GPz7onXjP_4

https://developers.google.com/web/tools/chrome-devtools/remote-debugging

https://developers.google.com/search/blog/2020/01/get-ready-for-new-samesitenone-secure

https://www.chromestatus.com/feature/5633521622188032

https://www.chromestatus.com/feature/5088147346030592

https://web.dev/samesite-cookies-explained/


Comments

Post a Comment

Popular posts from this blog

How to use Fiddler Everywhere to inspect Android network traffic to troubleshoot SAML authentication issues

Image
Recently Telerik would release Fiddler Everywhere, a free web debugging proxy, for macOS. Previously, Fiddler was native to Windows, and macOS users would have to resort to using Charles, or using Fiddler in Wine on their macOS. While Charles is great, it also wasn't free. With Fiddler Everywhere being a free offering, it has quickly cemented itself as a must-have tool for developers.  Thanks Telerik, my Hawaii vacation / retirement fund just grew by $50. Today, we're going to cover how to use Fiddler Everywhere to capture network traffic from an Android device. This is useful if you need to review SAML responses when troubleshooting authentication. But before we proceed to the fun stuff.... Wailea,  Ulua Beach, Maui Requirements: Telerik Fiddler Everywhere https://www.telerik.com/fiddler-everywhere Computer connected to network Android device connected to the same network as the computer Android device must have no Workspace ONE profiles installed th
Read more

Zimperium Delivery and Activation on Android Enterprise with Workspace ONE UEM Product Provisioning

Image
A use case I am involved in required remotely delivering Zimperium zIPS, a mobile threat detection and response security product, to Android Enterprise devices with Workspace ONE UEM. Zimperium is an incredible mobile security product, which I will discuss more in upcoming blog posts. The way Workspace ONE and Zimperium compliment each other is ideal for securing devices running (Android and iOS supported). First we need to deliver zIPS; and this will cover the delivery and activation of zIPS on an Android Work Managed device with Workspace ONE UEM Product Provisioning. For zIPS to secure a device, report threats back to Zimperium's zConsole and eventually Workspace ONE Intelligence; zIPS requires activation on each device. It sounds daunting, especially because it isn't just delivering an apk file and managed configuration. If you have a fleet of 15,000 or 150,000 devices; you wouldn't want to visit each point-of-sale kiosk, in-flight entertainment system, medical devic
Read more

Clean up duplicate identities and users from Workspace ONE using REST API's and PowerShell

Image
Workspace ONE gives us a centralized management plane for our users digital workspace. But with the proliferation of identity and access management solutions, it isn't uncommon to find users with multiple identities in our management plane. Especially when you lift and shift from one identity solution to the next.  I have a friend and colleague who is working with a beverage company who have a fairly tedious task ahead of them. They have to clean up duplicate identities, and do it quickly. I thought it would be great to share a solution I put together, and discuss how you can go about cleaning up identities in your environment as well. But before we get to the good stuff; some mood lifting visual stimuli... Entrance to Andaz Maui at Wailea Fun fact: Novell eDirectory still exists. Owned and maintained by NetIQ. Any readers still using eDirectory, send me a email so I can buy you a beer. A lot of organizations start with Workspace ONE by importing identitie
Read more