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

App-udviklere skal overveje nøje, hvornår login-oplysninger skrives ind i app’en, advarer sikkerhedsfirma.

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.

Læs også: Tidligere DSB it-direktør: Drop nirvana-visionen om at favne alt i én app

‘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.

Læs også: Gooligan: Over én million mobile enheder hacket af gammel Android-malware i nye klæder

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.

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

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".

  • 1
  • 1
Bjarne Pedersen

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

  • 1
  • 1
Lars Andersen Hjorth

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ø.

  • 2
  • 0
Jørn Wildt

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?

  • 0
  • 0
Log ind eller Opret konto for at kommentere
Jobfinder Logo
Job fra Jobfinder

Call to action

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. Læs også: Tidligere
DSB it-direktør: Drop nirvana-visionen om at favne alt i én app ‘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 ko...