Dropbox reset gedeelde links om 'beveiligingsprobleem'

Dropbox heeft alle links die gebruikers hebben gedeeld gereset, nadat bleek dat links naar gedeelde bestanden onbedoeld konden uitlekken. De opslagdienst hield geen rekening met referer-headers. Daardoor konden gelinkte sites achter de url's van bestanden komen.

Een link naar een bestand dat op Dropbox was gedeeld kon worden gelekt naar een gelinkte site doordat browsers een referer-header meesturen naar gelinkte sites, waardoor die site kan zien vanaf welke url de gebruiker kwam. Dropbox had daar geen rekening mee gehouden en heeft nu uit voorzorg alle shared-links naar documenten waarin links zouden kunnen staan ongeldig gemaakt. Links naar afbeeldingen zijn dus nog wel toegankelijk, maar die naar een pdf bijvoorbeeld niet.

Voor alle nieuwe links is er geen sprake meer van een beveiligingsrisico, stelt Dropbox. Het lijkt er op dat de cloudopslagdienst het beveiligingsprobleem heeft opgelost door gebruikers te dwingen om bestanden lokaal op te slaan voordat ze kunnen worden geopend. Het probleem is overigens niet opgelost voor bestanden die in de 'Public'-folder van Dropbox-gebruikers staan; die links zijn niet gereset en gebruikers moeten daar nog steeds rekening houden met het referer-'probleem'.

Het probleem werd ontdekt door Intralinks, een concurrent van Dropbox. Ook de cloudopslagdienst Box.net heeft last van het referer-probleem, maar dat bedrijf heeft voor zover bekend nog geen oplossing uitgerold.

Reacties (43)

[Pinobigbird]

Volgens mij gaat het hierom:
Als ik een document deel met als link A, en in dat document staat een hyperlink naar site B, dan kan de webmaster van site B de gedeelde link A zien in de serverlogs als vanuit dat document geklikt wordt op de hyperlink.

[Jeroen2289]

Dit speelt al heel lang. Ik kreeg met regelmaat links die ik vervolgens doorstuurde naar een ander email adres van mij. Kon vervolgens de bestanden nog steeds openen..

Wellicht had ik het moeten melden;)

[BtM909]

Dit is een ander probleem. Het artikel is helaas niet duidelijk genoeg, maar de bron weer wel:

[q]For background, whenever you click on a link in any browser, the site you’re going to learns where you came from by something called a referer header.

[...]

Dropbox users can share links to any file or folder in their Dropbox. Files shared via links are only accessible to people who have the link. However, shared links to documents can be inadvertently disclosed to unintended recipients in the following scenario:

• A Dropbox user shares a link to a document that contains a hyperlink to a third-party website.
• The user, or an authorized recipient of the link, clicks on a hyperlink in the document.
• At that point, the referer header discloses the original shared link to the third-party website.
• Someone with access to that header, such as the webmaster of the third-party website, could then access the link to the shared document.

[BtM909]

Dropbox heeft nooit beweerd dat die link alleen voor 1 persoon toegankelijk is. Ze zeggen het nota bene zelf (in het stuk wat ik quote). Iedereen met toegang tot die link heeft het recht om die shared link te zien.

[Anoniem: 457607]

Een dergelijke techniek heet ook wel 'obfuscation, iets beveiligen door het moeilijk raadbaar te maken, maar niet echt beveiligen. Het is niet per definitie onveilig, zo zijn heel erg veel activatie emails bij websites op hetzelfde principe gebaseerd.

[Gomez12]

Activatie emails bij websites hebben over het algemeen nog een geldigheidsduur zodat het moeilijker te vinden is.

[Anoniem: 516179]

Nee obfuscation is wanneer er een beveiligingsprobleem is en men poogt dit te verbergen. Het probleem bestaat nog steeds en met wat moeite kan men hetgeen verborgen is weer zichtbaar maken.

