Unit 4: Cookies and sessions · Lesson 5 of 6 · 20 min
Case file: the support upload that carried a session
Find the live credentials inside a HAR file and strip them before it leaves the company, as Okta's 2023 breach showed you must.
case file
Okta support system breach
Okta · 2023
Between 28 September and 17 October 2023 an attacker used a service account in Okta's support case system to download files customers had attached to support cases. Some were HAR files containing session tokens, which were used to hijack sessions at five customers.
What went wrong
A service account password had been synced into an employee's personal browser profile, and customer HAR files held live session tokens that nobody removed.
What would have stopped it
- Strip cookies and tokens from HAR files before uploading them anywhere.
- Keep service account credentials in a vault and block personal browser profiles on managed devices.
- Bind admin sessions to device or network and require sign-in again when they change.
What defenders could have seen
- A service account downloading support attachments at unusual volume.
- The same admin session token used from a new address.
mission
- You are
- The support engineer handling case 4471.
- Situation
- A customer recorded a HAR file of the slow receipt page and attached it. The vendor wants a copy.
- Goal
- Find every credential in the file and produce a clean copy that still shows the slow request.
- Hand in
- clean.har, with proof that no session value or token remains.
A HAR file as a sealed envelope
What is in the file?
jq '.log.entries | length' cases/support/case-4471.har 7 jq -r '.log.entries[] | .request.method + " " + .request.url' cases/support/case-4471.har GET https://shop.internal:8443/account GET https://shop.internal:8443/static/site.css POST https://shop.internal:8443/api/token GET https://shop.internal:8443/api/v1/me GET https://shop.internal:8443/receipt POST https://shop.internal:8443/login GET https://shop.internal:8443/shop
you should see Seven requests, including the slow /receipt page the vendor needs.
Find credentials in requests
jq -r '.log.entries[].request.headers[] | select(.name=="Cookie" or .name=="Authorization") | .name' cases/support/case-4471.har | sort | uniq -c
1 Authorization
3 Cookie
you should see Three Cookie headers and one Authorization header, each enough to act as the customer.
Find credentials in responses
jq -r '.log.entries[].response.headers[] | select(.name=="Set-Cookie") | .value' cases/support/case-4471.har
shop_session=7f3a9c2e41d8b6a5; Path=/; HttpOnly; SameSite=Lax
you should see The sign-in response handed out the same session value.
Strip them and check
jq '(.log.entries[].request.headers) |= map(select(.name!="Cookie" and .name!="Authorization")) | (.log.entries[].response.headers) |= map(select(.name!="Set-Cookie"))' cases/support/case-4471.har > clean.har && grep -cE 'shop_session|Bearer' clean.har cases/support/case-4471.har clean.har:0 cases/support/case-4471.har:4 jq -r '.log.entries[] | select(.request.url | endswith("/receipt")) | .response.headers[].name' clean.har Content-Type Cache-Control
you should see No session or token left in clean.har, and the receipt entry still shows its caching header, which is what the vendor needs.
defender tip Browsers can now export sanitised HAR files, but check anyway. And if a raw HAR has already been shared, end those sessions: removing the file does not.
What a defender takes away
- 1A HAR file is a recording of a signed-in session.
- 2Strip Cookie, Authorization and Set-Cookie before sharing.
- 3If credentials already left, revoke the sessions they belong to.
Questions
0 of 3 solved
Answer each one from what you find on your lab machine.