"10.20 Summary" a vulnerability submission page of the right to exploit

！！！ After writing the page crashes, and then the draft retrieved content is not right!!!

Write-Up Address: Add comment on a private Oculus Developer Bugs report

The vulnerability originated in the author Sarmad Hassan (Juba Baghdad) test of the Oculus Web site Vulnerability (non-security vulnerability) submission feature.

This feature is analyzed first :

1. Users have two ways to submit vulnerabilities: public and private

2. Public vulnerability: Anyone can comment or reply to comments

3. Private vulnerability: In addition to the submitter and support team, no one can comment

4. No other user's private vulnerabilities appear in the user's dashboard

It is clear that the user will not be exposed to the private vulnerabilities of other users under normal circumstances, and it is this part of the functionality that deserves our breakthrough.

analyze the possible problems with the private vulnerability feature by testing the public vulnerability feature .

The author created a public vulnerability and commented that the request was intercepted when replying to the comment:

Post/graphql?locale=user http/1.1host:graph.oculus.comaccess_token=my-acces-token&variables={"Input": {" client_mutation_id ":" 1 ","comment_parent_id":" 556190998150906 ","external_post_id":" 548709645565708 "," message ":" What Ever "}}&blablabla

You can find two interesting parameter names (the author should be confusing two IDs here, as explained in the author's PoC video):

1. COMMENT_PARENT_ID: The ID of the comment

2. EXTERNAL_POST_ID: Vulnerability ID (vulnerability ID can be obtained from URL https://developer.oculus.com/bugs/bug/your-bug-ID/)

Naturally, the author thought that the two IDs could be replaced:

One scenario is to replace external_post_id, which can be commented on by other users ' private vulnerabilities, but without success.

Another scenario is to replace comment_parent_id, which can be replied to under comments from other users ' private vulnerabilities, and the test succeeds. In fact, it is noted here that external_post_id still attacks the user's original vulnerability ID, but only because comment_parent_id becomes the user's private comment ID, you can achieve the attack.

a small problem :

How can an attacker obtain a comment ID for another user's private vulnerability? This is really a problem, and if it is targeted at a particular user, it may require other means, but the attacker can still enumerate the IDs in a violent manner, implementing a random attack.

1. For the characteristics of the test, it is necessary to analyze its various aspects of the function, as well as various types of user rights.

2. From normal permissions, analyze the restricted permission

3. To some extent, the vulnerability implies a logical problem, so do not analyze the possible direction of the vulnerability in accordance with normal logic, but break the limits of thinking

"10.20 Summary" a vulnerability submission page of the right to exploit