L'API Play Integrity ti aiuta a controllare che le interazioni e le richieste del server provengano dal programma binario dell'app originale in esecuzione su un dispositivo Android originale. Se rilevi interazioni potenzialmente rischiose e fraudolente, ad esempio da versioni di app manomesse e ambienti non attendibili, il server di backend della tua app può rispondere con azioni appropriate per prevenire gli attacchi e ridurre gli abusi.
Quando la tua app o il tuo gioco viene utilizzato su un dispositivo Android con il Google Play Store e Google Play Services, l'API Play Integrity fornisce una risposta che ti aiuta a determinare se stai interagendo con quanto segue:
- File binario dell'app originale:consente di stabilire se stai interagendo o meno con il tuo file binario non modificato riconosciuto da Google Play.
- Installazione Play originale:consente di stabilire se l'account utente corrente è autorizzato o meno, ossia se l'utente ha installato o acquistato l'app o il gioco su Google Play.
- Dispositivo Android originale:consente di stabilire se la tua app è installata o meno su un dispositivo Android originale con Google Play Services (o un'istanza genuina di Google Play Giochi per PC).
Puoi anche scegliere di ricevere informazioni sull'ambiente nella risposta dell'API Play Integrity, tra cui:
- Rischio di accesso all'app:determina se sono in esecuzione app che potrebbero essere utilizzate per acquisire la schermata, visualizzare overlay o controllare il dispositivo.
- Rischio derivante da malware noti: consente di stabilire se la funzionalità Google Play Protect è attiva e se ha rilevato app rischiose o pericolose installate sul dispositivo.
Panoramica
Quando un utente esegue un'azione nella tua app, puoi chiamare l'API Play Integrity per verificare che sia avvenuta nel file binario dell'app originale, installato da Google Play ed eseguito su un dispositivo Android originale. Puoi anche attivare la ricezione di altre informazioni nella risposta, tra cui il volume di richieste effettuate di recente da un dispositivo e indicatori sull'ambiente, tra cui l'esito relativo al rischio di accesso alle app e l'esito di Play Protect. Se i verdetti non sono corretti, il server di backend dell'app può decidere cosa fare per difendersi da problemi come attività illecite, uso improprio, imbrogli, accesso non autorizzato e attacchi.
Considerazioni sulla sicurezza
L'API Play Integrity fornisce il massimo valore per la tua app se segui queste pratiche consigliate:
Avere una strategia anti-abuso
L'API Play Integrity funziona in modo ottimale quando usata insieme ad altri indicatori in quanto parte della tua strategia generale contro i comportamenti illeciti e non come unico meccanismo anti-abuso. Utilizza questa API in combinazione con altre best practice di sicurezza appropriate per la tua app. Per impostazione predefinita, la tua app può effettuare fino a 10.000 richieste totali al giorno in tutte le installazioni. Puoi richiedere di aumentare il valore massimo giornaliero.
Raccogliere dati telemetrici e comprendere il pubblico prima di intervenire
Prima di modificare il comportamento della tua app in base ai verdetti dell'API Play Integrity, puoi comprendere la situazione attuale del tuo pubblico esistente implementando l'API senza applicazione. Una volta che sai quali sono i verdetti della tua base di installazioni attuale, puoi stimare l'impatto di qualsiasi applicazione delle norme che stai pianificando e modificare di conseguenza la tua strategia anti-abuso.
Decidi come richiedere gli esiti di integrità
L'API Play Integrity offre due opzioni per richiedere e ricevere esiti relativi all'integrità. Indipendentemente dal fatto che tu effettui richieste standard, richieste classiche o una combinazione di entrambi i tipi di richiesta, la risposta del verdetto sull'integrità verrà restituita nello stesso formato.
Le richieste API standard sono adatte a qualsiasi app o gioco e possono essere effettuate su richiesta per verificare che qualsiasi azione dell'utente o richiesta del server sia autentica. Le richieste standard hanno la latenza più bassa (in media alcune centinaia di millisecondi) e un elevato grado di affidabilità per ottenere un verdetto utilizzabile. Le richieste standard utilizzano la memorizzazione nella cache on-device intelligente, delegando al contempo la protezione da determinati tipi di attacchi a Google Play.
Anche le richieste API classiche, il metodo originale per richiedere esiti relativi all'integrità, continueranno a essere disponibili. Le richieste classiche hanno una latenza più elevata (in media alcuni secondi) ed è tua responsabilità ridurre il rischio di determinati tipi di attacchi. Le richieste classiche utilizzano più dati e batteria dell'utente rispetto alle richieste standard perché avviano una nuova valutazione e pertanto devono essere effettuate raramente come una tantum per verificare se un'azione altamente sensibile o di valore è autentica. Se stai pensando di effettuare una richiesta classica e memorizzarla nella cache per usarla in un secondo momento, ti consigliamo di effettuare una richiesta standard per ridurre il rischio di attacchi.
La seguente tabella evidenzia alcune differenze chiave tra i due tipi di richieste:
| Richiesta API standard | Richiesta API classica | |
|---|---|---|
| Versione minima dell'SDK Android richiesta | Android 5.0 (livello API 21) o versioni successive | Android 4.4 (livello API 19) o versioni successive |
| È necessario il riscaldamento dell'API | ✔️ (pochi secondi) | ❌ |
| Latenza di richiesta tipica | Poche centinaia di millisecondi | Pochi secondi |
| Frequenza potenziale delle richieste | Frequente (controllo su richiesta per qualsiasi azione o richiesta) | Sporadiche (controllo una tantum per le azioni di valore più elevato o le richieste più sensibili) |
| Mitigare gli attacchi di replay e simili | Mitigazione automatica da parte di Google Play | Utilizzare il campo nonce con la logica lato server |
Puoi vedere una tabella con altre differenze nelle considerazioni sulle richieste classiche.
Richiedi un verdetto sull'integrità al momento opportuno
Ti consigliamo di richiedere un verdetto sul rischio di accesso all'app il più vicino possibile al momento dell'azione o della richiesta al server per cui vuoi difenderti dall'accesso, per impedire ai truffatori di aggirare il controllo dell'integrità eseguito dalla tua app.
Rendi difficili da replicare le richieste API
Le richieste API standard hanno un campo denominato requestHash che viene utilizzato per proteggersi da manomissioni e attacchi simili. In questo campo, devi includere un digest di tutti i valori pertinenti della richiesta della tua app. Segui le indicazioni su come utilizzare il binding dei contenuti per proteggere le richieste standard della tua app.
Le richieste API classiche hanno un campo denominato nonce (abbreviazione di numero una volta), che viene utilizzato per proteggersi da determinati tipi di attacchi, come gli attacchi di replay e di manomissione. Segui le indicazioni su come generare valori nonce per proteggere le richieste classiche della tua app.
Evita di memorizzare nella cache i giudizi di integrità
La memorizzazione nella cache degli esiti di integrità aumenta il rischio di proxying, ovvero un attacco in cui un malintenzionato riutilizza un esito di un dispositivo valido per scopi illeciti in un altro ambiente. Anziché memorizzare nella cache le risposte, puoi effettuare una richiesta API standard per ottenere un verdetto su richiesta.
Avere una strategia di applicazione a più livelli
L'esito relativo all'integrità dell'API Play Integrity ha una gamma di possibili risposte che consentono di creare una strategia anti-abuso con più livelli di applicazione forzata. Per farlo, configura il server di backend della tua app in modo che si comporti diversamente a seconda di ogni possibile risposta o gruppo di risposte.
È anche possibile suddividere la strategia di applicazione in base all'affidabilità del dispositivo attivando la ricezione di etichette aggiuntive dei dispositivi nella risposta dell'API da Play Console. Ogni dispositivo restituirà tutte le etichette di cui soddisfa i criteri. Ad esempio, dopo aver attivato la ricezione di tutti gli etichetti del dispositivo, puoi scegliere di considerare attendibile un dispositivo che restituisce MEETS_STRONG_INTEGRITY, MEETS_DEVICE_INTEGRITY e MEETS_BASIC_INTEGRITY più di un dispositivo che restituisce solo MEETS_BASIC_INTEGRITY. Puoi rispondere diversamente dal server in ogni scenario.
Invia una serie di risposte dal server all'app
Avere una serie di risultati di decisione è più difficile da replicare rispetto all'invio di una risposta di tipo Allow/Deny dal server all'app per ogni risposta. Ad esempio, puoi utilizzare una serie di risposte correlate, come Consenti, Consenti con limiti, Consenti con limiti dopo il completamento del CAPTCHA e Nega.
Rilevare abusi su larga scala utilizzando l'attività del dispositivo recente
Utilizza la funzionalità di attività del dispositivo recente nell'API Play Integrity per trovare i dispositivi che richiedono un numero elevato di token di integrità. Gli autori di attività con volume elevato solitamente generano risultati di attestazione validi da dispositivi reali e li forniscono ai bot per automatizzare gli attacchi su dispositivi e emulatori con root. Puoi utilizzare il livello di attività del dispositivo recente per controllare quante attestazioni sono state generate dalla tua app sul dispositivo nell'ultima ora.
Mostrare messaggi di errore utili
Se possibile, fornisci all'utente utili messaggi di errore e spiegagli cosa può fare per risolvere il problema, ad esempio riprovare, attivare la connessione a internet o verificare che l'app Play Store sia aggiornata.
Avere un piano per problemi o interruzioni imprevisti
La dashboard dello stato di Google Play mostra informazioni sullo stato del servizio dell'API Play Integrity, nonché su eventuali interruzioni e interruzioni del servizio. Ti consigliamo di pianificare in anticipo il funzionamento del server di backend nell'improbabile eventualità di un'interruzione del servizio dell'API Play Integrity su larga scala. Tieni presente che il server di backend deve essere pronto anche per funzionare nel caso in cui le chiavi di attestazione della piattaforma Android specifiche per i dispositivi vengano revocate.
Valutare la possibilità di utilizzare soluzioni antifrode aziendali end-to-end
I clienti aziendali alla ricerca di una soluzione completa per la gestione di attività fraudolente e bot possono acquistare reCAPTCHA Enterprise per il mobile, che include SDK per Android che forniscono agli sviluppatori punteggi di rischio di attività fraudolenta. reCAPTCHA Enterprise include automaticamente gli indicatori dell'API Play Integrity e li combina con gli indicatori della rete e delle applicazioni reCAPTCHA per i clienti, fornendo una soluzione di gestione delle attività fraudolente invisibile e senza problemi. Può anche fornire protezione per le app Android in cui l'API Play Integrity non è disponibile.
Sfidare il traffico rischioso quando si accede a funzionalità sensibili o di alto valore
Identifica le azioni sensibili o di alto valore nella tua app o nel tuo gioco da proteggere con l'API Play Integrity anziché negare del tutto l'accesso. Se possibile, mettiti in discussione prima di consentire azioni di alto valore. Ad esempio, quando il rischio di accesso all'app indica che è in esecuzione un'app che potrebbe acquisire lo schermo, chiedi all'utente di disattivare o disinstallare le app che possono acquisire lo schermo prima di consentirgli di procedere alla funzionalità che vuoi proteggere.
Termini di servizio e sicurezza dei dati
Se accedi all'API Play Integrity o la utilizzi, accetti i Termini di servizio dell'API Play Integrity. Prima di accedere all'API, leggi e comprendi tutti i termini e le norme vigenti.
Google Play ha una sezione Sicurezza dei dati in cui gli sviluppatori possono comunicare le prassi di raccolta, condivisione e sicurezza dei dati delle loro app per informare gli utenti. Per aiutarti a compilare il modulo relativo ai dati, consulta queste informazioni su come l'API Play Integrity gestisce i dati.