Deze vorm van link delen, e-mail activatielinks en een gebruikersnaam/wachtwoord combinatie wordt 'shared secret' genoemd. Daar is helemaal niets mis mee en de basis van de meeste vormen van beveiliging. Immers als de data goed beveiligd zou zijn heeft niemand er meer toegang toe. De truc bij beveiliging is om enkel degene die jij wil toegang te geven en de rest niet.

[swtimmer]

Dit soort links word veel gebruikt in mailinglijsten bijv, waar je de content met die mensen wil delen zonder dat het per direct helemaal public is. Soort van tussenstap.

Persoonlijk maak ik er dan ook wel veel gebruik van. Ander voordeel is dat met zo'n link je geen dropbox account hoeft te hebben om toegang te krijgen. Zo te lezen is dat vanaf nu dus wel zo.

[Devilfish]

Dat is iets totaal anders, deze bug gaat er om dat als jij doorklikt vanuit een dropbox document op hun website, de website waar je naar doorklikt ziet waar je vandaan komt: het eigenlijk beschermde document.

[Wailing_Banshee]

Ah, dat maakt het wat duidelijker!

Dus een document wat ik eigenlijk helemaal niet "gelinked" had, kon dan dus wel door een derde gezien worden...

[.oisyn]

Persoon A heeft een document.
Persoon A deelt een link naar dat document met Persoon B. Feitelijk kan iedereen met die link het document opvragen.
Persoon B bekijkt het document en klikt op een link (naar een externe website) in het document.
De browser van Persoon B stuurt naar de externe website een header mee waar Persoon B vandaan kwam - dat was dus de "geheime" gedeelde link.
De webmaster van de site, persoon C, ziet de link in zijn logs en kan nu ook dat document bekijken.

Dus nee, een document dat jij niet gelinkt hebt kan niet zomaar door iemand bekeken worden. Pas als jij het document deelt (en daarvoor dus een speciale link hebt), en iemand klikt op een link binnen het document via de gedeelde link, dan kan het doel van de geklikte link achterhalen wat de link naar het gedeelde document is.

[Reactie gewijzigd door .oisyn op 29 juli 2024 14:43]

[Wailing_Banshee]

Dan is het geen probleem voor mij, aangezien ik altijd alleen plaatjes deel met mensen via mijn dropbox

(en ik heb laatst eens opruiming gehouden in mijn shared links lijst...)

[Anoniem: 368883]

Als ik het goed begrijp, komt het er gewoon op neer dat de link als REFERER wordt opgenomen als op een link klikt in het document. En de destination van de link ziet gewoon de REFERER in de HTTP request natuurlijk.

[Rutix]

Jij ving dus de links op via je site? Want een link van jezelf doorsturen dat maakt toch niet uit. Het punt was dat sites konden zien dat je van een gedeelde dropbox url kwam.

[Jeroen2289]

nee ik ontvang dan een link van Gebruiker A naar B en die link kan ik met gebruiker C alsnog openen. Tenminste tot een paar maand geleden kon dat wel, laatste tijd doe ik weinig met dropbox.

[Fawn]

Het idee is dat de link toegang geeft.
Als jij dus toevallig een link ontvangt omdat gebruiker A die per ongeluk naar je stuurt, dan is dat een goedwerkende functionaliteit aan de kant van Dropbox en een onhandigheid van gebruiker A

[Armin]

Nou ja, zie het zo: gebruiker A stuurt een lin naar gebruiker B. B deelt het vervolgens met C en C download van A. A vindt dat niet zo leuk ...

Nu zal ik de eerste zijn die zal beamen dat B natuurlijk ook de data zelf zou kunnen downloaden, en dan delen met C, maar qua logging staat het aanbieden nu op de naam van A. Juridisch maakt dat wel degelijk uit in sommige context.

Maar ja, als dat relevant is, is het waarschijnlijk beter uberhaupt geen dropbox te gebruiken ...

