Senza usare SSL, qual è il modo più sicuro per fare una richiesta AJAX a una pagina PHP?

3

È stato suggerito su StackOverflow di provare la mia domanda qui. Questo è letterale:

Quindi, è impossibile fare richieste AJAX in modo sicuro senza usare SSL. Capisco. Puoi visualizzare i dati che vengono inviati tramite Javascript, oppure puoi accedere direttamente alla pagina PHP spoofando le intestazioni, yada yada.

Ma diciamo che questa web app non richiede in particolare la sicurezza true , e invece è solo una sorta di gioco per tenere a bada la maggior parte dei reverse-engineer. Che tipo di ostacoli dovrei assumere?

Non sto cercando un'implementazione ridicolmente esagerata di Javascript di un algoritmo di crittografia. Voglio la semplicità e la sicurezza lieve ... se ciò non è contraddittorio per natura. Quindi, cosa consiglieresti ragazzi?

Ad esempio, sto organizzando un contest in cui se un utente fa clic su un'immagine con successo (jQuery), passa il suo userid e un timestamp a una pagina PHP, sia MD5 salato da dati casuali e quindi codificato con MIME. La pagina PHP quindi convalida questo userid e timestamp, quindi restituisce un "codice" vincente sotto forma di un altro hash MD5 salato. Sto anche impiegando più controlli di intestazione per garantire che la richiesta provenga da una posizione valida. Mi sto perdendo qualcosa, o è tutto quello che posso fare? Sembra che qualcuno potrebbe semplicemente attivare l'evento click di jQuery e rovinare tutto, ma non vedo come posso impedirlo.

Assegnerò la risposta a tutti coloro che inventano un ingegnoso meccanismo di sicurezza del falso! O ... solo chi mi dice perché sono stupido questa volta.

    
posta daveycroqet 15.03.2012 - 14:22
fonte

4 risposte

4

In particolare, a cosa stai cercando di essere sicuro?

Eavesdroppers che registra o intercetta messaggi tra il client e l'host? Fondamentalmente hai bisogno di SSL per assicurarti che nessuno possa intercettare o creare il tuo protocollo di crittografia (ad esempio come estensione del browser o javascript sulla pagina), sebbene raccomando strongmente contro il metodo di crittografia create-your-own (sarà più lento / più debole e quasi senza dubbio hanno grossi difetti se non lo si fa esaminare da diversi esperti di crittografia). Se i tuoi utenti hanno solo computer su reti separate l'uno dall'altro (e il computer host) e non controllano le reti intermedie (ad esempio, lavorano presso uno dei tuoi ISP), non potranno origliare.

Non sono sicuro di quale sia il punto del tuo gioco:

For example, I'm running a contest where if a user clicks an image successfully (jQuery), it passes their userid and a timestamp to a PHP page, both MD5 salted by random data and then encoded with MIME. The PHP page then validates this userid and timestamp, then returns a winning "code" in the form of another salted MD5 hash. I'm also employing multiple header checks to help ensure the request is from a valid location. Am I missing anything, or is that about all I can do? It seems like someone could just fire the jQuery click event and ruin the whole thing, but I don't see how I can prevent that.

Ci sono più immagini e solo un'immagine è corretta e possono essere indovinate solo una volta? Suggerirei di farli usare un token di tipo server di qualche tipo.

Un processo corretto sarebbe (a) che usano le loro credenziali segrete (username, password) per richiedere un token di ipotesi unico (una stringa casuale unica) dal server. Quindi fanno la loro ipotesi (facendo clic su un'immagine) che invia il nome utente, il gettone indizio e l'immagine che hanno scelto. Il server registra l'immagine se il token di prova inviato è valido e non è stato utilizzato in precedenza; altrimenti dice token non valido e getta la loro risposta. Questo continua a far capire a chi ascolta la risposta corretta.

    
risposta data 15.03.2012 - 16:41
fonte
3

Sembra più una questione di manomissione e attivazione di un client Javascript, che SSL non impedisce.

It seems like someone could just fire the jQuery click event and ruin the whole thing, but I don't see how I can prevent that.

Questo è praticamente corretto, lo scripting lato client, specialmente Javascript, è impossibile da bloccare contro cose come l'attivazione di eventi.

The PHP page then validates this userid and timestamp

Prevedo bug dovuti a differenze di latenza / clock (essendo come Javascript sta per estrarre dal PC locale) a seconda della granularità del timestamp, e di quanto avanti / indietro avremo a che fare per vedere se ci sono sono tutte le partite adiacenti.

Inoltre, avendo l'algoritmo qualcuno veramente determinato, cercherà collisioni hash a causa del fatto che MD5 è terribile (se sto capendo correttamente la tua implementazione e sto passando solo gli hash).

Tuttavia, indipendentemente da ciò che utilizzi per la crittografia, è lo scripting lato client, quindi posso semplicemente attivare qualsiasi metodo che utilizzi per inviare i dati al tuo server o semplicemente decodificarlo.

    
risposta data 15.03.2012 - 16:18
fonte
1

Sembra che il tuo gioco offra un comportamento "a quiz", in cui ci sono un sacco di posti che l'utente può cliccare e solo uno di essi è corretto. Il server sa quale è corretto, e il puzzle per il giocatore è quello di capire quale fare clic. È giusto?

Sembra che quello che stai facendo sia inviare la soluzione al quiz (l'ubicazione del luogo corretto in cui fare clic) al client e utilizzare Javascript sul client per controllare ogni clic per vedere se è corretto. Se sembra corretto, lo si invia al server con qualche altra porzione. Ovviamente, questo è intrinsecamente insicuro, perché se l'utente è malintenzionato, può manomettere il Javascript (o l'ambiente di esecuzione di Javascript), sbirciare dentro di esso, capire qual è il posto giusto per cliccare e poi vincere il quiz.

Il modo sicuro per fare ciò è fare tutto il controllo della soluzione sul server. Non inviare la soluzione corretta al cliente. Quando l'utente fa clic su una posizione, invia la posizione al server tramite una query AJAX. Chiedere al codice del server di verificare se il clic dell'utente è corretto o meno, tenere traccia di ciò e inviare una risposta. In questo modo, non importa quanto l'utente abbia problemi con il codice Javascript lato client, non può vedere la soluzione corretta e non ottiene alcun vantaggio nel risolvere il quiz.

La regola generale è: puoi controllare il server, quindi se esegui la codifica corretta dell'applicazione sul lato server, puoi fidarti. Tuttavia, non puoi controllare il client (il browser è sotto il controllo dell'utente, non il tuo controllo), quindi non puoi fidarti del client o del codice lato client. Non fidarti mai del cliente: metti i tuoi controlli di sicurezza sul server.

    
risposta data 15.03.2012 - 18:24
fonte
0

il seguente libro è ottimo per la sicurezza Ajax Sicurezza Ajax , dai un'occhiata

    
risposta data 21.03.2012 - 07:06
fonte

Leggi altre domande sui tag