Dovrei criptare il numero di cellulare e otp quando invio al back-end

What my concern is someone can figure out the API, and start hitting with different combination of OTPs for mobile number and gain the access to an account

Questa è una domanda frequente relativa alla sicurezza delle applicazioni web. Una volta che le nostre API sono pubbliche, sono esposte a qualsiasi tipo di malizia.

Oltre al link , che dovrebbe essere obbligatorio, ecco alcune misure da prendere in considerazione.

Soglie

Impostazione di un numero massimo di richieste al secondo e origine ( indirizzo remoto ). Diciamo X Req / s per indirizzo IP.

Le soglie vengono comunemente implementate nel gateway API o nel server di autenticazione. Molti gestori API forniscono il controllo delle soglie fuori dalla scatola.

Il punto è che il numero di combinazioni possibili di telefono / otp e le rispettive permutazioni sarà di solito superiore alla soglia, cosa che riduce le possibilità di colpire una tupla valida o, almeno, fa più difficile.

Possiamo impostare endpoint con soglie diverse. Di solito, gli endpoint correlati alla sicurezza avranno valori inferiori rispetto a quelli relativi al business.

Il colpire la soglia causa il divieto. Il ban dura tutto il tempo che vuoi (1, 5, 10 minuti, ...). Se ti piacciono le liste nere, questo è il posto giusto per aggiungerne uno.

Casi di studio:

• foglio trucchi DDoS
• Scheda Trucchi sulla sicurezza REST
• Sicurezza IoT

Opacità

Spesso pensiamo che dovremmo fornire quante più informazioni possibili all'utente quando si verificano errori. Va bene quando parliamo di regole aziendali, ma non è quando parliamo di sicurezza.

Se la procedura di accesso fallisce, è sufficiente una credenziale non valida semplice. Non dire a chi c'è dall'altra parte del cavo le cause dell'errore.

Rendere la tua sicurezza opaca agli esterni riduce la superficie di attacco.

Token di autenticazione

Ti incoraggerei a non reinventare la ruota, in generale con la sicurezza. JWT .

È un vantaggio se puoi forzare la scadenza a volontà dal back-end.

Casi di studio:

• Cheat Sheet di autenticazione

Tracciabilità

Https sono crittografate. Tuttavia, le stringhe di query possono essere tracciate nei file di registro una volta che il messaggio è stato decodificato. Quindi, non importa se i valori della stringa di query sono stati crittografati due volte. Suggerirei di inviare la richiesta POST per i processi di autenticazione. Fallo per qualsiasi altra richiesta che possa trasportare dati sensibili.

Convalida del certificato

Come prevenzione per MITM , controllando se il certificato del server corrisponde al dominio del server è un vantaggio.

La consapevolezza

La sicurezza è un affare serio. Tieniti aggiornato e ben documentato. Qui un buon posto per iniziare a lavorare. OWASP - Categorie .

Ecco alcuni progetti interessanti:

• Pratiche di codifica sicure
• Cheat Sheet Series
• Scheda cheat di test delle applicazioni Web

Ci sono due punti principali di attacco contro il tuo sistema:

1) il canale di trasporto, che potrebbe contenere i dettagli di accesso (numero + password)

2) la tua API che potrebbe consentire a un nodo sconosciuto di indovinare ripetutamente le credenziali, per un determinato numero di telefono

Come proteggere?

• Come detto nei commenti, la crittografia del numero e OTP non è sufficiente per la protezione da 1: perché se l'API accetta l'input crittografato, l'utente malintenzionato deve solo intercettare la versione crittografata.

• link

• La crittografia dell'OTP del telefono o di entrambi, in linea di principio non ti protegge contro 2: se l'OTP 1234 è crittografato su xEHg, è solo una questione di tempo prima che la versione crittografata venga indovinata. Quanto segue aumenterà la tua difesa:

  • usa OTP più lungo (8 sembra un minimo)
  • lascia vivere l'OTP per un intervallo di tempo più breve (se l'OTP cambia ogni minuto, sarà troppo breve per indovinare milioni di combinazioni)
  • se un indirizzo IP fa più di N ipotesi sbagliate, blocca quell'IP per un certo periodo di tempo
  • se ci sono più di K errori errati di OTP per un dato telefono, blocca l'indirizzo IP di origine per un certo periodo di tempo, o notifica all'utente il rischio o entrambi

Queste misure sconfiggeranno l'ipotesi OTP.

Al di là di ciò che dice Amon: non utilizzare MAI http. Usa sempre https. In questo modo tutto è criptato e sai che va nella giusta destinazione.

PS. Quello che dice Burghardt è sbagliato . Afferma che i parametri di una richiesta https vengono inviati non crittografati e mostrano una cronologia di Firefox come prova. Ma Firefox ha inviato la richiesta https, quindi Firefox sulla tua macchina conosce i parametri e può registrarli - ma allora vengono crittografati prima di essere spedito.

Prima di tutto, non sono una persona di sicurezza. Quindi tutto ciò che dico qui può o non può essere stupido.

Il mio primo pensiero è che se non si cripta il numero di cellulare, qualsiasi terza parte può risucchiare il flusso di dati e raccogliere informazioni che collegano direttamente un identificatore pubblicamente noto con un utente del proprio sistema.

Questo può o non può influire sull'inpenibilità della tua API, ma ha il potenziale per influenzare i tuoi utenti.

Modifica

Vedi ... Sapevo che l'avvertenza avrebbe dovuto tornare utile. Non ho notato il problema di http rispetto a https!

Il problema da un punto di vista della sicurezza è il codice One-Time e il numero di cellulare viene passato come parametri della stringa di query. Se le informazioni sono ritenute sensibili in alcun modo, non utilizzare una richiesta GET con parametri stringa di query. Utilizzare una richiesta POST e passare i parametri come parte del corpo della richiesta e crittografarla utilizzando HTTPS.

HTTP + GET = Problema di sicurezza

HTTPS + GET = Stesso problema di sicurezza

HTTPS + POST + Il passaggio dei parametri nel corpo della richiesta indica che i dati effettivamente vengono crittografati e non sono visibili nella cronologia del browser di qualcuno o nei file di registro del server Web di destinazione per la richiesta.

amon ha commentato:

Could you please explain why HTTPS + query params in the URL is a security problem? As far as I understand, HTTPS encrypts the complete payload incl. headers and the URL during transit. The only info that can't be encrypted is the server hostname.

Dai un'occhiata alla cronologia del tuo browser. Ecco uno screenshot di Firefox della mia recente cronologia del browser:

Comepuoivedere,hovisitatoil link . La parte ?sort=newest è la stringa di query ... su un URL HTTPS. Visibile nella cronologia del browser, inclusi i log di accesso sul server Web di destinazione.