Database-brøler: Telia sendte 7.000 sms'er til tilfældige mobilbrugere

Under en import til en database blev VARCHAR ved en fejl konverteret til integer. Resultat: Telia sendte ifølge deres kundeservice 7.000 sms'er til vilkårlige danske mobilnumre. Også hos konkurrenterne.

Det var en teknisk fejl, der forleden bevirkede, at adskillige danskere en sms-henvendelse fra Telia om, at deres mobilpakke var blevet opgraderet fra Roam Like Home til Roam Like Home Norden.

Sms’en tikkede vel at mærke ind, uanset om folk var kunder hos Telia eller ej.

Der er dog ikke tale om, at teleselskabet har været på bevidst kundehugst hos konkurrenterne, forsikrer David Engstrøm, pressechef hos Telia.

Derimod skete der torsdag d. 4. juni en teknisk fejl under import af en fil til en database, oplyser pressechefen i en mail. Fejlen opstod, da en underleverandør modtog en liste med de numre - hos Telia - som skulle modtage sms'en.

Et af felterne i listen er det såkaldte MSISDN. Det vil sige det unikke internationale nummer, der identificerer et abonnement i netværket.

MSISDN skulle være sat ind i en kolonne i en MySQL-database, hvor datatypen er det variable string-format VARCHAR. Men i stedet var netop dette felt, altså MSISDN-feltet, sat til tal-typen integer. Og integer-feltet har ikke kunnet rumme MSISDN-dataene.

David Engstrøm, der har været i kontakt med Telias underleverandør, forklarer det således i en mail:

»Filen blev ved en fejl importeret til en forkert temporær database-tabel, hvor ‘MSISDN’-feltet var sat til typen ‘Integer’. Normalt er det sat til typen ‘VARCHAR’, og da et ‘MSISDN’ er for stort et tal til at kunne rummes i en ‘Integer’-type, konverterede import-processen alle ‘MSISDN’ til et tilfældigt tal, som kunne rummes i en ‘Integer’. Import-processen er indbygget i databasen (MySQL) og rapporterede ikke fejl efter import,« skriver han.

De fejlagtigt-konverterede MSISDN-numre blev nu brugt til sms-udsendelse.

»Herefter blev de forkerte MSISDN prefixet med 45 (den danske landekode, red.), og udsendelsen blev igangsat,« skriver pressechefen.

Kundeservice: 7.000 numre

Da der ikke er nogen garanti for, at de fejlkonverterede data faktisk har svaret til et gyldigt og aktivt mobilnummer, svarer antallet af poster på listen, som underleverandøren modtag fra Telia, heller ikke til det faktiske antal sms-modtagere.

Præcist hvor mange poster, der var på listen til at starte med, ønsker David Engstrøm af konkurrencemæssige hensyn ikke at oplyse.

Af en mail fra Telias kundeservice, sendt til en Version2-læser (som ønsker at være anonym), fremgår det, at ca. 7.000 ikke-Telia kunder skulle have modtaget en sms fra selskabet. Telia har dog ikke villet præcisere over for Version2, hvor mange sms'er der er udsendt i alt, og heraf hvor mange der har ramt fungerende telefonnumre.

Siden episoden har Telia været i kontakt med blandt andet Datatilsynet.

»Vi er kede af fejlen og beklager ulejligheden for dem, som fejlagtigt har modtaget sms’en,« skriver David Engstrøm og fortsætter:

»Vi har proaktivt informeret modtagerne af sms’en og vores konkurrenter om fejlen, ligesom vi har været i kontakt med Forbrugerombudsmanden og Datatilsynet.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Christian Rasmussen

Sådan går det jo. Det er ærgerligt og en kende pinligt - men kunne være meget værre. Den fejl begår de nok ikke igen. Umiddelbart er jeg ret positiv over den grad af gennemsigtighed der er omkring fejlen. Ros til både Telia og underleverandør for ikke at pakke det unødigt ind.

  • 24
  • 0
Jakob Møllerhøj Journalist

gad vide om de ikke har ment IMSI nummer, og ikke MSISDN?

Uden selv at have været i kontakt med underleverandøren, tænker jeg, det er MSISDN. Der faktisk er en udgave af mobilnummeret, der kan identificeres i en international sammenhæng. Det vil sige med lande-prefiks og det hele. (Det har jeg præciseret i artiklen.) Og det felt har så åbenbart ikke kunnet rummes i det integer-format, kolonnen i databasen har været sat til.

