Quanto è sicuro inviare una password in testo semplice usando AJAX?

Question

Forse il titolo è mal formulato ma non riusciva a pensare a un modo migliore di dirlo.

Attualmente sto lavorando su un sistema di login (niente di formale, solo sperimentazione) e stavo pianificando di usare PHPLiveX (una libreria AJAX) per alcune funzionalità. Fondamentalmente si creano alcune funzioni PHP che vengono poi chiamate tramite JavaScript. È possibile aggiungere parametri (getElementById) al codice JavaScript trasferito alla funzione PHP.

Quello che volevo veramente sapere è se è sicuro chiamare la funzione da JavaScript senza crittografare prima la password, quindi lasciare che la funzione PHP la cripta (SHA256 in questo caso). I dati trasferiti tramite AJAX possono essere intercettati? Se sì, quanto è probabile questo?

Answer 1

Non più o meno sicuro di un normale richiesta HTTP POST rilasciato da un browser (come in da un <form>)

"Fix" per questo è lo stesso "fix" per i non-AJAX richieste - usa SSL.

Answer 2

Le chiamate AJAX sono semplicemente richieste HTTP.

Si comporta come una normale richiesta HTTP e viene fornito con tutti i vantaggi e gli svantaggi. Non è più sicuro.

Per rendere il vostro chiamate AJAX al sicuro, ci sono diversi modi si può provare:

1. Usa SSL. SSL crittograferà i messaggi tra l'utente e il server. Lo svantaggio di SSL è che dovrai pagare una tariffa aggiuntiva per i certificati SSL validi. I certificati SSL non validi quando sono utilizzabili, non forniscono lo stesso livello di garanzia di sicurezza agli utenti.
2. Crittografa le richieste prima di essere inviate, lato client. Ad es .: password degli utenti hash prima di essere inviata in rete. La maggior parte delle volte, non è comunque necessaria la password di testo in chiaro degli utenti. Questo non è utilizzabile quando gli utenti non consentono l'esecuzione di script sul lato client.
3. E a parte le informazioni fuorvianti comuni in cui il POST è più sicuro di GET, non lo è. Entrambi sono ugualmente aperti agli attaccanti per vedere.

Answer 3

Se si invia la password tramite AJAX o tramite un modulo normale, viene comunque inviata tramite una richiesta HTTP POST (si spera). Quindi non stai aggiungendo o rimuovendo nulla dal punto di vista della sicurezza.

L'unico modo per impedire a qualcuno di intercettare la password è utilizzando SSL (tramite AJAX o no).

Answer 4

La password di testo in chiaro trasmessa tramite AJAX sarà sicura quanto la stessa password trasmessa tramite un normale post HTTP. Vale a dire che AJAX utilizza HTTP e può quindi essere intercettato e annusato. La soluzione migliore è utilizzare HTTPS (SSL).

Per ulteriori letture su AJAX e sicurezza vi consiglio i seguenti letture

• Top 10 Ajax Security Holes and Driving Factors
• Ajax security holes and how to fill them

Answer 5

Questo è solo sicuro come avere un form di login che non è SSL essere spedito via cavo, come quasi tutti i forum là fuori!

Answer 6

Non è sicuro. Non inviare password non crittografate. È molto probabile che verranno intercettati a un certo punto e avrai un grosso problema.

Questo è un esempio video di acquisizione di una password telnet. Telnet manda un messaggio in chiaro e questo illustra chiaramente il problema principale che hai se pensi di farlo. Qualsiasi script kiddie a due bit può intrappolare una password in testo semplice più velocemente di quanto tu possa così "Oh mio Dio, dov'è finito il mio database?"

Answer 7

Assicurati che la destinazione della tua chiamata AJAX sia una pagina HTTPS attendibile: // e l'hai resa altrettanto sicura delle altre mandate delle stesse informazioni che sta facendo il resto della tua applicazione. La maggior parte delle librerie/framework non ti limita a solo HTTP: // per le tue chiamate AJAX.

