Google spreadsheet CSRF+JSON hijacking vulnerabilities-vulnerability warning-the black bar safety net

ID MYHACK58:62201680768
Type myhack58
Reporter 佚名
Modified 2016-11-01T00:00:00


In 2 0 1 5 years 1 0 months I am in the Google spreadsheet for the API interface found in the JSON + CSRF(cross-site forgery requests, Clickjacking vulnerability. An attacker can exploit this vulnerability in not authorized to access Google Drive files of the case, to obtain the user of the electronic forms of the information. Vulnerability On the network using this exploit, an attacker would need to bypass the Google Drive spreadsheet shared set of ACL policies. The first description, the attacker is not authorized to access Google Drive files of the case(shown below),you can use this vulnerability to bypass Google security settings: ! Vulnerability the root causes of This is not the first Google there is JSON data hijacking, thereby causing the user data leakage vulnerabilities. Vulnerability is the root cause of Google Drive API interface to the data flow design, thereby resulting in the OWASP TOP(2 0 1 3)-A8-Cross-site Request Forgery(CSRF)vulnerability resulting JSON data hijacking. Vulnerability is not difficult, once the Google Gmail there is CSRF+JSON hijacking vulnerabilities. 2016.01.27-Gmail attack of the advanced techniques 2008.11.20 -- JSON attacks coquettish posture 2010.10.14-the Gmail JSON hijacking attack technique JSON hijacking attacks, Google is such a fix: in the JSON inside add a while()loop, if the attack occurs it will make the victim's browser to crash, causing the attack to fail. However, for Google Drive JSON hijacking vulnerabilities, add only one cycle is not enough. In order not to affect the Google Drive product features, the necessary repair requires complex changes. Google chose to let the old API interface offline, use the new interface to solve the security issues. This requires the use of these interfaces the developers to update the code. Vulnerabilities attack scenarios numerous use of a One of the company's spreadsheet inside the organic key information. ! The spreadsheet is only shared to the authorized company staff. ! A staff in-service, he authorized the account to be canceled, while is to share the file inside a password/PIN is also changed. ! New the sharing as shown below, you can see the separation of staff privileges have been cancelled. ! The force be with you Now is to cancel the authorization of the employees very much want to get the electronic form of the data, 他知道Mr.admin.assist@example.com喜欢经常去一个网站 while this site allows anyone to use HTML format message. This is known as watering hole attack, the attacker only need to wait. The following figure is the victim visits the website screenshots ! At completely don't know the victims, no matter who is the document owner of the case, the attacker can receive the electronic table of data. ! The following figure is the attacker stealing the data of the victims completely invisible) ! The attacker sees the data as follows: ! This is how to become possible? Google Drive API does not require OAuth token in the case, allowing other sites cross-domain requests. In this case, as long as the user login to Google Drive after any other site it can be by calling the API interface to obtain the user's spreadsheet data. Because the return data is in JSON format, so you can use JavaScript to parse after transmission to the attacker's server. Simple vulnerability prove the code is as follows: simpleCapture.php - from the victim's browser to get data to the script google_drive_smuggle.html - the HTML code used to steal the target data The following is a JSON hijacking code example: var google = new Object(); google. visualization = new Object(); google. visualization. Query = new Object();

google. visualization. Query. setResponse = function(goods) { google. response = JSON. stringify(goods, undefined, 2);

} Google Drive API returns data in JSON format to Javascript Object, The this data we can cross-domain page to get to, only need a simple send to your own server. Timeline Date Event 2015.10.29 Report to Google 2015.10.30 Google confirmed the vulnerability at the same time ask Google the time to repair 2015.11.6 Google reply: the product group hope they eventually change will not take under one year user a lot of time. As you said, this issue needs to be handled carefully, because many users in the use of this function. But I'm glad they have some progress, and will soon repair. 2016.1.5

[1] [2] next