Skrammeldata er endt op i feltet, og (+)45 er blevet sat foran, hvorefter udsendingen er begyndt.

  • 3
  • 0
Torben Mogensen Blogger

Ja, mysql er per standard sat til at være meget tilgivende.

Det er efter min mening en stor designfejl. Netop når det drejer sig om databaser, bør der være automatisk check på, om man lægger noget data ned i et felt af en anden type, end data selv har. Og helst inden programmet kører. I givet fald ville denne fejl give en typefejl under oversættelse af programmet, men selv en køretidsfejl er at foretrække frem for garbage data.

  • 4
  • 0
Peter Christiansen

Man kan hvis man vil sætte mysql til strict mode, hvor den
kommer med en error i stedet, så programmet stopper den/de query's
der ikke har den rigtige type.

set @@GLOBAL.sql_mode = "STRICT_ALL_TABLES";
set @@SESSION.sql_mode = "STRICT_ALL_TABLES";

eller man kan rette det i /etc/my.cnf eller hvor denne måtte ligge.

Men normalt checker man alligevel data, felt for felt
før man indsætter i databasen, det burde man i hvertfald.

  • 2
  • 0
Christian Nobel

Normalt er MySQL ret tilgivende som David siger.

Hvis man sætter en alfanumerisk værdi ind i en integer, konverteres den til 0.
Hvis man sætter en floating point værdi ind, skæres alle decimaler væk.
Hvis man sætter en integer ind, som er større end 31 bit, sættes den til maksværdien 7FFF FFFF.

  • 1
  • 0
Torben Mogensen Blogger

Du har jo ingen dataværdier under kompilering, så du kan da kun lave check under afvikling, med mindre du er i besiddelse af en krystalkugle.

Du har vist ikke helt forstået konceptet med statiske typer: Her har hver variabel en specifik type, og det garanteres under oversættelse af programmet, at der aldrig kommer en værdi af en anden type ind i denne variabel.

For at det virker med databaser, skal hver database udstyres med en type, sådan at man kan checke, om et program bruger denne type korrekt.

Programmer, der er generiske over flere forskellige databasetyper, kan bruge polymorfe/generiske typer.

  • 1
  • 0
Christian Nobel

Du har vist ikke helt forstået konceptet med statiske typer: Her har hver variabel en specifik type, og det garanteres under oversættelse af programmet, at der aldrig kommer en værdi af en anden type ind i denne variabel.

Jo jeg har udmærket forstået.

Og selvfølgelig kan man definere variable som statiske typer, man kan f.eks. ikke andet i Pascal.

Og man kan også lave typecheck i sit program, eller man kan lade exception handling stå for det, hvis f.eks. den underliggende database brokker sig.

Eller jeg kan lave programmæssige check som tage forbehold for forkerte typer.

Men jeg kan aldrig på kompileringstidspunktet gardere mig mod at en eller anden bøhtosse ved afvikling kunne finde på at prøve at proppe en float ned i en integer - det er nonsens.

  • 1
  • 1
Henrik Snog

Hvorfor kaldes den omtalte fejl -- og mange andre lignende -- for en 'teknisk fejl'? Det er vel en banal menneskelig fejl, der efterfølgende ikke er blevet fanget på grund af en banal menneskelig undladelsessynd.

  • 3
  • 0
Brian Jensen

Du har vist ikke helt forstået konceptet med statiske typer: Her har hver variabel en specifik type, og det garanteres under oversættelse af programmet, at der aldrig kommer en værdi af en anden type ind i denne variabel.

For at det virker med databaser, skal hver database udstyres med en type, sådan at man kan checke, om et program bruger denne type korrekt.

Programmer, der er generiske over flere forskellige databasetyper, kan bruge polymorfe/generiske typer.

Nu står der jo i artiklen at det er en temporær tabel der er brugt under import. Hvis data så flyttes fra den over i den som applikationen har fat i, vil du have din implicitte konvertering fra Source (varchar) --> temp (int) --> target (varchar). Så hvis ikke din mySQL fanger problemet, er du screwed fordi kolonnen har samme datatype i source og target :)

  • 1
  • 0
Log ind eller Opret konto for at kommentere