Maar goed, dat is dus niet het probleem zoals hier beschreven. Het probleem zoals hier bechreven is dat mensen zonder dat de link explciiet gedeeld werd, toch de link konden/kunnen zien. Dit als de dropbox link zéf ook naar een andere URL verwijst bijvoorbeeld. De website van die tweede URL krijgt dan de bron-link in de referal header meegestuurd.

[fantafriday]

dat is het hele idee achter het link delen (meestal)

[Foxpat]

Dat is niet echt relevant. Het gaat hier om een heel ander probleem.

[tommyx]

ze zouden een timer in moeten stellen dat zo'n link automatisch wordt gegenereerd met een "levensduur"van 48uur.

[We Are Borg]

Wat helpt die 48 uur dan? Binnen 48 uur kan dit probleem zich prima voordoen

De oplossing van dropbox vind ik niet erg gebruiksvriendelijk dat je nu eerst moet opslaan. Maar ik vraag me af of je het technisch anders kan oplossen. Ik kan het me niet bedenken

[tommyx]

48uur was een random aanname

[Rutix]

Dat zouden ze dan wel optioneel moeten maken want ik gebruik gewoon shared links voor langdurige access tot sommige van mijn folders hoor.

[Anoniem: 543869]

Ik vind het sympathiek dat Intralinks het gemeld heeft (denk ik, staat er niet echt duideljik in).
Dat Dropbox alle links heeft gereset is een tijdelijk goeie oplossing, nu nog de fix uitrollen en dan gewoon alle links terug herstellen, eventueel door Dropbox zelf

[JKP]

Het is inderdaad wenselijk dat Dropbox de links terugplaatst. Tegelijk laat het zien dat er wel een aantal tekortkomingen zitten aan het huidige systeem van het delen van links.

Op z'n minst zou het wenselijk zijn dat je als gebruiker de mogelijkheid om eigen links aan te maken. Nu bepaald Dropbox ten alle tijden hoe de link eruit komt te zien. Soms zou je daar juist meer controle over willen hebben.

Er zijn bepaalde documenten waarvan het me weinig zou interesseren als iemand anders die leest. Echter heb ik geen mogelijkheid om de links te herstellen. Ik word gedwongen een nieuwe aan te maken. Het zou in zo'n geval mooi zijn als je de controle hebt hoe de links eruit komen te zien.

[Ravefiend]

Die links kunnen niet hersteld worden want nu dit bekend is, kan iedere webmaster zijn logs gaan doorspitten op zoek naar referer header links die naar Dropbox verwijzen. Deze links maken het mogelijk om bestanden op halen van Dropbox waar die webmaster niets mee van doen heeft omdat deze bestanden enkel via die 'gedeelde' link benaderdbaar zijn en de eigenaar van die link hoort te bepalen met wie hij die link deelt.

[Reactie gewijzigd door Ravefiend op 29 juli 2024 14:43]

[JKP]

Ik vroeg me dit af, omdat er op dropbox het onderstaande stond:

For previously shared links to such documents, we’ve disabled access entirely until further notice. We’re working to restore links that aren’t susceptible to this vulnerability over the next few days.

Dit vind ik een vreemde zin. De links zouden dus niet allemaal de kwetsbaarheid bevatten. Het enige wat ik me voor kan stellen is dat ze controleren of het bestand geopend is via de link.

[Armin]

Tegelijk laat het zien dat er wel een aantal tekortkomingen zitten aan het huidige systeem van het delen van links.


Als ik privacy paranoide zou zijn, zou ik zeggen dat referral headers 'evil' zijn.

Deze hebben doorgaans slechts zeer beperkt nut voor de surfer, maar worden vooral gebruikt voor website statistieken. In feite een vorm van tracking. Natuurlijk komen de website bouwers en beheerders dan weer aan met allerlei verhalen hoe dat indirect toch weer in mijn belang is, maar feit is dat voor mijn rechtstreekse surfgedrag het eigenlijk geen enkel nut heeft.

