Udviklere gennemtrawler Android-apps: Hundredvis af login-oplysninger indskrevet i koden

17. januar 2017 kl. 11:3311
App-udviklere skal overveje nøje, hvornår login-oplysninger skrives ind i app’en, advarer sikkerhedsfirma.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Sikkerhedsfirmaet Fallible har reversed engineered 16.000 Android-apps og fundet et væld af oplysninger, som optimalt set ikke burde være tilgængeligt for andre end app-udviklerne.

Af de undersøgte apps indeholdt 2.500 enten hemmeligheder eller tredjepartsnøgler, skriver The Register.

‘Nogle nøgler er harmløse og er nødt til at være i app’en, som for eksempel nøgler til Googles API, men der var mange API-hemmeligheder, som helt sikkert ikke burde være i apps'ne,’ fortæller selskabet i en blog.

I alt fandt gennemgangen 304 følsomme nøgler. I flere tilfælde fandt selskabet oplysninger total-adgang til konti hos Amazon Web Services, som f.eks. gav mulighed for at slette indhold i skyen.

Artiklen fortsætter efter annoncen

De mest almindelige følsomme tredjepartsnøgler, Fallible har fundet, knytter sig til Twitter og Urban Airship.

‘For app-udviklere, der læser dette: Når som helst du hardcoder en API-nøgle eller token ind i din app, så tænk på, om du virkelig har brug for at hardcode det,’ skriver Fallible, der har brugt selskabets online kode-analyseværktøj til at gennemtrawle appsene.

11 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
11
18. januar 2017 kl. 14:54

Tak for kommentarene.

Jeg er glad for, at artiklen bringer smil frem :) Men nu er teksten ændret.

Bedste hilsner

10
18. januar 2017 kl. 09:41

Må jeg foreslå at fokusere på artiklen.

Årrh, må vi ikke have det lidt sjovt :-)

Jeg koder af og til små værktøjer som kan gøre vores hverdag nemmere, og det sker da at jeg føler mig nødsaget til at indlejre adgangskoden til vores versionsstyringssystem eller den standard netværksbruger som vi alle sammen bruger til at komme på firmaets netværksdomæne med.

Okay, spøg til side, som man siger.

Her er et eksempel på en løsning: under windows kan man fx bruge "integrated authentication" mod databaser (men ikke nødvendigvis et versionsstyringssystem). Herefter sørger man for at sine services kører som en bestemt Windows bruger, som gives direkte adgang til databasen. På den måde undgår man at indlejre credentials i programmet eller dets config-filer - adgang er givet ved den bruger processen kører som.

Tilsvarende under Windows er det muligt at kryptere en string (loginnavn+password eller tilsvarende) og gemme det et sted i operativsystemet, således at det kun er muligt at aflæse værdien for en bestemt bruger. Hvis man så sørger for at sine services kører som denne bruger, så kan servicen slå sine credentials op på en sikker måde uden at andre kan læse dem.

Jeg er desværre ikke bekendt med tilsvarende løsninger for Android apps (og det er formentlig umuligt at undgå at en eller anden "hemmelighed" gemmes indlejret i app'en). Det er, mig bekendt, i hvert fald normalt at apps har deres egne API-nøgler og at disse IKKE må anses for super hemmelige, da app'en til enhver tid kan de-kompileres som beskrevet i artiklen.

Derfor er det noget nær en nødvendighed at man som bruger skal logge ind på en app med sit eget app-specifikke brugernavn, for så kan serveren styre adgang via dette login. Eksemplet fra artiklen med fuld admin adgang til en Amazon konto bør ikke være nødvendig.

Jeg hører også gerne om andre løsninger?

9
17. januar 2017 kl. 22:06

Må jeg foreslå at fokusere på artiklen. Jeg koder af og til små værktøjer som kan gøre vores hverdag nemmere, og det sker da at jeg føler mig nødsaget til at indlejre adgangskoden til vores versionsstyringssystem eller den standard netværksbruger som vi alle sammen bruger til at komme på firmaets netværksdomæne med. Jeg ved godt at disse programmer er dedikeret til brug inden for virksomhedens fire vægge men det er da alligevel en betydelig sikkerhedsbrist eller hvad? Vi har kun få brugernavne som går igen til alle vores virtuelle testcomputere og byggemaskiner. Det undrer mig egentlig at vores IT afdeling accepterer at vi aldrig skifter adgangskoden for disse brugere, men det glæder mig for ellers ville det være ret umuligt at holde styr på vores udviklingsmiljø.

8
17. januar 2017 kl. 21:03

Må jeg forslå at oversætte sensitiv til følsom?

7
17. januar 2017 kl. 19:44

Så hellere "indlejrede"

6
17. januar 2017 kl. 16:32

haha - den morede jeg mig sgu også over :D

"hårdkodede" - jeg plejer normalt at foretrække dansk hvor det er muligt, men lige det ord giver absolut ingen mening....

Men derimod syntes jeg at "Indgroede API nøgler" - det må være det nyeste og mest passende udtryk for hardcoded :D

4
17. januar 2017 kl. 14:47

Jeg har ikke læst artiklen. Er her udelukkende for at kommentere på "hårdkodede".

Hatten af til Magnus Boye, for at opfinde et grimmere udtryk end "brandmur" og "infokage".

3
17. januar 2017 kl. 13:20

Og hvis man endelig skal tosse rund i mærkelige fordanskninger der blot "opfuskerer" ;) teksten, hvorfor så ikke login-oplysninger? "log på oplysninger"?

2
17. januar 2017 kl. 12:28

Og hvis det skal fordanskes, må det være hårdtkodede. (analogt med hårdtslående)