Answer 8

Lo si sta inviando in chiaro, quindi chiunque abbia lo sniffing/listening/etc, la rete del client sarà in grado di vedere facilmente la password. La chiamata AJAX è solo un semplice vecchio messaggio HTTP. Se vuoi vedere questo in azione, accendi una copia di wireshark e fai la tua richiesta. Sarai in grado di vedere la password nel pacchetto HTTP.

Answer 9

Sì, può essere letto. Proprio come tutto il resto senza un qualche livello di sicurezza (Vedi SSL)

Per vederlo, esegui uno strumento come WireShark mentre esegui i comandi AJAX.

Quanto è probabile? Non molto, ma la password dell'utente verrà probabilmente salvata nei file di registro di qualcuno in testo normale. Se qualcuno lo avesse trovato, allora potrebbe essere una brutta notizia. Tornato al college, la mia classe di networking aveva accesso ad alcuni router (semi) fantasiosi. Abbiamo avuto incarichi in cui ci siamo registrati per account su siti web casuali. Mentre facevamo questo, abbiamo notato alcune cose molto spaventose sui file di log nei router. Questo mi ha aperto gli occhi per pensare a come ogni tracciamento è tracciato e molto probabilmente registrato da qualche parte.

Answer 10

Come altri hanno già detto, non è più pericoloso che inviare un messaggio HTTP da un modulo. In effetti, è la stessa cosa.

Ma se HTTPS non è un'opzione, è sempre possibile utilizzare uno schema di richiesta/risposta su una connessione non crittografata. Fondamentalmente funziona così:

• Il server ha uno SHA (o qualsiasi algoritmo di hashing che si preferisce) hash della password dell'utente.
• Il client ha la password.
• Le richieste dei client (utilizzando in chiaro AJAX) che il server di inviare una sfida (una stringa casuale di byte; caratteri vanno bene.)
  
• Server crea una sfida e un ID di sfida, e la salva con una scadenza.
• Il cliente riceve la sfida e l'ID della sfida.
• Client hash la password utilizzando SHA.
• Il client esegue l'hash risultante con la sfida aggiunta in qualche modo.
• Il client invia l'ID sfida (non la sfida stessa) e il secondo hash risultante.
• Il server cerca la sfida usando l'ID se esiste e non è scaduto.
• Il server accoda la richiesta all'hash della password memorizzata e crea un hash utilizzando lo stesso schema del client.
• Il server confronta l'hash con il client.Se è lo stesso, l'utente è autenticato.

In realtà è piuttosto semplice da configurare una volta ottenuta l'idea. Wikipedia ha alcune informazioni aggiuntive su di esso.

EDIT: ho notato ho dimenticato di dire, se l'autenticazione va a buon fine si necessario eliminare la sfida, a prescindere. Dare al cliente più tentativi su una sfida potrebbe portare a problemi di sicurezza.

Answer 11

Come già accennato, SSL è la soluzione migliore qui. Tuttavia, si potrebbe hash la password sul lato client. Se cerchi google, troverai moltissime implementazioni javascript di md5.

Answer 12

dannazione voi ragazzi mi preoccupate. SSL non protegge dall'attacco MITM dell'avvelenamento dell'arp. Sarebbe fatale adorare SSL come voi. È necessario disporre di un modo per crittografare la password sul lato client prima di effettuare anche un solo salto o anche un nuovo hacker sarà in grado di intercettare la password in chiaro

Answer 13

Si dovrebbe anche essere molto consapevoli delle potenziali vulnerabilità di sicurezza durante la costruzione un'applicazione che utilizza Ajax.

Il seguente sito ha alcune davvero buone informazioni per quanto riguarda l'Ajax e XSS o XSRF Attacchi http://www.isecpartners.com/files/isec-attacking_ajax_applications.bh2006.pdf

Non dimenticare che quando si effettua una funzione remota accessibile a una chiamata javascript, un utente potrebbe semplicemente indovinare la funzione di chiamalo e modificalo per fare le sue offerte.