Rischio di sicurezza derivante dai dati trasmessi in $ _GET superglobal

Sembra che il mio commento non sia arrivato qui, quindi lo posterò come risposta:

No, non è un serio problema di sicurezza. Se il tuo sito ha per esempio una vulnerabilità cieca di SQL injection, questo renderebbe più facile attaccare un utente specifico. Probabilmente rende anche molto più facile raschiare il tuo sito Web per i profili utente, se questo è un tuo problema. Ma a parte questo, non riesco a pensare a un modo per attaccare questo.

Ma se sei ancora preoccupato: No, le variabili post nascoste non sono la risposta. Invece, non passare gli id, ma passare invece slug di nomi utente / postnames / etc (gli slug dovrebbero essere disinfettati, in modo che contengano solo caratteri url validi). Questo è anche più user e seo friendly.

Ma assicurati di non inviare i dati forniti dall'utente direttamente all'utilizzatore finale. Devi prima disinfettarlo per prevenire attacchi xss (e conta come fornito dall'utente anche quando proviene dal database - se i dati nel database sono forniti dall'utente).

L'utilizzo del POST al posto dei parametri URL non ha alcun vantaggio per la sicurezza. I dati POST possono essere modificati proprio come i parametri URL. In effetti, non devi fidarti di nessun dato proveniente dall'utente, che si tratti di un parametro URL, un parametro POST, un cookie, un'intestazione HTTP o altro. Quasi tutti gli input sono sotto il controllo dell'utente e possono essere qualsiasi cosa vogliano.

La chiave è trattare ogni valore che non è codificato come una potenziale minaccia e assicurarsi che non causi alcun danno. Le istruzioni preparate sono una buona scelta per le query dinamiche, poiché garantiscono che i valori vengano trattati come dati anziché come istruzioni SQL. Per inserire valori nel tuo documento HTML, devi eseguire l'escape HTML; i comandi di shell richiedono che i valori siano di tipo escape-shell e così via.

Ci sono due aspetti alla domanda qui:

1. Sta usando l'ID dall'URL (GET) sicuro? Risposta breve, no. Come ogni altro dato, deve essere convalidato e filtrato prima dell'uso. Ciò impedisce l'avvio di problemi come SQL injection e rende l'applicazione vulnerabile. Convalidare che si tratta di un ID, convalidare che si tratta di un ID valido e utilizzare istruzioni preparate per ridurre ulteriormente il rischio.

2. Poiché sono ID (interi) è sicuro usare qualcosa che l'utente può cambiare? Questo è dove le cose diventano un po 'più complesse. Questa parte del problema riguarda meno i dati che ti stanno dando (è il numero 1) e maggiori informazioni sull'accesso e l'autenticazione. Ad esempio, nella maggior parte delle applicazioni una "vista" su un utente è a posto per chiunque. Tuttavia, una "modifica" potrebbe essere consentita solo all'utente e all'amministratore. Qui è dove serve quel livello di protezione che controlla chi è l'utente e quali permessi hanno per quella pagina / risorsa. Questo è correlato all'elemento "Insecure Direct Object References" di OWASP nella Top 10. È un problema piuttosto comune, ma la risposta corretta è auth * protection, non offuscamento attraverso i campi POST o hidden.