Dovrei preoccuparmi dell'iniezione PHP se non utilizzo MySQL?

Question

Uso un semplice script PHP per eseguire un fumetto online che utilizza fondamentalmente un GET per prendere un valore intero n e inserire un tag img per n .jpg. Non esegue alcuna operazione di disinfezione o di controllo degli errori oltre a garantire che sia presente n .jpg. L'unica interazione dell'utente con lo script è attraverso questo GET, e un altro che fa la stessa cosa con una stringa per visualizzare manualmente un modello diverso per il test.

La mia domanda è: dovrei anche preoccuparmi dell'iniezione? E se sì, cosa dovrei fare per impedirlo? Tutto quello che ho trovato finora riguarda solo l'iniezione di MySQL, che non si applica in questo caso.

Answer 1

Se non si utilizza un database, quindi ovviamente l'iniezione SQL non è una preoccupazione per il tuo. Allo stesso modo, se non si memorizzano i dati inviati dall'utente da mostrare ad altri utenti, Cross-site-scripting non è un problema. Ciò lascia cose come eval() o processi esterni che un utente malintenzionato potrebbe sovvertire, ma non sembra che tu faccia qualcosa del genere.

Quindi probabilmente sei al sicuro. Tuttavia, sarebbe bene avere un minimo di controllo degli errori, solo per prendere l'abitudine. Ad esempio, tu dici che hai un intero parametro GET. Non esiste una cosa del genere: tutti i parametri HTTP sono stringhe implicite. PHP sfoca la distinzione, ma è assolutamente necessario eseguire il cast in int esplicitamente per assicurarsi che non si tratti di una stringa destinata a sfruttare una vulnerabilità XSS, SQL injection o eval (anche se nessuna di queste esiste).

Answer 2

Si dovrebbe sempre preoccuparsi della sicurezza. Non ogni buco di sicurezza è costituito dall'uso sbagliato di mysql :-)

Answer 3

Se si suppone get a contenere solo un uso intero

$n = intval($_GET['n'])

Answer 4

L'iniezione SQL non è applicabile nel tuo caso, perché si non stanno usando un database per il tuo sito. Ma dovresti considerare altri problemi di sicurezza per il tuo sito, ad esempio cross site scripting.

Se si utilizza una variabile da GET, considerare sotto url:

index.php?myvar=<script>alert(document.cookie);</script> 

Gli hacker sono in grado di fornire sopra URL in un numero esadecimale modi, UTF, ecc

Un cattivo ragazzo può modifica le tue variabili GET per eseguire attacchi XSS. XSS è la radice di molti buchi di sicurezza. Devi considerare anche questo.

Se vi aspettate un tipo numerico dal GET var quindi prendere in considerazione sottostante Codice:

$myvar = (int) $_GET['your_var']; 

si dovrebbe usare htmlentities funzione per prevenire gli attacchi XSS.

Answer 5

Controllare sempre l'input dell'utente e $ _GET e $ _POST per i contenuti dannosi. Addslashes, ereg_match e intval sono tuo amico ...

Se si riesce a farla franca, impostare la direttiva

allow_url_fopen = Off 

in php.ini

Answer 6

Se si aspetta un numero, non disinfettare l'input errato, negarlo.

if (!ctype_digit($user_input)) { 
    header('Location: error.php'); // or whatever page 
    exit; 
} 

Answer 7

Mi piacerebbe anche richieste colpito la directory di immagini desiderato troppo, in quanto non si vuole che la gente la navigazione del file server con richieste come example.com/?q=../../.htaccess

Non sono sicuro di come sarebbe influenzare l'uscita, ma non può essere buono.

Answer 8

Non devi preoccuparti dell'iniezione SQL. Ma dovresti controllare i tuoi input così come sono usati nel codice HTML che generi. Immagina di dare questo link http://www.example.com/viewComic.php?id="/><script type="text/javascript>alert("XSS");</script><img src="22 a qualcuno. Questa persona avrà un piccolo pop-up proveniente dal tuo sito web. E un sacco di cose brutte possono essere fatte con javascript. Per ulteriori informazioni, puoi iniziare a leggere la pagina di wikipedia su XSS.

Quindi, si dovrebbe verificare che il numero che si aspetta sia un numero. Ad esempio con is_numeric.