Perché dovremmo usare checkCallingPermission invece di checkCallingOrSelfPermission in Android?

1

Ho scansionato un progetto usando Fortify e dice che dovrei sostituire checkCallingOrSelfPermission metodo con checkCallingPermission .

Non sono riuscito a capire il rischio per la sicurezza che presenta il metodo checkCallingOrSelfPermission.

Questa è la spiegazione Fortifica:

The function checkCallingOrSelfPermission() or checkCallingOrSelfUriPermission() determine whether the calling program has the required permission to access a certain service or a given URI. However, these functions should be used with care as they can grant access to malicious applications, lacking the appropriate permissions, by assuming your applications permissions.

This means a malicious application, without appropriate permissions, can bypass its permission check by using your application's permission to get access to otherwise denied resources. This can result in what is known as the confused deputy attack.

    
posta mk_ 06.12.2016 - 14:45
fonte

2 risposte

4

Il delegato confuso è quando si sta operando per conto di un altro programma, ma non si controllano appropriatamente le autorizzazioni. Il normale esempio di questo è un cassiere di un negozio di generi alimentari, che scansiona gli oggetti usando un codice a barre. Se un cliente malintenzionato cambia il codice a barre, ad esempio mettendo un codice a barre di carota su filet mignon, e la cassiera semplicemente scansiona e carica i prezzi delle carote, lui / lei è un vice confuso. (D'altra parte, se lui / lei nota, sta applicando un controllo appropriato e non è un deputato confuso, ma uno competente)

In questo caso, ciò che Fortify sta dicendo è che sei disposto a sostituire le tue autorizzazioni per le autorizzazioni del chiamante (questo è ciò che fa checkCallingOrSelfPermissions) - stai dicendo che non importa ciò che il chiamante può fare, andare con cosa puoi farlo.

È possibile che questo sia ciò che desideri - se il tuo programma è destinato a eseguire comandi privilegiati per conto di programmi non privilegiati, questo potrebbe essere ciò che desideri. In tal caso, tuttavia, sei responsabile di garantire che il chiamante sia il vero chiamante e che non stia facendo nulla di malvagio. Fortify non può aiutarti - è lì che eseguirai una vera e intensa ispezione del codice e alcuni seri test per assicurarti che quel limite del trust non possa essere sfruttato da qualcosa di malevolo. Se il tuo codice passa, normalmente annoteresti in modo che Fortify lo ignori. Questi sono definiti trust-boundaries e sono dove vuoi dedicare molto tempo all'analisi per assicurarti di eseguire controlli appropriati.

Probabilmente vuoi semplicemente ascoltare Fortify qui e apportare la modifica, a meno che tu non abbia fatto il lavoro per verificare i tuoi input e sia positivo che questa chiamata non possa essere usata per fare qualcosa di malevolo E è l'unico modo per fare qualcosa utile.

    
risposta data 06.12.2016 - 15:24
fonte
3

Immagina due app: Alice e Bob. E, per ragioni, fai finta che sul dispositivo ci siano solo due app.

Se Bob chiama checkCallingPermission() , Bob sta chiedendo "può Alice farlo?"

Se Bob chiama checkCallingOrSelfPermission() , Bob sta chiedendo "può Alice o io fare questo?", che è una domanda insolita. Normalmente utilizziamo questi metodi per proteggere le app da richieste indesiderate di terze parti e quali permessi le nostre app tenere non hanno importanza per quella particolare situazione.

È possibile che checkCallingOrSelfPermission() sia davvero ciò che desideri. IMHO, ci sono meno casi d'uso per questo, e quindi vale la pena di avvertire uno scanner per suggerire che forse hai usato il metodo sbagliato. Oppure, meglio ancora, sbarazzarsi di entrambi i metodi e utilizzare gli attributi di android:permission nel manifest, se il caso d'uso è abbastanza semplice, in quanto difende automaticamente i componenti in base all'autorizzazione denominata.

    
risposta data 06.12.2016 - 15:28
fonte

Leggi altre domande sui tag