Comment by DecoySalamander
Comment by DecoySalamander 10 months ago
Since everything is stored in their DB, they supposedly can audit logs and sources for boosts themselves to confirm if anyone was actually impacted.
Comment by DecoySalamander 10 months ago
Since everything is stored in their DB, they supposedly can audit logs and sources for boosts themselves to confirm if anyone was actually impacted.
I don't think you're using "dorking" correctly here, since web crawlers aren't anywhere in the picture. Server log queries aren't "dorks." Besides, if you can reproduce the issue and _if_ it's somehow logged in the database, it's usually not too hard to figure out how to query for other occurrences.
With that said, I think you're probably right. I doubt Firebase audit logs contain update contents, and based on the bug report, your "in and out" proposal is as simple as:
firebase.collection("boosts").where("creatorID", "==", "attackers_user_id").update({"creatorId": "victims_user_id" });
sleep(time);
firebase.collection("boosts").where("creatorID", "==", "victims_user_id").update({"creatorId": "attackers_user_id" });
(okay, not exactly, because this would also set the ownership of the victim's legitimate Boosts, but the actual code isn't much more difficult).
Can you explain? How are they able to check whether someone did a quick “in and out” keylogger or cookie extraction? I doubt they can, because I doubt they store every request (that would go against what they claim for privacy) and I also doubt their DB backup happens on such a high frequency that they could catch this (e.g. minute-to-minute).
So…how? Are you claiming they have oodles of logs and a perfect dork* to find suspicious JavaScript? If they had the latter wouldn’t they already be using it for security?
If you have some method that works do tell.
* https://www.alibabacloud.com/blog/what-is-dork_600025