Se visualizzo user_id che rappresenta ciascun utente unico nel db come atrribute in un elemento HTML, è una buona pratica? Perché ho bisogno del riferimento all'utente se voglio eseguire un'azione su quell'utente particolare come aggiungerlo per essere mio amico.
Esempio in HTML:
<div data-user-id='12' onclick=addFriend(12)>
Click to add John as your friend
</div>
Il 12 rappresenta l'ID utente effettivo dell'utente dal db. Quindi è sicuro dal punto di vista della sicurezza fare questo?
Secoli fa si credeva che il nome avesse un potere arcano sul nome. I genitori darebbero ai loro figli un secondo nome segreto in modo che i loro nomi usati di solito fossero parziali, e i maghi malvagi non saranno in grado di conoscere facilmente i loro nomi completi e usarli negli incantesimi.
Quelli di noi che vivono nell'era della scienza moderna sanno che questa è un'assurdità. Anche se conosci il mio nome completo, non sarai in grado di lanciare una maledizione di lebbra contro di me. Al massimo, sarai in grado di cercarmi su Google e trovare alcune informazioni pubbliche su di me. Non c'è alcun rischio reale qui - il rischio è così basso che i miei genitori non sentono il bisogno di darmi un secondo nome segreto e che non mi dispiace nominare il nome nell'angolo in basso a destra di questa risposta.
Gli ID nella tua pagina sono simili agli innocui nomi moderni o ai nomi mistici dei vecchi? Se conosco il tuo ID, ho il potere sul tuo account? Posso cambiare le tue impostazioni? Posso creare post per tuo conto? Ordina prodotti con i tuoi soldi? Accedi alla tua casa intelligente e modifica la modalità di Alexa in "Killer AI"?
Se la sicurezza è importante, non è necessario rispondere a questa domanda: è sufficiente accertarsi che la risposta sia NO. Hai citato il database SQL, ma se ho accesso al tuo database posso solo trovare gli account utente per nome, anche se non conosco i loro ID. Uno dei commentatori (David Arno) ha menzionato la modifica dell'ID in un collegamento, ma il server dovrebbe comunque controllare le credenziali per determinare se è consentita una query o un'operazione. Se l'ID da solo è sufficiente per gli estranei di attaccare - la tua sicurezza è già compromessa.
La sicurezza non dovrebbe essere nell'interfaccia utente. Dovrebbe essere nel server. Le uniche parti della sicurezza che hanno qualcosa a che fare con la macchina del cliente sono il meccanismo delle credenziali per impedire la rappresentazione e il meccanismo di crittografia per impedire l'intercettazione.
No, non vi è alcun difetto di sicurezza intrinseco con l'inserimento degli ID utente in HTML. Dopo tutto, è una pagina web. È necessaria la pagina Web per consentire all'utente di aggiungere amici e senza qualche tipo di valore identificativo, non è possibile farlo. È necessario fornire il valore identificativo nella pagina Web in qualche posto, sia che si tratti di un attributo onclick o data-x o di un campo modulo nascosto. Questo è semplicemente come funziona il World Wide Web.
Il difetto di sicurezza potrebbe provenire dal codice JavaScript eseguito nel gestore di eventi onclick . Se l'aggiunta di qualcuno come amico risulta in una richiesta GET al server, allora qualcuno deve solo pubblicare una pagina web su Internet con alcuni tag <script> che fanno riferimento al tuo URL e ingannare gli utenti registrati a visitare questa pagina (che non è un grosso problema se gli utenti possono pubblicare messaggi o commenti e incorporare URL in essi).
<script src="https://example.com/friends/add/1"></script>Supponiamochel'URLhttps://example.com/friends/add/1siailmodoincuiunamicovieneaggiuntoall'elencodiamicidell'utentecorrenteerispondeancheaunarichiestaGET.UnapaginawebconiltagSCRIPTinaltonellasuasorgenteHTMLfaràsìcheilbrowserinviiunarichiestaGETaquell'URL,anchesenonrestituisceJavaScriptvalido!Epoichél'utentecorrentehaeffettuatol'accesso,ilbrowserinviafelicementeilpropriocookiedisessionealserverwebdicendo"hey, questa persona è loggata" e il tuo server web non è il più saggio.
Se l'utente che sta visualizzando questa pagina è collegato al tuo sito, boom. Hanno un nuovo amico.
Puoi evitare questo tipo di attacco assicurandoti che qualsiasi richiesta al server che modifica i dati richieda una richiesta POST, PUT o DELETE.
Quindi la risposta finale è:
No, inserire ID di database in HTML non è intrinsecamente pericoloso. È così che vengono usati quegli ID che potrebbero essere pericolosi.
L'identificazione dei valori non è un rischio per la sicurezza a meno che non rientrino in queste categorie:
E assicurati che qualsiasi richiesta al server che modifica i dati in qualsiasi modo richieda una richiesta POST, PUT o DELETE e mai una richiesta GET.
L'ID direttamente nel codice HTML non è intrinsecamente insicuro di per sé.
Tuttavia, mi preoccuperei di questo: sembra che tu stia usando ID consecutivi (dato che l'ID di esempio è un numero basso, direi che è un autoincremento o impostato da un trigger). Ciò costituisce una vulnerabilità di enumerazione degli utenti.
Utilizza id casuali o una lunghezza ragionevole, così facendo ridurrai il rischio che un utente malintenzionato possa indovinare gli ID degli utenti.
Un utente malintenzionato può scrivere uno script che itera su id e aggiunge tutti come amici. Anche se mai respingi qualcuno (e ti assicuro che alcuni non lo faranno, perché ci sono persone che accettano tutti), quello script infastidirebbe molti utenti e aggiungerebbe carico ai tuoi server.
Ciò peggiorerebbe di più le funzioni che l'utente può chiamare con questi ID (ad esempio, questo potrebbe rivelare informazioni private o sensibili sull'utente. Assicurati di controllare chi sta richiedendo e quali o no hanno accesso a tali informazioni ), e ancor peggio se esiste una vulnerabilità di SQL Injection (il fatto che tu abbia menzionato una query nei commenti mi fa preoccupare di questo, per favore usa le dichiarazioni preparate, grazie).
C'è anche il rischio di attacchi cross-site. La tua funzione addFriend dovrà tradursi in definitiva su alcune richieste al server, giusto? Se esiste la possibilità di simulare quella richiesta (falsificazione richiesta cross-site) o di chiamare la funzione (cross-site scripting), un utente malintenzionato potrebbe inviare un link alla vittima che quando è aperta - mentre la vittima ha una sessione aperta sul tuo sito - comporterebbe l'aggiunta di una terza parte come amico.
Ci sono molte cose da fare per mitigare gli attacchi tra siti. Si prega di fare riferimento agli articoli di Owasp su Cross-Site Requst Forgery e Cross-Site Scripting .
Troverete che una cosa che puoi fare è generare codici che significano "Aggiungi X come amico" che sono monouso e legati alla sessione dell'utente. Ciò significherebbe che nessuno script o richiesta di falsificazione sarà in grado di aggiungere un amico per il quale il codice non è stato generato. E lo stesso approccio può essere fatto per qualsiasi altra funzione o richiesta che deve essere protetta.
Altre cose che potresti prendere in considerazione: puoi anche "aggiungere un cooldown" all'operazione, assicurandoti che una funzione che li chiama in rapida successione non funzioni. In effetti, l'esecuzione di uno potrebbe invalidare e rigenerare tutti gli altri codici, rendendo qualsiasi script che li legge e li usa come difficilmente implementabili (in più si saprebbe chi continua a farlo e produce un divieto temporaneo).
Addendum: utilizza Captcha in attività notevoli.
Nota: non memorizzarli nel database permanente. Per esperienza personale, questo diventa un disastro molto rapidamente. Inoltre, non legarli all'utente, ma alla sessione. In effetti, usare le variabili di sessione (anche se supportato da un database) è un buon approccio.
Tuttavia, invece di memorizzare tutti i codici validi (e salvare la memoria sul server), è possibile generare e memorizzare una chiave criptografica e utilizzarla per codici cifrati che rappresentano l'operazione. Se lo fai, invalidare i codici implica la sostituzione della chiave con una nuova.
Vedi anche: Il bug di Moonpig: come sono stati esposti 3.000.000 di dettagli dei clienti dove Tom Scott spiega una numerazione di utenti vulnerabilità.
Leggi altre domande sui tag web-development