How I found an IDOR in Google Classroom on Day 3 of my Hunting?

Hope you are well. This is my first writeup and I will tell you how I found IDOR on Google Classroom on Day 3 of my hunting on Google. I hope it will inspire you.

I selected my first target as Google Classroom because I use it daily for my University Assignments and Tasks.

So first, I started testing every feature, and I noticed in Burp History that Google is using Batchexecute system with rpcids for every UI functionality.

The batchexecute system at classroom.google.com is Google's internal frontend RPC protocol and it's completely undocumented.

The batchexecute system works like, every UI action in Classroom triggers a POST request to the batchexecute endpoint with a parameter called rpcids that identifies which internal method to call.

For example when you post a comment in Classroom your browser sends something like:

Then, I started mapping different UI functionalities with rpcids, for example:

ndas7c > CREATE announcement F7asdb > UPDATE/EDIT announcement tQbcjc > READ/FETCH announcement xxxxxx > POST private comment on submission thread

These rpcids helped me map every Ui functionality.

After spending time mapping every RPC method in Classroom batchexecute system, most of my tests were coming back clean. Google's auth on the obvious attack surfaces was solid. The well-known endpoints had proper authorization checks.

I was about to move on to a different target but I decided to look more carefully one last time at the private comment functionality on assignment submissions.

Private comments in Google Classroom are a specific feature designed for confidential communication between a student and their teacher about a particular assignment submission. When a student submits work they can leave private notes for the teacher and the teacher can respond. These comments are explicitly designed to be visible only to the submission owner and the teacher. No other student should be able to see or interact with that thread.

I gave it a try and said to myself that this is the last endpoint I will test on Classroom.

I had two test accounts set up, one acting as an attacker and one as a victim, both enrolled in the same course with submitted assignments. While intercepting traffic I started looking at the requests that fired when I posted a private comment on my own submission.

What caught my attention was the structure of the request. Like all batchexecute calls, it contained several ID parameters such as the course ID, the coursework ID, and crucially a submission ID that identified whose submission thread the comment was being posted to.

The question I asked myself was simple, what happens if I change that submission ID?

Then, I captured my second account same request and copied the submission ID.

I replaced my submission ID with the victim's submission ID in the request, kept my own session cookies, and sent it.

The server returned 200 OK.

I opened the victim's account and looked at their private submission thread. Yippee, my attacker comment was sitting there, visible to the victim and their teacher.

The authorization check wasn't there for this particular RPC method. The server accepted the request, trusted the submission ID in the payload, and posted the comment without verifying that the commenter had any legitimate relationship to that submission.

Now, there was one thing I had to figure out that how to get the victim submission ID in a realistic scenario.

I started analyzing Burp History and found a response that was showing submission IDs of all students enrolled in the class. BOOM. I tested it again and found that on a specific endpoint, if you refresh the page and capture the request, you will see submission IDs of all students in the response.

I verified the finding from the teacher's account as well. The unauthorized comment appeared there too.

I documented everything and submitted the report to Google VRP. Unfortunately, The report came back as a duplicate, but I was happy that I found a legitimate issue.

Finding a real vulnerability in a Google product as someone still building their skills felt significant, even if it ended up being a duplicate. The whole process taught me more than I expected, not just about bug hunting but about how to think like a security researcher.

Thank you for reading. Hope you enjoy it and hope it inspire you.

Follow me on Linkedin: linkedin.com/in/marrij