Denne side indeholder hjælp til SDK-udbydere, der bruger Google Play SDK Console.
Hvis du er appudvikler og leder efter hjælp til Google Play Console, kan du bruge søgefeltet eller gå tilbage til startsiden.
Du kan bruge SDK Console til at holde dig orienteret om potentielle politikrelaterede problemer eller sikkerhedsbrister, som påvirker dine SDK-versioner. Det er vigtigt at være orienteret om denne type problemer for at sikre, at Google Play forbliver sikkert og for at undgå potentielle negative konsekvenser for dine SDK'er. Dette kan omfatte, at registreringsbadget fjernes, eller adgangen til funktioner i Google Play SDK Console begrænses.
SDK-versioner med potentielle politikrelaterede problemer
Hvis du har SDK-versioner, som er kendt for at få de apps, der anvender dem, til at overtræde vores politik vedrørende SDK-krav eller andre af Google Plays programpolitikker for udviklere, markeres disse versioner på en måde, hvor det fremgår, at de ikke overholder politikkerne, i SDK Console. Nye appversioner, der er udgivet i Google Play, og som bruger disse versioner, afvises, og udviklerne bliver bedt om at finde en version, der overholder politikkerne, inden de indsender deres app igen.
Screenshottet nedenfor viser et eksempel på en SDK-version, hvor en politikovertrædelse er fremhævet:
Screenshottet nedenfor viser et eksempel på den udvidede SDK-version, der indeholder oplysninger om det rapporterede problem:
Hvis der registreres et politikrelateret problem med din SDK, får du i overensstemmelse med servicevilkårene for SDK Console en meddelelse om og vejledning i, hvordan du løser problemet og indsender en ny SDK-version til gennemgang. Når håndhævelsesprocessen for eksisterende apps er gennemført, sørger SDK Console for, at de problematiske SDK-versioner markeres på en måde, hvor det fremgår, at de ikke overholder politikkerne, og nye appversioner, der indeholder versionen, kan ikke udgives, før de har skiftet til en version, der overholder politikkerne.
Mulige konsekvenser ved gentagne SDK-relaterede politikovertrædelser
Google Play bestræber sig på at understøtte et sikkert og pålideligt økosystem for både udviklere og brugere. Som en del af denne bestræbelse implementerer vi en forbedret tilgang, der skal begrænse gentagne overtrædelser af Google Play-politikker, som er forårsaget af SDK'er:
Afhængigt af overtrædelsernes omfang og hyppighed kan konsekvenserne omfatte, men er ikke begrænset til:
- Fjernelse af registreringsbadge: Gentagne overtrædelser og/eller overtrædelsens alvorlighed kan medføre fjernelse af det registreringsbadge, der vises i Google Play SDK Index. Badget angiver, at SDK'en er registreret i Google Play SDK Console, og at udbyderen af denne SDK har accepteret servicevilkårene for Google Play SDK Console, hvilket omfatter en forpligtelse til, at udbyderens SDK'er ikke medfører, at apps overtræder Google Play-politikkerne.
- Begrænset adgang til funktioner i Google Play SDK Console: I tilfælde af SDK'er, der forårsager gentagne politikovertrædelser fra appudviklere, eller hvis overtrædelsen er alvorlig, forbeholder vi os retten til at fjerne adgangen til vigtige funktioner i SDK Console.
Bemærk! SDK-udbydere kan stadig anmode om oplysninger vedrørende beslutninger. I denne artikel i Hjælp og i Google Plays programpolitikker for udviklere kan du få flere oplysninger om sikker brug af SDK'er.
SDK-versioner med potentielle sikkerhedsbrister
En sårbarhed er en brist eller fejl i koden, som kan udnyttes af en ondsindet aktør. SDK Console advarer dig om potentielle sikkerhedsbrister, der påvirker dine SDK-versioner. Nedenfor kan du finde oplysninger om de sårbarheder, der kan påvirke din SDK, og hvordan du løser disse problemer.
Sådan løser du problemer med SDK'er, der indeholder usikre krypteringsmønstre
Din SDK indeholder usikre krypteringsmønstre. Det vil sige, at en krypteringstekst genereres med en statisk beregnet hemmelig nøgle, salt eller initialiseringsvektor (IV, initialization vector).
Hvis en app anvender din SDK, modtager den en underretning i Play Console. Du skal løse problemet med sikkerhedsbristen i din SDK for at forhindre, at apps, der anvender din SDK, modtager underretninger.
Følg nedenstående vejledning for at løse problemet i din SDK. Du kan se, hvor i din SDK der er usikker krypteringskode, i SDK Console-notifikationen til din SDK.
Yderligere oplysninger
Gennemgå din SDK for statisk beregnede nøgler, initialiseringsvektorer og/eller salte, der bruges i krypteringsoperationer, og sørg for, at disse værdier er konstrueret sikkert. Følgende kode bruger f.eks. en hemmelig nøgle og en initialiseringsvektor, der kan beregnes statisk:
// Console-underretningen henviser til denne metode
public byte[] encryptionUtil(String key, String iv, byte[] plainText) {
Cipher cipher = Cipher.getInstance(“AES/GCM/NoPadding”);
SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), “AES”);
GCMParameterSpec paramSpec = new GCMParameterSpec(256, iv.getBytes());
cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
return cipher.doFinal(plainText);
}
// Den usikre nøgle og initialiseringsvektor er her og bør ændres
byte[] cipherText = encryptionUtil(“abcdef...”, “010203040506”, plainText);
Statisk beregnede værdier
En statisk beregnet værdi er en værdi, der er ens ved hver udførelse af en funktion. Statisk beregnede værdier kan udtrækkes af din SDK og bruges til at angribe en apps krypterede data. Selv hvis du manipulerer nøgler, initialiseringsvektorer og salte på komplekse måder inden brug, forbliver de usikre, hvis disse manipulationer er de samme for hver programkørsel.
Den bedste praksis for Android
Vi anbefaler, at du bruger Jetpack Security til symmetrisk kryptografi. Hvis din SDK krypterer API-nøgler, personhenførbare oplysninger eller andre følsomme oplysninger, kan EncryptedSharedPreferences bruges til at gemme disse data sikkert, uden at du skal bekymre dig om implementeringen af hemmelige nøgler, initialiseringsvektorer og salte. Der er flere optimale løsninger og eksempler på denne side. Udviklere bør bruge TLS/SSL til at sikre data ved transmission til andre systemer.
Jetpack Security bruger Googles open source-projekt Tink til at håndtere symmetrisk godkendt kryptering. Hvis du har avancerede eksempler på brug af operationer på lavere niveau, anbefaler vi, at du bruger Tink direkte.
Hvis den førnævnte bedste praksis for Android ikke lever op til dine eksempler på brug, og du har til opgave eksplicit at administrere nøgler, initialiseringsvektorer og salte, anbefaler vi, at du følger disse standarder:
- Hemmelige nøgler: Symmetriske hemmelige nøgler skal være uforudsigelige og hemmelige. Når lokale data krypteres, bør udviklere konstruere hemmelige nøgler ved hjælp af kryptografisk sikker tilfældighed (eller fra brugergenereret data, hvis de bruger PBEKeySpecs) og gemme de hemmelige nøgler ved hjælp af AndroidKeystore.
- Initialiseringsvektorer: Initialiseringsvektorer skal være unikke og uforudsigelige i flere meddelelser, men behøver ikke at være hemmelige. Udviklere bør konstruere initialiseringsvektorer ved hjælp af kryptografisk sikker tilfældighed. Udviklere bør gemme eller overføre initialiseringsvektorer sammen med den tilhørende ciffertekst.
- Salte: Salte skal være unikke og uforudsigelige på tværs af flere hashes, men behøver ikke at være hemmelige. Udviklere bør konstruere salte ved hjælp af kryptografisk sikker tilfældighed. Udviklere bør opbevare eller overføre salte sammen med de tilhørende hashes.
Sådan løser du problemer med SDK'er, der bruger mindre sikre krypteringstilstande
Din SDK indeholder kryptering, der anvender den mindre sikre tilstand AES/ECB. Kryptering af indhold ved hjælp af denne usikre tilstand kan medføre usikker krypteringstekst og kompromittere brugerdata.
Hvis en app anvender din SDK, modtager den en underretning i Play Console. Du skal løse problemet med sikkerhedsbristen i din SDK for at forhindre, at apps, der anvender din SDK, modtager underretninger.
Følg nedenstående vejledning for at løse problemet i din SDK. Du kan finde kodeplaceringerne for de mindre sikre krypteringstilstande i SDK Console-notifikationen til din SDK.
Yderligere oplysninger
Tjek, hvor i din SDK der er instantieret en krypteringsalgoritme. Følgende konfigurationstilstande indikerer, at der anvendes usikker AES/ECB:
"AES"
"AES/ECB/NoPadding"
"AES/ECB/PKCS5Padding"
"AES/ECB/ISO10126Padding"
Følgende kode anvender f.eks. tilstanden AES/ECB som standard, da "AES" er angivet:
// Console-underretningen henviser til denne metode
public byte[] encryptionUtil(String key, String iv, byte[] plainText) {// Anvender AES-/ECB-tilstand som standard
Cipher cipher = Cipher.getInstance(“AES”);
SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(), “AES”);
cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
cipher.init(Cipher.ENCRYPT_MODE, keySpec, paramSpec);
return cipher.doFinal(plainText);
}
Google anbefaler, at udviklere bruger "AES/GCM/NoPadding" i stedet for den usikre tilstand, der er nævnt ovenfor.
Sådan løser du problemer med SDK'er, der indeholder kode, som er sårbar over for stiforløbet for en ZIP-fil
Koden i din SDK indeholder usikre mønstre til udpakning af filer, som kan føre til en sikkerhedsbrist i forbindelse med stiforløbet for en ZIP-fil.
Hvis en app anvender din SDK, modtager den en underretning i Play Console. Du skal løse problemet med sikkerhedsbristen i din SDK for at forhindre, at apps, der anvender din SDK, modtager underretninger.
Følg den detaljerede vejledning nedenfor for at løse problemet i din SDK. Du kan se, hvor de usikre ZIP-mønstre er, i SDK Console-notifikationen til din SDK.
Yderligere oplysninger
ZIP-filer kan indeholde et element (en fil eller et indeks), som indeholder tegn til path traversal ("../") i navnet. Hvis udviklere pakker disse ZIP-filelementer ud uden at validere deres navn, kan det muligvis føre til et path traversal-angreb, hvilket kan resultere i skrivning i tilfældige indekser eller overskrivning af filerne i en apps private mapper.
Vi anbefaler, at du løser problemet i din SDK ved at tjekke, om kanoniske stier til udpakkede filer er under det forventede indeks. Hvis du bruger et File-objekt, som er oprettet ved hjælp af returværdien for getName()-metoden for ZipEntry, bør du altid tjekke, om returværdien af File.GetCanonicalPath() hører til den forventede indekssti. Eksempel:
InputStream is = new InputStream(untrustedFileName);// SecurityException
ZipInputStream zis = new ZipInputStream(new BufferedInputStream(is));
while((ZipEntry ze = zis.getNextEntry()) != null) {
File f = new File(DIR, ze.getName());
String canonicalPath = f.getCanonicalPath();
if (!canonicalPath.startsWith(DIR)) {
}// Finish unzipping...
}
Sådan løser du problemer med SDK'er, der indeholder sårbarheden Implicit PendingIntent
Din SDK indeholder en fejl med Implicit PendingIntent, hvilket kan gøre dine apps sårbare over for trusler såsom denial-of-service, tyveri af private data og eskalering af rettigheder.
Hvis en app anvender din SDK, modtager den en underretning i Play Console. Du skal løse problemet med sikkerhedsbristen i din SDK for at forhindre, at apps, der anvender din SDK, modtager underretninger.
Følg den detaljerede vejledning nedenfor for at løse problemet i din SDK. Du kan se, hvor i koden der anvendes Implicit PendingIntent, i SDK Console-notifikationen til din SDK.
Yderligere oplysninger
Android-apps sender meddelelser mellem komponenter ved hjælp af hensigter. Hensigter kan enten angive målkomponenten (eksplicit hensigt) eller angive en generel handling og lade operativsystemet levere hensigten til enhver komponent på enheden, der registrerer et hensigtsfilter, som stemmer overens med den pågældende handling (implicit hensigt).
Afventende formål er hensigter, der er delegeret til en anden app med henblik på senere levering. Oprettelse af en implicit hensigt, der er indkapslet af en PendingIntent, er en sikkerhedsbrist, som kan medføre denial-of-service, tyveri af private data og eskalering af rettigheder.
Tjek, hvor i din SDK der er oprettet en PendingIntent. Følgende kode opretter f.eks. en PendingIntent, der indkapsler en implicit hensigt:
// Opret en implicit basishensigt, og brug PendingIntent til at indkapsle den
Intent base = new Intent("ACTION_FOO");
base.setPackage("some_package");
PendingIntent pi = PendingIntent.getService(this, 0, base, 0);
Google anbefaler, at udviklerne løser problemet med sikkerhedsbristen ved at følge mindst én af disse anbefalinger:
- Sørg for, at felterne for handling, pakke og komponent for basishensigten er udfyldt.
- Sørg for, at PendingIntent kun leveres til komponenter, der er tillid til.
- Brug FLAG_IMMUTABLE (tilføjet i SDK 23) til at oprette PendingIntents. Dette forhindrer, at apps, der modtager PendingIntent, udfylder ikke-angivne egenskaber. Hvis appen også kører på enheder med SDK 22 eller ældre, anbefaler vi, at udviklerne anvender de tidligere valgmuligheder og styrker oprettelsen af PendingIntent med mønsteret:
if (android.os.Build.VERSION.SDK_INT >= 23) {
// Opret en PendingIntent ved hjælp af FLAG_IMMUTABLE
} else {
// Eksisterende kode, der opretter en PendingIntent
}
Sådan løser du problemer med SDK'er, der indeholder sårbarheden implicit intern hensigt
Din SDK indeholder et problem med implicit intern hensigt. Implicitte hensigter, der anvendes til at oprette forbindelse til en intern komponent, kan opfanges af hackere, som enten kan stoppe meddelelsen, læse indholdet eller endda erstatte indholdet.
Hvis en app anvender din sårbare SDK, modtager den en underretning i Play Console. Du skal løse problemet med sikkerhedsbristen i din SDK for at forhindre, at apps, der anvender din SDK, modtager underretninger.
Følg den detaljerede vejledning nedenfor for at løse problemet i din SDK. Du kan se, hvor i din SDK der anvendes implicitte hensigter, i SDK Console-notifikationen til din SDK.
Yderligere oplysninger
Gennemgå din SDK for at finde ud af, hvor der anvendes en implicit hensigt. Den følgende kode anvender f.eks. implicitte hensigter til at oprette forbindelse til en intern komponent:
//Appen har en komponent, der registrerer MY_CUSTOM_ACTION, som kun
//registreres af denne app, hvilket angiver, at udviklerens formål er, at denne hensigt
//leveres til den interne komponent på sikker vis.
Intent intent = new Intent("MY_CUSTOM_ACTION");
//Føj potentielt følsomt indhold til "intent"
intent.putExtra("message", sensitive_content);
startActivity(intent);
Google anbefaler, at udviklere bruger eksplicitte hensigter til at oprette forbindelse til deres interne komponenter på en af følgende måder:
- Brug Intent.setComponent til eksplicit at indstille komponenten til at behandle hensigten.
- Brug Intent.setClass eller Intent.setClassName til eksplicit at angive målkomponenten.
- Brug Intent.setPackage til at begrænse antallet af komponenter, som denne hensigt opretter forbindelse til.
Sådan løser du problemer med SDK'er, der indeholder sårbare JavaScript-biblioteker
Din SDK indeholder ét eller flere JavaScript-biblioteker med kendte sikkerhedsproblemer, f.eks. almindelige sårbarheder og eksponeringer (CVE'er, Common Vulnerabilities and Exposures). Hvis du medtager sådanne sårbare biblioteker i din SDK, kan det udgøre en risiko for appbrugere.
Hvis en app anvender din sårbare SDK, modtager den en underretning i Play Console. Du skal løse problemet i din SDK for at forhindre, at apps, der anvender din SDK, modtager underretninger.
Følg den detaljerede vejledning nedenfor for at løse problemet i din SDK. Du kan se en liste over registrerede usikre biblioteker og de af deres versioner, der anvendes i din SDK, i SDK Console-notifikationen til din SDK.
Yderligere oplysninger
For hvert bibliotek, der er registreret som usikkert, kan du rette problemet ved at foretage en af de tre handlinger nedenfor:
- Brug en opdateret version af biblioteket: Hvis din SDK er direkte afhængig af den version af et bibliotek, der er registreret som usikker, og sikkerhedsproblemet er blevet rettet i den nyeste version af biblioteket, løser det problemet at genopbygge SDK'en med den nyeste version.
- Kontakt biblioteksudvikleren: Det er muligt, at biblioteket stadig opdateres, men at sikkerhedsproblemet endnu ikke er løst. Det er også muligt, at din SDK har en forbundet afhængighed af det bibliotek, der er registreret som usikkert (dvs. SDK'en afhænger direkte af et bibliotek, som afhænger af det usikre bibliotek). Under disse omstændigheder skal du kontakte biblioteksudvikleren for at løse problemet.
- Find et alternativ: Hvis det usikre bibliotek med et eller flere sikkerhedsproblemer ikke længere opdateres, skal du finde og bruge et sikkert alternativt bibliotek.
Sådan løser du problemer med SDK'er, der anvender webvisninger til godkendelse
Din SDK anvender Webvisning til godkendelse, hvilket ikke anbefales. Brug af webvisninger til OAuth 2.0-anmodninger går både ud over sikkerheden og anvendeligheden af apps, der anvender din SDK. Følg nedenstående vejledning for at løse problemet i din SDK.
Hvis en app anvender din SDK, modtager den en underretning i Play Console. Du skal løse problemet med sikkerhedsbristen i din SDK for at forhindre, at apps, der anvender din SDK, modtager underretninger.
Du kan se, hvor i din SDK der er OAuth 2.0-anmodninger via webvisninger, i SDK Console-notifikationen til din SDK.
Yderligere oplysninger
Efter udgivelsen af tilpassede faner i Chrome har Google anbefalet, at udviklere ikke længere skal benytte webvisninger til godkendelse. Brug af OAuth til godkendelse i en webvisning kan gøre apps, der anvender din SDK, sårbare over for sikkerhedsproblemer og skade anvendeligheden ved at afbryde brugerens forbindelse til Single Sign-On-sessioner. Tilpassede faner i Chrome hjælper med at løse disse problemer.
- Tjek, hvor i din SDK der udføres en OAuth 2.0-anmodning via Webvisning.
- Google anbefaler, at udviklere erstatter Webvisning med en tilpasset fane i Chrome. Følg implementeringsvejledningen i tilpassede faner i Chrome for at føje en tilpasset fane i Chrome til din SDK.
- Brug nu den tilpassede fane i Chrome til at udføre OAuth 2.0-anmodningen.
Sådan løser du problemer med SDK'er, der offentliggør GCP API-nøgler
Din SDK indeholder ubeskyttede Google Cloud Platform (GCP) API-nøgler. Hvis du integrerer GCP API-nøgler i din SDK, bliver nøglerne offentligt tilgængelige. Ubeskyttede API-nøgler kan medføre uventede debiteringer og kvoteændringer på din SDK's GCP-konto.
Hvis en app anvender din sårbare SDK, modtager den en underretning i Play Console. Du skal løse problemet med sikkerhedsbristen i din SDK for at forhindre, at apps, der anvender din SDK, modtager underretninger.
Følg den detaljerede vejledning nedenfor for at løse problemet i din SDK. Du kan se, hvor i din SDK der er ubeskyttede GCP API-nøgler, i SDK Console-notifikationen til din SDK.
Yderligere oplysninger
Vi anbefaler, at du løser problemet med din SDK ved hjælp af en af følgende måder:
- Hvis det er muligt, bør du bruge GCP-tjenestekonti i stedet for GCP API-nøgler til at godkende din app med. En GCP-tjenestekonto er en Google-konto, der er tilknyttet dit GCP-projekt. Du kan få flere oplysninger om, hvordan du opretter og bruger tjenestekonti, her.
- Angiv begrænsninger for din API-nøgle, så det kun er dine SDK'er/apps, der kan bruge API-nøglen. Du kan få flere oplysninger om, hvordan du føjer begrænsninger til API-nøgler, her. Bemærk! Hvis du allerede har tilføjet begrænsninger for at beskytte din API-nøgle, kan du set bort fra denne advarsel.