This seems unsafe; if I understand what this person has done, he'd essentially be coercing Dropbox's backend services to open arbitrary links on his behalf. That's a very dangerous capability to expose to adversaries.
I don't see a .doc file getting small enough to outsize a HTTP request inside of it, even if you used some funky compression, but I'm willing to hear otherwise.
One question would be if you could upload the document once and then somehow trigger a very tiny edit that causes them to rescan it.
We do use LibreOffice to render previews of Office documents for viewing in a browser, and have permitted external resource loading to make those previews as accurate as possible. While this could theoretically be used for DDoS, we haven’t seen any such behavior. However, just to be extra cautious we’ve temporarily disabled external resource loading while we explore alternatives.
It may be that you are big enough that even the limited bandwidth you need for normal operations is enough to take out smaller hosts, so you'd need to measure and monitor to see how well this works.
Could Dropbox perhaps let me disable this feature? I almost never use the web interface so I wouldn't miss it and I prefer that my documents are not opened after being synched.
That does seem likely - dropbox tries to only upload diffs, when a file gets changed: https://www.dropbox.com/help/8/en
http://www.behind-the-enemy-lines.com/2012/04/google-attack-...
They could not fetch it and have a little blank bit in the thumbnail.
Chances are they're using a library they didn't develop and did not think of the possibility of external resources being loaded.
Edit: The most secure way I can think to handle preview generation is to have a virtual machine firewalled from the internet that previews a single document and is then reverted.
I'd set up a docker to accept a single HTTP post with the document, and to return the thumbnail. The docker can then be shut down and a new instance spun up to wait for the next document to process.
It might be wasteful to spin up a new docker for each instance, but it's the only way to prevent some exploit in LibreOffice[1] that might leak information somehow. A leak could be as terrible as embedding an entire document in the next thumbnail, or as simple as returning the wrong thumbnail (like from a previous request).
[1] LibreOffice was the user-agent that phoned home in the article.
If you're thinking of egress filtering except for the proxy, you can just HTTP tunnel right through it.
"How did this HTTP GET go through to my 'firewalled' PHPmyadmin site?"
You have to treat all user input as if it's toxic.
Also docx files are zip files which opens the possibility of a zipbomb. I wonder if LibreOffice has protection for zipbombs.
It wouldn't surprise me one could engineer a docx bomb that would consume gigs of memory.
Firewall unexpected outbound connections on machines doing their processing.
<img src="https://news.ycombinator.com/y18.gif" />