Un utente malintenzionato può effettuare acquisti in-app dei miei prodotti nella sua app?

4

La mia app iOS deve memorizzare un segreto precondiviso. Non può essere incorporato all'interno del pacchetto di app stesso perché potrebbe essere estratto analizzando staticamente il pacchetto.

Il sistema di acquisto in-app di Apple consente a un'app di fare una richiesta ad Apple. iOS dovrebbe verificare l'autenticità dell'app (dato che tutte le app sono firmate) - Mi rendo conto che potrei usare questo sistema per verificare che l'app sia mia (e non un impostore che cerca di ottenere il segreto).

La mia app farebbe una richiesta IAP ad Apple, Apple quindi genera una ricevuta firmata crittograficamente e la restituisce alla mia app, che poi passa la ricevuta al mio server che verifica la firma di Apple ed emette un nuovo segreto di istanza per-app e lo restituisce al client (per la memorizzazione nell'iPhone Secure Enclave) dove nessun'altra app può leggerlo.

Questo sistema si romperebbe se un utente malintenzionato potesse inviare le proprie ricevute al mio servizio. Capisco che la ricevuta contenga il nome del pacchetto di app / pacchetto che Apple afferma sia corretto, ma non so come proteggerei da un utente malintenzionato che esegue un tipo di attacco di replay in cui farebbero sì che la mia app effettui lo IAP in modo tale da ricevere la ricevuta è valido, ma acquisisci la ricevuta, interrompi il processo della mia app, quindi invia la ricetta dalla loro app al mio servizio (ottenendo così il segreto).

Qual è una buona soluzione a questo problema e un telefono jailbroken potrebbe consentire a un'altra app di mascherarsi come app per Apple per IAP?

    
posta The D 07.04.2016 - 10:31
fonte

2 risposte

2

Il tuo scenario in cui un utente malintenzionato scambia una ricevuta valida per i dati segreti può essere mitigato se invece il server invia il segreto in risposta a una ricevuta, fornisce il segreto alla tua app con altri mezzi. I servizi di notifica push di Apple sono una buona soluzione, poiché collegano il tuo server alle tue app (nessun'altra app può ricevere le tue notifiche e il tuo server non può inviare notifiche ad altre app dello sviluppatore anche se lo desidera, perché il client lo ha certificato usa per parlare con Apple consente solo di inviare messaggi indirizzati alle tue app).

Quando richiedi i dati segreti dal server, invia la ricevuta e il suo token dispositivo univoco che ti consente di inviare notifiche push ad esso. Il server invia quindi i dati segreti come notifica push. Se la dimensione è un problema, può inviare una chiave segreta che si adatta al carico utile della notifica e l'app scarica quindi i dati segreti effettivi presentando quella chiave in una richiesta successiva. Un'app di imposter non sarebbe in grado di ricevere la notifica push perché, anche se invia un proprio token, Apple non consentirà al server di inviare una notifica a tale app poiché proviene da uno sviluppatore diverso.

Infine, una domanda mi viene in mente, perché stai facendo questo? Se i dati segreti contengono informazioni su altri utenti, questo è il tuo problema principale. Invece di cercare di proteggere i dati segreti (che non puoi ricevere da qualcuno che ha accesso fisico al dispositivo), assicurati che i dati non contengano nulla di sensibile su altre persone e che l'utente faccia ciò che vuole con < em> i loro dati. Se è per DRM, tieni presente che molte persone hanno provato e fallito , e non importa quanto sei intelligente, non puoi fare l'impossibile. Perché non concentrare i tuoi sforzi sulla realizzazione di un'esperienza straordinaria per incoraggiare le persone a pagare invece di copiare i tuoi contenuti?

    
risposta data 06.08.2016 - 04:00
fonte
0

Qualsiasi sistema di questo tipo vale la pena (sic) avrà un MAC basato sul tempo (o almeno un'opzione per aggiungerne uno) esattamente per questo motivo.

Non posso commentare specificamente il servizio di Apple, ma so che è qualcosa che, ad esempio, offre Azure per l'accesso basato su token al suo sistema di cloud storage ... Ho persino scritto un meccanismo simile per proteggere i comandi di streaming RTSP per pre -release audio circa quindici anni fa :)

    
risposta data 07.04.2016 - 23:35
fonte

Leggi altre domande sui tag