get_temporary_link with zip files causing Google Chrome warning

[theTutor]

Hi

Google Chrome (83, Mac) has started giving me a 'Dangerous File' warning whenever trying to download zip files specifically served by the 'get_temporary_link' API call. I have 'Safe Browsing' enabled (set to 'Standard'). Until recently I have experienced no issues using this API method (using it for over 2 years now).

Apart from virus scanning etc, we've performed the following to isolate the cause:

1) The exact same files download without problem when accessing via a standard 'shared' dropbox link (i.e. with dl=1 appended to end)

2) The same files download 100% fine when downloaded through Chrome within our Dropbox account.

3) The exact same files download fine when uploaded to other file hosts. For example, Amazon S3.

4) We have created new zip files that contain nothing by a single plain text file and these are still causing the warning, but only when served via the 'get_tempoary_link' method.

5) We've pasted the temporary dropbox link directly into the Chrome address bar to rule out any potential issues with the php script we are normally using to serve the files

This only seems to affect zip files (have tested PDF and txt, no problems there). The only constant variable that causes the warning is the use of the 'get_temporary link' call. Unfortunately I don't have any indepth knowledge of the Dropbox API so am not able to test other API methods, nor am I able to see anything obvious that might be causing this.

Can anyone think why this might be any issue? I assume it's either the URL structure itself, or the output headers. 

The header is

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 29 Jun 2020 08:37:18 GMT
Content-Type: application/zip
Content-Length: 60328012
Connection: keep-alive
cache-control: max-age=0
pragma: public
x-dropbox-request-id: 9292cd205582aa9dc8b7b280e644fd75
x-robots-tag: noindex, nofollow, noimageindex
referrer-policy: no-referrer
etag: 1586602502895794n
accept-ranges: bytes
x-content-type-options: nosniff
content-disposition: attachment; filename="somefile.zip"; filename*=UTF-8''somefile.zip";
content-security-policy: sandbox
x-webkit-csp: sandbox
x-content-security-policy: sandbox
Vary: Origin
X-Server-Response-Time: 566
This is the code we are using to generate the temporary file:



$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://api.dropboxapi.com/2/files/get_temporary_link");
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Authorization: Bearer ' . $dropboxKey,
'Content-Type: application/json') );
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, "{\"path\":\"/".$record["file"]."\"}");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

$data = json_decode(curl_exec($ch), true);

if (curl_errno($ch)) { echo 'Error:' . curl_error($ch); }
curl_close($ch);
$filepath = $data['link'];

Any advice appareciated!

[Greg-DB]

Thanks for the report. I just tried this myself and I was able to reproduce this warning in Chrome with a temporary link to a zip file with some junk in it. A txt file worked fine for me though as well.

I also accessed my two temporary links directly, and the only differences seem to be, aside from the file data itself:

• the "Content-Type" header: "application/zip" vs. "text/plain; charset=utf-8"
• the lack of the "Vary: Accept-Encoding" header
• the "x-dropbox-request-id" header value (both randomly generated)
• the "etag" value (though this is opaque anyway) 
• the "content-disposition" header "filename" value: reflecting the respective file name and extension for each, ".zip" vs. ".txt"

Of those, I think it's likely the "Content-Type" and/or the "content-disposition" that Chrome is suspicious of (since .zip could potentially hide something more dangerous than .txt would), perhaps combined with different levels of trust of the Dropbox API server host as compared to others like S3.

Unfortunately, it doesn't look like there's anything for us to fix on our side, since the HTTPS response is valid in both cases, and the logic for this warning is controlled by Google of course. Dropbox also doesn't offer ways to configure the specifics, e.g., the headers, of the response (though we don't know what specifically is causing Chrome to decide to show this anyway).

I'll raise this with the team, but I can't promise if this is something we'd be able to resolve. You may wish to raise this as an issue with Google.

[theTutor]

Thanks for the reply. If it helps, I've copied the headers below for the same file downloaded through Amazon S3 (which was considered safe by Google), their headers are more 'threadbare'.

But I agree, ultimately this seems down to some internal logic at Google, and while I will report this I wonder if Dropbox could also report this themseleves, considering this is an issue that you've independantly confirmed and one that is likely to affect all dropbox customers using this API call (and potentially other API calls) for delivering zip files?

HTTP/1.1 200 OK
x-amz-id-2: 7MxPN6hDhv+Rmb9kvfQN64Z2WnSeGI5jhHvP2s6OGpSo7B4ORWyFQ/A+TnOzkTtqN8AAKnj6He0=
x-amz-request-id: A1EA9FD1D0064990
Date: Mon, 29 Jun 2020 08:32:31 GMT
Last-Modified: Tue, 02 Jun 2020 11:31:27 GMT
ETag: "72b5b016974907dcadc1644b08ff28c6-4"
Accept-Ranges: bytes
Content-Type: application/zip
Content-Length: 60328012
Server: AmazonS3

[Greg-DB]

Thanks! Yes, we're also looking into what we may be able to do about it on our side. I'll follow up here with any updates.

[aciid]

any update on this please?

I got a lot of complaints about this.

[Greg-DB]

@aciid No, unfortunately I don't have an update on this yet. I'll follow up here once I do.

[Greg-DB · Accepted solution]

This should be fixed now. Please let us know if you're still seeing any issues like this.

[mohammadreza]

Yes the problem was solved.

[aciid]

cool

thank you

[theTutor]

Yes, this seems to be working correctly now. Thanks for getting this fixed!