ordinatore REST Richieste

Sto lavorando su un servizio REST che ha alcuni requisiti:ordinatore REST Richieste

Deve essere sicuro.
Gli utenti non dovrebbero essere in grado di falsificare richieste.

Il mio attuale soluzione proposta è quella di avere un colpo di testa di autorizzazione personalizzato che simile a questa (questo è lo stesso modo in cui l'Amazzonia lavoro servizi web):

Authorization: MYAPI username:signature

La mia domanda è come formare la firma . Quando l'utente accede al servizio, riceve una chiave segreta che dovrebbe essere in grado di utilizzare per firmare le richieste. Questo fermerà gli altri utenti che invieranno richieste per loro conto, ma non li interromperà.

L'applicazione che utilizzerà questo servizio è un'applicazione per iPhone, quindi stavo pensando che avremmo potuto inserire una chiave pubblica nell'applicazione con cui possiamo fare una firma aggiuntiva, ma questo significa che dovremo avere due firme, una per la chiave utente e una per la chiave app?

Qualsiasi consiglio sarebbe molto apprezzato, mi piacerebbe molto farlo bene la prima volta.

fonte

2008-10-27 jonnii

Definire "richieste di forgiatura". Quale entità crea richieste non forgiate? È il software lato client? – Alexander

Penso che il modo più semplice per farlo sarebbe utilizzare l'autenticazione client HTTPS. Il sito di Apple ha uno thread proprio su questo argomento.

Modifica: per gestire l'autorizzazione, vorrei creare una risorsa separata (URI) sul server per ciascun utente e consentire solo all'utente (autenticato) di manipolare questa risorsa.

Modifica (2014): Apple ha cambiato il software del forum negli ultimi sei anni; il thread è ora a https://discussions.apple.com/thread/1643618

fonte

2008-10-27 15:27:34

In che modo questo impedisce agli utenti di falsificare le richieste? – jonnii

L'autenticazione del client HTTPS richiede che il client abbia un certificato di chiave pubblica valido. A meno che non intenda per "falsificare richieste" che un utente autenticato sta in qualche modo facendo richieste non autorizzate, che è un problema di autorizzazione e non un problema di autenticazione. –

Questo è il problema che sto cercando di risolvere, ho aggiornato l'argomento per riflettere questo. Come suggeriresti di autorizzare richieste valide? – jonnii

Cosa c'è che non va con HTTP Digest Authentication?

fonte

2008-10-27 15:29:21

In primo luogo dovrò utilizzare SSL per le richieste (che va bene), ma non impedisce a un utente di accedere all'API da un dispositivo non iPhone e inviare richieste forgiate. – jonnii

Come possono falsificare una richiesta tramite l'autenticazione digest? Come hanno ottenuto l'attuale valore di nonce e creato una risposta digest accettabile? –

Possono creare una richiesta perché possono creare un'applicazione client di terze parti che accede all'api, a quel punto possono inviare le proprie richieste. Devo verificare l'origine della richiesta API. – jonnii

v'è una migliore discussione di questo qui:

Best Practices for securing a REST API/web service

fonte

2008-10-31 20:24:42 jonnii

La risposta è semplice: non si può fare. Non appena spedisci una soluzione all'utente finale, lui o lei può sempre attaccare il server con cui sta comunicando. La versione più comune di questo problema è l'imbroglio con elenchi di hi-score nei giochi Flash. È possibile renderlo più difficile incorporando una sorta di crittografia nel client e offuscando il codice ... Ma tutto il codice compilato e offuscato può sempre essere decompilato e non offuscato. È solo una questione di quanto tempo e denaro sei disposto a spendere e allo stesso modo del potenziale aggressore.

Quindi la vostra preoccupazione è non come cercare di impedire all'utente di inviare dati difettosi al vostro sistema. È come impedire all'utente di danneggiare il sistema. Devi progettare le tue interfacce in modo che tutto il danno causato da dati difettosi riguardi solo l'utente che lo invia.

fonte

2009-05-01 09:04:32

In questo caso stiamo per essere distribuiti sull'iPhone, quindi c'è il rischio che qualcuno decompilando il codice. Nel tuo post sollevi punti molto validi sulla limitazione della possibilità di danneggiare solo i dati degli utenti, in questo caso sarebbero in grado di imbrogliare in un gioco, quindi dobbiamo essere in grado di identificare gli imbroglioni e affrontarli in modo efficace. Nessun compito facile. – jonnii

L'unico modo per proteggere il gioco AV è eseguirlo interamente sul server e inviare solo le azioni degli utenti sul filo. Quello che faccio di solito è: 1. Rendere difficile barare 2. Salvare quante più informazioni possibile. In genere, il cheating è ragionevolmente facile da individuare, quindi è possibile eliminare tutte le voci per quell'utente in seguito. –

Se stai sviluppando un GAME, e questo è un problema CHEATING, allora hai a disposizione tutta un'altra serie di strumenti, a seconda che si tratti di un gioco di abilità o di un gioco d'azzardo. In generale, le prestazioni dei giocatori possono essere misurate statisticamente e possono essere individuati strani pattern - questo è il numero di sistemi di rilevamento delle frodi che operano nel settore dell'intrattenimento. Un'altra cosa che viene subito in mente è la progettazione algoritmica che introduce alcune proprietà misurabili nel gioco, ad esempio l'accumulo di errori nei numeri in virgola mobile. – mst

risposta

Problemi correlati