The process of detecting reflective, storage, and DOM vulnerabilities in the Google collaborative community (GWC)

The process of detecting reflective, storage, and DOM vulnerabilities in the Google collaborative community (GWC)

Google Work Connect (GWC) is a Community system composed of systems, application administrators, and partners. It is also within the scope of Google's vulnerability rewards. Not long ago, I found reflective, storage, and DOM XSS IN THE GWC Community system.
Stored XSS
In the GWC Community system, administrators of different applications can share their opinions with each other. This Community system allows users to create documents, articles, discussions/messages (and other such as tag issues and tags). An article contains a title and a body, the title is what we are most interested in, but the system will encode it into HTML entities
 

For example, if the object is encoded as an HTML object, we cannot use it at this point, but we can do the same with Google Drive. On Google Drive, there is a "Upload File to Google Drive" function, and the uploaded file name will become the title of the article.

For example, I uploaded "xxxxxxxx 'yyyyy on Google Drive. PNG, then the file name is put in the title of the script tag, but "and is not encoded or filtered, so xss can be constructed.

For example, upload a file named confirm (document. domain) file, and the file name is nested into the GWC Community system. The xss is a storage-type xss, which will be triggered by any login user.
The reason for the formation of this storage-type xss is that when the GWC Community system introduces data from other applications (Google Drive), it is directly used without controlling, coding, and filtering the data, however, in their respective applications, the data submitted by users is well processed.
Reflected XSS
If you can trigger an error (for example, the file is not uploaded properly in Google Drive), The GWC Community system will throw an error message in the GET request "googleDriveError" parameter, this parameter can be used to construct a reflected xss. If you can construct an authentication error, the error message will also be placed in the "error" parameter of the GET request. As shown in, the "googleDriveError" parameter in the GET request contains our harmless test character "xxxxxxxx 'yyyyy.

You can also see that the object is not encoded as an HTML object.

For example, the "googleDriveError" parameter of the GET request is used to construct the xss.

For example, xss is constructed using the "error" parameter of the GET request.
DOM-type XSS
The culprit is window. location. hash. substring (1), but there is a limit: the xss can be triggered only when the user marks the article as "Mark as Helpful. The problematic JavaScript code is as follows:
... {If (window. location. hash) {c. scrollTo ("a [name = '" + window. location. hash. substring (1) + "']")}...

For example, this article is not marked as "Mark as Helpful", so the xss is not triggered.

For example, the article is marked as "Mark as Helpful", so the XSS is triggered.