Recentemente ho scoperto che con la semplice visualizzazione rapida del codice compilato di una delle nostre applicazioni, puoi ottenere sia ID app (chiave API) che Segreto app per l'API di Facebook
Suppongo che dovremmo davvero mantenere App Secret (ovviamente dalla parola secret ), in modo che nessuno possa accedervi, ma qual è la minaccia principale correlata alla perdita di questi articoli?
Se il malvagio ottiene queste voci, qual è il peggior abuso possibile che potrebbe eseguire ?
Hai ragione. Il segreto dell'app deve essere segreto e non dovrebbe essere ottenuto facilmente mediante il reverse engineering del codice client.
Facebook utilizza OAuth quindi tutto ciò che dico qui si applica anche a tutte le applicazioni che utilizzano OAuth per autorizzare e autenticare. Il segreto dell'app autentica il tuo cliente su Facebook. Proprio come un nome utente / password autentica un utente in un servizio web, i client mobili / desktop utilizzano la chiave segreta dell'app come credenziale per il server per convalidare che è l'app client "reale" legittima.
If the evil guy obtains these entries, what is the worst possible misuse he could perform?
Potrebbe creare un client spoofed simile al tuo client / applicazione e rilasciarlo. Gli utenti ignari lo scaricheranno e lo useranno per connettersi a Facebook. L'app falsa non ottiene ancora le credenziali degli utenti (il che è buono) perché l'autenticazione delle credenziali dell'utente avviene su una pagina di Facebook. Tuttavia, l'utente finisce per autorizzare questa app falsa su Facebook. Facebook lo fa felicemente perché crede che chiunque ti presenti quel segreto sei tu. Di conseguenza, l'app falsa ottiene il "token di accesso" per l'utente e può iniziare a postare commenti e fare altre cose che la tua vera app non intende fare.
Quindi, in poche parole, è il tuo valore di reputazione che è in gioco qui. Altri clienti possono impersonare come tuo cliente su Facebook.
Questo è un approfondito case study di un tale client Twitter che memorizza la chiave del consumatore (il suo equivalente del segreto dell'app) in testo semplice.
Sto citando una riga di quel blog:
It’s very important to understand that a compromised consumer secret key doesn’t jeopardize the security of the users of the application. The key can’t be used to gain access to the accounts of other users, because accessing an individual account requires an access token that individual instances of the client application obtain automatically on behalf of the user during the authorization process.
Ora, come proteggi il cliente segreto?
Se si tratta di un client standalone (come un'app mobile), non hai altra scelta che incorporarlo in qualche modo. Sfortunatamente per un reverse engineer esperto, è solo una questione di tempo prima che possa essere decodificato. Dopo tutto il suo da qualche parte lì (in qualche modo) nel client . Se il cliente può ricalcolare / riassemblare, così può fare un ribaltamento.
Modifica: se l'architettura dell'applicazione lo consente, il server può eseguire i passaggi OAuth per conto dell'app client / mobile. In questo modo la chiave risiede nel server, fa tutti i passaggi di OAuth e passa il token di accesso al client per utilizzarlo per accedere ai dati di Facebook dell'utente. A questo punto stai facendo qualcosa di molto simile al browser - server web - interazione facebook descritto qui . Sostituisci "Browser utente" con la tua "Applicazione client / mobile" e "La tua app" con "Il tuo server" in quella foto.
Se si tratta di una sorta di applicazione Web, è possibile ottenerla facilmente mantenendo la chiave solo sul lato server e utilizzando flusso lato server per impedire che il segreto dell'app si diffonda.
Nel caso di Facebook - non conosco altri siti abilitati per OAuth - esiste la possibilità di utilizzare il token di accesso all'applicazione anonima aka. È un token creato concatenando appId con appSecret , ad esempio 504216299598238|59d273f6dddb0a2f72e727132f4a74a4 .
Si potrebbe ottenere questo token di accesso dalla sorgente dell'app mobile e fare richieste autenticate all'API Graph. Quindi, Facebook fornisce alcune informazioni sugli utenti che hanno autorizzato questa app in precedenza anche senza il token di accesso utente .
L'utente malintenzionato può ottenere in questo modo l'accesso a dati utente riservati (ad esempio e-mail). Ecco una dimostrazione del concetto:
Questo utente non ha autorizzato l'applicazione:
https://graph.facebook.com/100004668630549?fields=email&access_token=504216299598238|59d273f6dddb0a2f72e727132f4a74a4
E questo ha fatto:
https://graph.facebook.com/100004619894646?fields=email&access_token=504216299598238|59d273f6dddb0a2f72e727132f4a74a4
Il campo email non è altrimenti visibile. Risultato: un utente malintenzionato può ottenere informazioni sensibili sull'utente attaccato senza alcuna interazione da parte dell'utente .
Leggi altre domande sui tag oauth reverse-engineering passwords facebook