You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The intended solution was to use a variant of [3-combo](https://www.sonarsource.com/blog/code-vulnerabilities-leak-emails-in-proton-mail/#multiple-requests-per-element-crossfade) to leak a one-time password.
465
+
466
+
But after reading other people writeup, I found that arkark's [solution](https://gist.github.com/arkark/5787676037003362131f30ca7c753627) was the most simple and easy to understand. The idea was to not let the server regenerate the otp by abusing the disk cache on the client-side.
467
+
468
+
The flow was go to website (generate otp) -> leak first character via css -> go to about:blank -> use history.back() to use the disk cache (doesn't generate otp) -> leak second character and so on...
469
+
470
+
Note: Script executed in about:blank, in this case `history.back()` is considered to be same origin in the [document](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#inherited_origins), so the SOP won't block navigating back via `history` object.
I used ngrok to expose the port and replaced the url in the server code. After that I started the server and sent the ngrok url to the bot.
579
+
580
+
But I was only able to leak about ~73 characters of the otp and then it stop.
581
+
582
+

583
+
584
+
After check the bot code in the [challenge archive](https://github.com/uclaacm/lactf-archive/blob/main/2024/admin-bot/handlers/quickstyle.js), I saw that the bot has a 60-second timeout so that mean that I didn't leak the otp fast enough. This may be caused by ngrok or my machine/bot not being fast enough? I tried a couple more time and the most characters I was able to leak was 75.
585
+
586
+
Despite not being able to solved it fully, I have learnt alot about css injection and chrome's caching policy. It was a great challenge!
0 commit comments