come dovrei proteggere il parametro url nella query JPQL per reimpostare il flusso della password

Question

come dovrei proteggere il parametro url nella query JPQL per reimpostare il flusso della password

#1 da (0 voti)
#2 da (0 voti)

1

Sto implementando un'app Web con il ripristino del flusso della password. Ecco cosa ho fatto per cercare di renderlo sicuro.

Inserisci l'indirizzo email nel modulo password dimenticata.
Indipendentemente dal fatto che il cliente esista, l'applicazione segnala una email inviata, questo evita di rivelare l'esistenza di un indirizzo email.
Genero una stringa casuale sicura, quindi la crittografo e la utilizzo come token di accesso con validità di 1 giorno.
Il cliente fa clic sul link indietro che ha un parametro token, controllo la tabella clienti e li autorizzo al modulo di reimpostazione della password se il token è valido.
In questo modulo inserisco il valore del token, non l'ID del cliente in fase di reimpostazione che evita di esporre l'id.

Ora la prima domanda è, è abbastanza sicuro?

Ma la mia domanda principale è relativa a Hibernate e parametri - la mia query è come "Seleziona c dal cliente dove c.token =? 1 and c.activeDate > DATe_NOW". Passo nel valore del parametro token non elaborato.

In JPA / Hibernate o JPQL, c'è il rischio di un attacco di iniezione modificando il parametro token quando sto usando parametri posizionali come questo nella query?

sql-injection

posta Richard G 23.07.2015 - 15:04

fonte

2 risposte

0

Non sono abbastanza sicuro di ciò a cui ti riferisci quando dici di usare "Ibernazione" (NHibernate?)

In entrambi i casi, di solito quando vedi il modello di sostituzione di un parametro con ? , suggerisci che stai lavorando con una query parametrizzata. Se utilizza query parametrizzate, sarai protetto da SQL Injection nella tua situazione.

Se riesci a chiarire quale tecnologia stai utilizzando, posso dare una risposta più chiara.

risposta data 23.07.2015 - 16:38

fonte

Leggi altre domande sui tag sql-injection

cosa è più sicuro, avere PPPoE sul modem o sul firewall In che modo viene inviata la messaggistica OTR con il Socialist Millionaire Protocol (SMP) protetto da Man In The Middle?

score 0 · Accepted Answer

In primo luogo, non vedo alcun vantaggio nel crittografare la stringa casuale nel passaggio 3. (Non vedo una differenza tra il tentativo di indovinare una stringa casuale e una stringa casuale crittografata - che potrebbe essere considerata solo un'altra stringa casuale .) Ma non vedo come questo faccia male ...

Per la tua prima domanda, il tuo algoritmo è abbastanza sicuro? Dipende dal tipo di dati / funzionalità che stai proteggendo. Il tuo metodo fa semplicemente supporre che se hai accesso all'indirizzo e-mail associato all'account, dovresti avere il permesso di reimpostare la password, e sembra che tu stia realizzando questo in modo ben congegnato e ragionevolmente sicuro. Se il tuo sito ha transazioni finanziarie o record sanitari, potresti prendere in considerazione l'aggiunta di un ulteriore passaggio di verifica; le domande di sicurezza sono il modo più comune per farlo. Se il tuo sito ha segreti governativi o codici nucleari, probabilmente vorrai costringere le persone a reimpostare la loro password di persona ...

Per quanto riguarda la tua seconda domanda, con SQL parametrizzato sei protetto da SQL injection. Non importa veramente quale sia il token o se qualcuno si diverte a mettere 'DROP TABLE' nella loro stringa token. Corrisponde al token previsto o non lo farà.

Per inciso, suppongo che anche se l'hai lasciato aperto per l'iniezione SQL, il fatto che tu stia codificando / decrittando il token renderebbe piuttosto difficile per qualcuno iniettare codice sql significativo a meno che non sapessero che stavi facendo questo e come lo stavi facendo. Quindi, anche se ho iniziato dicendo che la crittografia non è necessaria, suppongo che potrebbe essere d'aiuto come una "sicurezza per oscurità" se non avessi alcuna protezione contro l'iniezione sql.