Er wordt ongevraagd informatie (zij het zeer beperkt) doorgestuurd over mijn vroegere surfgedrag, naar een website die ik bezoek.

[beun92]

_{Het probleem werd ontdekt door Intralinks, een concurrent van Dropbox.}
wel een nette actie van Intralinks!!

[BtM909]

Het is meer om aan te tonen dat de concurrent de beveiliging slechter op orde heeft

[beun92]

goed punt, maar zoals ik het artikel bekijk van Intralinks is het niet direct gericht op Dropbox maar meer in algemeen. wel word er aan het eind een update gegeven over de dropbox blog post.
zo krijgen ze i.i.g. wel positieve aandacht.

[Morgoth]

Natuurlijk moeten beveiligingsproblemen gemaakt worden en wellicht dat dit de enige oplossing is, maar ik vind dit wel behoorlijk onhandig. Op sommige sites waar ik geen controle over heb wordt gelinkt naar door mij gedeelde documenten (ik weet, niet echt professioneel). Die doen het nu allemaal niet meer. Had het wel netjes gevonden van Dropbox als ik daar een mail over had gehad in plaats van dat ik dit op tweakers moet lezen.

[We Are Borg]

Zouden ze niet linkjes kunnen vervangen door een eigen redirect? Dus scannen op linkjes, die vervangen door www.dropbox.com/link/23912731207 bijvoorbeeld en die dan redirecten naar de echte link die geplaatst is in het document? Dan kan je voorkomen dat een referer wordt doorgegeven en is gebruiksvriendelijker dan dit. Nadeel is dat je niet meer kunt zien wat de orginele link is voordat je er op klikt, maar dat kan je met een title op de link oplossen

[Anoniem: 587244]

Zo zou ik het inderdaad oplossen

[Boemklaas]

Ik geloof dat ik het ook niet helemaal begrijp.
In ieder geval goed dat het opgelost is, met 2 jaar aan foto's op dropbox wil ik wel dat het "veilig" is.

[Pinobigbird]

Gedeelde links naar foto's zijn niet aangetast. Alleen gedeelde links naar documenten met hyperlinks zijn verwijderd, volgens de bron.

[fre0n]

het is veilig totdat het volgende lek gevonden wordt natuurlijk. Ook zul je een backup moeten hebben, want wat dat betreft heb je bij een externe partij natuurlijk nooit garanties

[JKP]

Foto's is niets mee aan de hand. Het gaat om documenten die een hyperlink bevatten naar een andere website.

Toch zou ik mijn foto's op meer locaties plaatsen dan dan alleen op Dropbox. En dan bedoel ik op een locatie die niet op internet staat. En al mocht je dat wel willen, overweeg dan eens een WD My Cloud harde schijf. Een andere alternatief is bij een hostingprovider wat webruimte opkopen en de foto's via FTP uploaden.

Verder is veiligheid altijd maar relatief. Wel goed om ernaar te kijken, maar wanneer jij wilt dat foto's nooit uitlekken, dan zou ik ze juist niet op diensten als Dropbox zetten. Houd foto's in zo'n geval beperkt tot een offline opslag.

[Boemklaas]

Nogal late reactie maar dropbox is gelukkig niet mijn primaire back up, dat is gewoon een van mn hdd's. Ik vind het ideaal werken op mn mobiel en pc en deel zelf nooit links van bestanden op dropbox, ik download enkel af en toe een bestand wat ik zelf weer verstuur.
In ieder geval bedankt voor de uitleg!

[Cilph]

Kan iemand anders het wat duidelijker uitleggen?

EDIT: Dropbox blog is duidelijk genoeg.

[Reactie gewijzigd door Cilph op 29 juli 2024 14:43]

[Bosmonster]

Het probleem is overigens niet opgelost voor bestanden die in de 'Public'-folder van Dropbox-gebruikers staan; die links zijn niet gereset en gebruikers moeten daar nog steeds rekening houden met het referer-'probleem'.

Daar is het uberhaupt geen probleem, want die zijn dus... public...