Come proteggere i dati degli utenti nel sito multiutente?

Question

Come proteggere i dati degli utenti nel sito multiutente?

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

0

Sto lavorando su un sistema in cui le persone possono creare i propri account con poche cose memorizzate nel database come id (che sarà l'incremento automatico), nome, cognome, nome utente ecc.

Ora sono ben consapevole delle iniezioni SQL, quindi sto usando le istruzioni preparate, ma la dichiarazione è sufficientemente preparata da impedire agli hacker di manomettere il mio database?

Tutti conoscono il nome e il cognome delle persone sui social network e potrebbero essere utilizzati:

'delete from table where firstname='john''

o può essere fatto lo stesso con id in quanto è auto incremento possiamo scrivere qualsiasi numero

'update table set firstname='joker' where id=555'.

Quindi la mia domanda è che sono state preparate istruzioni sufficienti per impedire che attacchi o professionisti di sql memorizzino tali informazioni nel database in forma crittografata.

sql-injection databases

posta bɪˈɡɪnə 25.02.2016 - 04:07

fonte

2 risposte

Leggi altre domande sui tag sql-injection databases

Il client ha inviato un certificato con zero byte ma ssl funziona correttamente Fail2Ban continua a mandarmi i log degli utenti bannati, qualcuno sta cercando di hackerarmi?

score 2 · Answer 1

Se stai usando istruzioni preparate ovunque nel tuo codice, allora l'iniezione SQL non dovrebbe essere possibile.

L'iniezione SQL è comunque solo un mezzo di attacco. È inoltre necessario assicurarsi che il sito sia protetto contro altre forme di attacco. La cosa più importante è assicurarsi che non sia possibile caricare file eseguibili, ecc.

score 2 · Answer 2

Are prepared statements enough to prevent SQL injection attacks?

Dubbi, non farei affidamento solo su dichiarazioni preparate. La convalida dell'input è ancora richiesta e altamente raccomandata. Determina quale input ti aspetti in un campo e agisci di conseguenza.

Ad esempio, in un campo nome non devi aspettarti caratteri come ">" o "<". Tuttavia, un personaggio come una citazione è previsto e dovrebbe essere trattato correttamente.

Do professionals store such information in database in encrypted form?

Dipende dal tipo di dati e dalla sua classificazione, in genere non tutti i campi sono crittografati. In caso di carte di credito, ad esempio, devono essere crittografati.

La posizione della chiave di decrittografia è un'altra cosa da considerare. Se la chiave è archiviata sulla stessa macchina in cui sono archiviate le tabelle crittografate, un utente malintenzionato potrebbe ottenere anche questa chiave.

Un attacco di SQL injection può anche portare all'accesso alla shell e non significa necessariamente necessariamente l'estrazione dei dati che si trovano nel database. Se la chiave è archiviata sulla stessa macchina, un utente malintenzionato può recuperare sia i dati crittografati che la chiave di decrittografia.

Nota: la crittografia dei dati in un database non deve essere considerata una soluzione per gli attacchi di SQL injection.