That is fascinating:

> A member of the IT team was engaged with Okta support, and at their request, created a HAR file from the Chrome Dev Tools and uploaded it to the Okta Support Portal. This HAR file contains a record of all traffic between the browser and the Okta servers, including sensitive information such as session cookies. In the early morning hours of Friday, Sept. 29th, an unknown actor used the same Okta session that was used to create the HAR file to access the Okta administrative portal

Like your bank tells you, don't give the support person your password.

> Like your bank tells you, don't give the support person your password.

Sure, but was the user aware what the HAR-file actually contained?

At the least all active sessions should be cleared after sharing something like that. But that hinges on you knowing about it. Support should also make it mandatory/automatic.

It seems to me like the browser should not include cookies in HAR files by default. Sure, have a way to enable including cookies, but it should be behind a scary warning informing the user that the cookies likely contain sensitive data.

How about: People shouldn't send around HAR files that contain sensitive information, or at least make sure the information contained is no longer sensitive (eg. by flushing active sessions)?

HAR files are a debug tool. If I have to debug a problem with a webservice, I require them to contain all the information that was sent/received by the browser. The browser arbitrarily deciding to delete part of that information, would make it worthless to me as a debug tool.

Reminds me of that banner Facebook writes to the browser console to warn people of pasting stuff that will hand over their session to third parties. Handing over a HAR is just as bad if there is any form of session involved.

Browsers could add even more nag screens between the user and the tools, but those have zero effect once the assumption "I'm talking to a person from the hoster" is established. It's the old "put on a safety vest and a hardhat and you can walk anywhere" hack that only training can protect you from. And even with the best training, you'll never reach 100%. That's why you need many tiers of your operation is as sensitive as selling a trust store.

It's well possible that 1Password are still far from being breached thanks to tiers, but it's interesting to see even people working full-time on the conflict between authentication and convenience struggle with that balancing act.

There have been several times when I was working on triaging a customer reported bug where I wanted to ask for a HAR file (through customer support), but didn't, because I didn't want them sending me (or the support intermediary) their session cookies. And having the cookies wouldn't have helped me debug it.

> And having the cookies wouldn't have helped me debug it.

But having that cookie, or any other data from my dev environment, after I manage to recreate the reported bug internally, has often helped me debug problems.

The point here is, debug tools that delete information are less useful. Worst case, they are useless.

Yes, such tools can be problematic. With great power comes great responsability. But I rather have powerful tools with a big 'ol warning sign, than useless tools.

This sounds to me like the correct way to plug this leak. It will benefit additional use cases involving the HAR export beyond individual support portals sanitizing it before storage.

The "Copy as cURL" feature has the same issue. As does highlighting and copying request/response headers to the clipboard.

However, less sensitive data should ideally remain easily transferred, without much effort on the part of the user.

I thought so too, but then was surprised to see:

   Based on the activity logs provided by Okta for their Support Portal, the HAR file had not been accessed by their support engineer until after the events of the incident

That tells me either the attacker either removed the access from the logs OR the attacker figured out how to access the HAR file without having the access recorded in the logs.

All this says is that the support engineer didn't access the file. It doesn't say the attacker wasn't logged accessing it.

>Oct 21, 2023: Okta confirmed publicly that their internal support systems were compromised. This answers how the HAR file was accessed by the attacker and that the initial compromise was not through the employee’s laptop.

how can "the industry" trust okta?!

> Like your bank tells you, don't give the support person your password.

Sure, but they uploaded it to the okta portal, not to any random support person. Most users would expect that people getting files from the company portal would be cleared to see confidential and sensitive stuff.

Obviously not passwords, but still ...

Ideally, okta would clear those sessions when someone uploads a har file. That way, you don't have to trust users did the right thing...