Quali misure di protezione sono necessarie nella fatturazione in-app Android per prodotti non consumabili?

2

L'applicazione è un client Android per un servizio remoto sul quale tutti gli utenti dispongono di account e possono effettuare acquisti di articoli non di consumo. Ogni acquisto è legato all'account su cui sono stati acquistati. Lo schema di acquisto corrente è il seguente:

  1. Il cliente avvia l'acquisto con il servizio di fatturazione in-app di Google Play. La richiesta di acquisto contiene il payload che identifica in modo univoco l'account.
  2. Una volta completato l'acquisto, il cliente recupera i dati di acquisto che contengono il carico utile e il token di acquisto. Inoltre ha una firma per i dati ricevuti che al momento non è stato controllato.
  3. Il client invia il token di acquisto al server. A questo punto deve essere autenticato.
  4. Il server riceve il token di acquisto. Il server esegue l'autenticazione con il servizio Google Play utilizzando la sua chiave dell'account di servizio e riceve i dati di acquisto per il token indicato. I dati contengono il carico utile originale e le informazioni riguardanti l'acquisto.
  5. Il server convalida i dati di acquisto: si verifica che il payload corrisponda all'id utente attualmente connesso, che l'acquisto non sia ancora stato consumato e che sia stato pagato con successo.
  6. Se la verifica ha esito positivo, viene contrassegnato che il cliente ha acquistato il prodotto sul server e il client riceve una conferma, altrimenti il client riceve un rifiuto.

Cosa potrebbe andare storto con questo schema? Ad esempio, mi preoccupa che la firma non venga utilizzata da nessuna parte. Tuttavia, non vedo quale uso ci sia se il server riceve i dati direttamente da Google Play. Nel peggiore dei casi, può ricevere un token errato, ma il payload contiene l'id utente, quindi l'acquisto verrà rifiutato se è stato creato per un altro account. Anche l'invio dello stesso token due volte è inutile poiché il prodotto non è consumabile: è stato acquistato o meno. Ma forse mi manca qualcosa qui o c'è qualche altro difetto che non vedo?

    
posta Malcolm 02.08.2016 - 16:16
fonte

2 risposte

1

Non capisco quale sia davvero la domanda?

Sospetto che la tua domanda sia di più, a cosa serve la firma, se non è mai verificata. E posso dire qui a cosa serve la firma: La firma viene utilizzata quando non hai un sistema di account sottostante e non stai utilizzando il sistema di account Google.

In tal caso, riceverai i dati di acquisto firmati dal server di Google nell'app. Ora arriva il problema che l'utente potrebbe manometterlo, dicendo che potrebbe manomettere per dire che hanno acquistato qualcosa che non hanno acquistato.

Inoltre non hai ID utente da convalidare, quindi se hai usato solo token di acquisto, l'utente potrebbe condividere i token l'uno con l'altro.

Ecco cosa sta entrando in gioco la firma. Quando si ricevono i dati dall'app / client / utente, è possibile verificare che non siano controllati prima di rendere l'accesso ai servizi a pagamento. Inoltre, qui puoi fornire un nonce casuale con la tua richiesta, che viene fornita nella risposta. Poiché l'utente non può ottenere dati di acquisto per qualsiasi altro acquisto rispetto ai propri acquisti, ciò impedisce efficacemente la condivisione del contenuto premium.

L'aggiunta della convalida dei dati di acquisto al di sopra del tuo schema lo renderebbe ancora più sicuro, ma in questo caso non è necessario poiché stai convalidando il token contro UserID.

    
risposta data 07.08.2016 - 03:33
fonte
1

Hai ragione, non vedo alcun problema in questo schema. Se Google inizia a mentire al tuo server in merito a acquisti fittizi, dubito che una firma potrebbe aiutarti, poiché a quel punto avresti bisogno di cambiare completamente i fornitori di pagamento.

    
risposta data 06.08.2016 - 04:07
fonte

Leggi altre domande sui tag