Twitter waarschuwt ontwikkelaars voor mogelijk lekken van api-sleutels

Twitter heeft ontwikkelaars die van de api gebruikmaken een waarschuwing gestuurd vanwege potentieel lekken van api-sleutels. Door een foute instelling op de ontwikkelaarspagina van Twitter, zijn api-sleutels en toegangstokens binnen de browser opgeslagen.

Dat meldt ZDnet op basis van e-mails die naar ontwikkelaars zijn gestuurd. Een foute configuratie van developer.twitter.com zorgde ervoor dat per ongeluk api-gegevens zijn opgeslagen binnen de browser die door de ontwikkelaar wordt gebruikt. Dat hoeft in de meeste gevallen niet tot een beveiligingsprobleem te leiden, maar als er van een publieke pc gebruikgemaakt wordt, kunnen de gegevens mogelijk buitgemaakt worden.

Twitter heeft inmiddels het cachingprobleem met de api-sleutels en toegangstokens opgelost, zodat deze niet meer binnen de browser worden opgeslagen. Wat de oorzaak is van de foute instelling op het ontwikkelaarsplatform is door Twitter niet bekendgemaakt.

Er is verder geen bewijs dat kwaadwillenden de foute instelling in developer.twitter.com hebben misbruikt om api-gegevens te stelen. Aanvallers zouden dan zowel kennis van de bug moeten hebben als toegang tot de browser die de ontwikkelaar gebruikt. Daar heeft de sociale-netwerksite geen bewijs van gevonden, en de waarschuwing is daardoor voornamelijk uit voorzorg gestuurd.

Reacties (15)

Dit klinkt als exact hetzelfde cache-probleem als ze een half jaar geleden ook al hadden op twitter.com zelf:

nieuws: Twitter waarschuwt dat Firefox privégegevens in cache opsloeg - update

Ik had de mail ook gehad ja, maar ik denk dat de exploit cases hiermee vrij laag is, hoeveel mensen werken aan een API vanaf een computer die door meerdere mensen met eventueel slechte bedoelingen word gebruikt? ik denk haast nihil, maar het is goed om te melden natuurlijk, mogelijk dat dus ook andere processen op je computer die key hadden kunnen zien, maar ja als je op die zelfde pc toch al aan de API werkt, kunnen ze zie key ook wel elders zien, dus de daadwerkelijke impact zal erg laag zijn.

Ohja even tokens generen in de bieb

Het zien van de tokens was genoeg. Dus ja dat is potentieel veel vaker voorkomend, waardoor het zeker het melden waard is.

Nee, want die tokens kun je maar één keer zien, als je ze genereert.

Oh nee, dat was bij letterlijk elke andere implementatie van API tokens, bij Twitter kun je ze juist wel recyclen volgens mij.

[Reactie gewijzigd door theguyofdoom op 27 september 2020 18:56]

Het is natuurlijk goed dat Twitter een waarschuwing geeft dat je mogelijk gevoelige gegevens kan lekken. Maar wat ik mis is de duidelijkheid dat je als ontwikkelaar die tokens natuurlijk niet moet gebruiken alsof ze niet in een cache kunnen achterblijven. @Gamebuster heeft dus wel degelijk een heel sterk argument: zorg er hoe dan ook voor dat je een token die je hergebruikt niet zomaar ergens gebruikt waar ook anderen die je niet kent bij kunnen.

Het is natuurlijk ook wel aan te raden om tokens af en toe eens te vernieuwen. Dat zou men ook aan de kant van Twitter kunnen afdwingen door er gewoon een vervaldatum op te zetten.

Is dat zo? Van wachtwoorden is het op zijn minst punt van discussie of je die nou wel of niet met enige regelmaat zou moeten vervangen. Geldt dat ook niet net zo voor tokens?

Hoe langer je iets niet verandert hoe groter de kans dat het ooit misbruikt kan worden. De kans dat iets lekt is immers direct afhankelijk van de tijd.

Een belangrijk onderdeel van security is beschikbaarheid, en dat aspect lijdt als er niet operationeel wordt geborgd dat de tokens regelmatig worden geüpdatet. Kijk maar hoe vaak er systemen op hun plaat gaan door een verlopen SSL certificaat (en daar is operationele borging mogelijk omdat de vervaldatum in het certificaat staat, wat bij tokens doorgaans niet het geval is).

Als dezelfde api-key door een nieuw ip-adres wordt gebruikt of pas na een x aantal maanden door een oud ip-adres, zou er toch ook een waarschuwingsmail in de inbox moeten belanden?

De opstelling van vernieuwen à la certification van Let's Encrypt kàn, maar is schijnveiligheid als er al malware op de device zit dit èn de api-key èn het ip-adres gebruikt.

Als niet veranderen het uitgangspunt is dan heb je waarschijnlijk veel vertrouwen dat niemand dat token ooit kan achterhalen of weinig vertrouwen dat het wijzigen je geen problemen geeft.

Voor wachtwoorden is deze discussie er omdat mensen dan een systeempje gaan gebruiken in hun wachtwoord. (Bvb Januari001 wordt dan Februari002. Zo kan je alsnog heel snel het wachtwoord raden als je eens een oud wachtwoord te pakken kan krijgen)

Als je tokens gaat vervangen wordt die random superlange nonsens reeks van letters vervangen door een nieuwe random superlange nonsens reeks van letters. Er is geen correlatie tussen, dus snel vervangen mag zeker.

(Fyi : als je van een wachtwoord manager gebruik maakt kan je uw wachtwoorden ook als lange nonsens reeks van letters hebben hebben ipv dat er een regeltje in zit en dan is dat probleem er ook niet meer)

Daar zit inderdaad wat in; een token vervangen is niet zo ingewikkeld. Een wachtwoord moet je weer bedenken en onthouden, tenzij je een wachtwoordmanager hebt.
OT: Persoonlijk gebruik ik BitWarden, met wachtwoorden á la "dsb#nMtyZs5QNf"

Ik schrok wel even toen ik de mail kreeg want ik was eerlijk gezegd vergeten dat ik ooit software had die de Twitter api gebruikte. Het goede nieuws is natuurlijk wel dat die tokens hier werken zoals ontworpen. Als ze lekken gooi je de tokens weg maar het hoofdwachtwoord van de gebruiker blijft veilig.