2013-12-08 14 views
7

Sto costruendo un sito quiz, dove memorizzo alcune variabili (tempo impiegato per rispondere, quale opzione di risposta è stata scelta dall'utente ecc. Ecc.) In $_SESSION s dopo ogni domanda - dove ho inserito queste statistiche solo nel DB dopo che l'utente ha completato il quiz.

Ho implementato alcuni if per verificare se le variabili $_SESSION sono numeri (is_numeric()). Anche io convalidare la lunghezza (strlen()) ecc

  • Ma c'è un motivo per farlo?
  • O è sufficiente solo a real_escape_string() quelli prima di memorizzarli in MySQL?
  • Inoltre, se ci fossero molti utenti, non sarà questo a mettere un grosso carico sul server ?
+1

Se sei interessato a prevenire l'SQL injection, dovresti usare PDO o mysqli con istruzioni parametrizzate. In questo modo, indipendentemente da ciò che inserisci, non verrà mai valutato come codice MySQL. – jpodwys

+0

Il caso è che non sto parlando solo di iniezioni SQL. Non c'è altro modo in cui qualcuno può attaccare il mio sito usando le variabili passate dall'utente? – joe007

+0

@ joe007 sì, come XSS. –

risposta

8

No, dal momento che li hai impostati da soli.

A meno che non vengano dedotti direttamente dall'input dell'utente, nel qual caso si applicano le stesse regole valide per ogni bit di input dell'utente.

Non c'è niente di speciale sulle variabili $_SESSION. È necessario disinfettare l'input dell'utente quando lo si riceve dall'utente, indipendentemente dal fatto che lo si memorizzi in un database, una sessione o così via.

Come suggerito da JPod - quando si eseguono query SQL, utilizzare sempre query preparate che riducano l'iniezione SQL.

+1

Sì, ma diciamo che ho impostato la variabile $ _SESSION su _page1_ quindi viene letta su _page2_. Se lo sanitizzo su _page1_ e non mi interessa su _page2_, allora un hacker/cracker può semplicemente inviare codice/materiale dannoso tramite $ _SESSION direttamente a _page2_ usando un software? – joe007

+2

@ joe007 l'utente front-end non ha accesso diretto a '$ _SESSION', _ sei tu a mettere le cose lì. Se si disinfetta l'input _before_ lo si inserisce nella variabile di sessione (e si dovrebbe fare sempre _), non diventerà magicamente pericoloso. Più in generale, dovresti disinfettare tutto ciò che ricevi dal cliente religiosamente e senza pietà, deve essere chiaro, coerente, esplicito e in un unico posto. Non ci dovrebbero essere dubbi su quali dati sono sporchi e quali dati sono puliti. –

+3

Oh ok non sapevo che l'utente non potesse riscrivere $ _SESSION in qualche modo. Grazie mille :) – joe007

Problemi correlati