Htmlspecialchars e mysql_real_escape_string proteggono il mio codice PHP dall'iniezione?

All'inizio di oggi è stata posta una domanda sulle strategie di convalida degli input nelle app Web .

La risposta principale, al momento della scrittura, suggerisce di PHPutilizzare solo htmlspecialcharse mysql_real_escape_string.

La mia domanda è: è sempre abbastanza? C'è di più che dovremmo sapere? Dove si scompongono queste funzioni?

Quando si tratta di query di database, provare sempre a utilizzare query parametrizzate preparate. Le librerie mysqlie lo PDOsupportano. Questo è infinitamente più sicuro rispetto all'utilizzo di funzioni di escape come mysql_real_escape_string.

Sì, mysql_real_escape_stringè effettivamente solo una funzione di escape della stringa. Non è una bacchetta magica. Tutto ciò che farà è sfuggire a caratteri pericolosi in modo che possano essere usati in sicurezza in una singola stringa di query. Tuttavia, se non disinfetti in anticipo i tuoi input, sarai vulnerabile a determinati vettori di attacco.

Immagina il seguente SQL:

$result = "SELECT fields FROM table WHERE id = ".mysql_real_escape_string($_POST['id']);

Dovresti essere in grado di vedere che questo è vulnerabile agli exploit.
Immagina che il idparametro contenga il vettore di attacco comune:

1 OR 1=1

Non ci sono caratteri rischiosi da codificare, quindi passerà direttamente attraverso il filtro di fuga. Lasciandoci:

SELECT fields FROM table WHERE id= 1 OR 1=1

Che è un adorabile vettore di SQL injection e consentirebbe all'autore dell'attacco di restituire tutte le righe. O

1 or is_admin=1 order by id limit 1

che produce

SELECT fields FROM table WHERE id=1 or is_admin=1 order by id limit 1

Ciò consente all'autore dell'attacco di restituire i dettagli del primo amministratore in questo esempio completamente fittizio.

Sebbene queste funzioni siano utili, devono essere utilizzate con cautela. È necessario assicurarsi che tutti gli input Web siano convalidati in una certa misura. In questo caso, vediamo che possiamo essere sfruttati perché non abbiamo verificato che una variabile che stavamo utilizzando come numero fosse effettivamente numerica. In PHP dovresti usare ampiamente un insieme di funzioni per verificare che gli input siano numeri interi, float, alfanumerici ecc. Ma quando si tratta di SQL, fai attenzione al valore dell'istruzione preparata. Il codice precedente sarebbe stato sicuro se fosse stata un'istruzione preparata poiché le funzioni del database avrebbero saputo che 1 OR 1=1non è un valore letterale valido.

Quanto a htmlspecialchars(). Questo è un campo minato a sé stante.

C'è un vero problema in PHP in quanto ha un'intera selezione di diverse funzioni di escape relative a HTML e nessuna guida chiara su esattamente quali funzioni fanno cosa.

In primo luogo, se ti trovi all'interno di un tag HTML, sei davvero nei guai. Guarda a

echo '<img src= "' . htmlspecialchars($_GET['imagesrc']) . '" />';

Siamo già all'interno di un tag HTML, quindi non abbiamo bisogno di <o> per fare nulla di pericoloso. Il nostro vettore di attacco potrebbe esserejavascript:alert(document.cookie)

Ora appare l'HTML risultante

<img src= "javascript:alert(document.cookie)" />

L'attacco arriva dritto.

Peggiora. Perché? perché htmlspecialchars(se chiamato in questo modo) codifica solo virgolette doppie e non singole. Quindi se lo avessimo fatto

echo "<img src= '" . htmlspecialchars($_GET['imagesrc']) . ". />";

Il nostro malvagio aggressore ora può iniettare parametri completamente nuovi

pic.png' onclick='location.href=xxx' onmouseover='...

ci da

<img src='pic.png' onclick='location.href=xxx' onmouseover='...' />

In questi casi, non c'è nessuna bacchetta magica, devi solo santizzare l'input da solo. Se provi a filtrare i personaggi cattivi, fallirai sicuramente. Adotta un approccio da whitelist e lascia passare solo i caratteri che sono buoni. Guarda il cheat sheet XSS per esempi su come possono essere diversi i vettori

Anche se utilizzi htmlspecialchars($string)al di fuori dei tag HTML, sei comunque vulnerabile ai vettori di attacco con set di caratteri multibyte.

Il più efficace che puoi essere è usare una combinazione di mb_convert_encoding e htmlentities come segue.

$str = mb_convert_encoding($str, 'UTF-8', 'UTF-8');
$str = htmlentities($str, ENT_QUOTES, 'UTF-8');

Anche questo lascia IE6 vulnerabile, a causa del modo in cui gestisce UTF. Tuttavia, potresti ricorrere a una codifica più limitata, come ISO-8859-1, fino a quando l'utilizzo di IE6 non diminuisce.

Per uno studio più approfondito sui problemi multibyte, vedere https://stackoverflow.com/a/12118602/1820

Oltre all'eccellente risposta di Cheekysoft:

• Sì, ti terranno al sicuro, ma solo se vengono utilizzati in modo assolutamente corretto. Usali in modo errato e sarai comunque vulnerabile e potresti avere altri problemi (ad esempio il danneggiamento dei dati)
• Utilizzare invece query parametrizzate (come indicato sopra). È possibile utilizzarli tramite, ad esempio, PDO o tramite un wrapper come PEAR DB
• Assicurati che magic_quotes_gpc e magic_quotes_runtime siano sempre disattivati ​​e che non vengano mai attivati ​​accidentalmente, nemmeno brevemente. Si tratta di un tentativo precoce e profondamente fuorviante da parte degli sviluppatori di PHP di prevenire problemi di sicurezza (che distruggono i dati)

Non c'è davvero un proiettile d'argento per prevenire l'iniezione di HTML (es. Cross site scripting), ma potresti essere in grado di ottenerlo più facilmente se stai usando una libreria o un sistema di modelli per l'output di HTML. Leggi la documentazione per quello su come sfuggire alle cose in modo appropriato.

In HTML, è necessario eseguire l'escape delle cose in modo diverso a seconda del contesto. Ciò è particolarmente vero per le stringhe inserite in Javascript.

Sarei sicuramente d'accordo con i post sopra, ma ho una piccola cosa da aggiungere in risposta alla risposta di Cheekysoft, in particolare:

Quando si tratta di query di database, provare sempre a utilizzare query parametrizzate preparate. Le librerie mysqli e PDO supportano questo. Questo è infinitamente più sicuro rispetto all'utilizzo di funzioni di escape come mysql_real_escape_string.

Sì, mysql_real_escape_string è effettivamente solo una funzione di escape delle stringhe. Non è una bacchetta magica. Tutto ciò che farà è sfuggire a caratteri pericolosi in modo che possano essere usati in sicurezza in una singola stringa di query. Tuttavia, se non disinfetti in anticipo i tuoi input, sarai vulnerabile a determinati vettori di attacco.

Immagina il seguente SQL:

$ risultato = "SELEZIONA campi DALLA tabella WHERE id =" .mysql_real_escape_string ($ _ POST ['id']);

Dovresti essere in grado di vedere che questo è vulnerabile agli exploit. Immagina che il parametro id contenga il vettore di attacco comune:

1 OPPURE 1 = 1

Non ci sono caratteri rischiosi da codificare, quindi passerà direttamente attraverso il filtro di fuga. Lasciandoci:

SELEZIONA i campi DALLA tabella DOVE id = 1 O 1 = 1

Ho codificato una piccola funzione veloce che ho inserito nella mia classe di database che eliminerà tutto ciò che non è un numero. Usa preg_replace, quindi c'è probabilmente una funzione un po 'più ottimizzata, ma funziona in un pizzico ...

function Numbers($input) {
  $input = preg_replace("/[^0-9]/","", $input);
  if($input == '') $input = 0;
  return $input;
}

Quindi, invece di usare

$ risultato = "SELEZIONA i campi DALLA tabella WHERE id =" .mysqlrealescapestring ("1 OR 1 = 1");

io userei

$ risultato = "SELEZIONA campi dalla tabella WHERE id =" .Numeri ("1 OR 1 = 1");

e potrebbe eseguire la query in modo sicuro

SELEZIONA i campi DALLA tabella DOVE id = 111

Certo, questo gli ha semplicemente impedito di visualizzare la riga corretta, ma non penso che sia un grosso problema per chiunque stia cercando di iniettare sql nel tuo sito;)

Un pezzo importante di questo puzzle sono i contesti. Qualcuno che invia "1 OR 1 = 1" come ID non è un problema se citi ogni argomento nella tua query:

SELECT fields FROM table WHERE id='".mysql_real_escape_string($_GET['id'])."'"

Che si traduce in:

SELECT fields FROM table WHERE id='1 OR 1=1'

che è inefficace. Poiché esegui l'escape della stringa, l'input non può uscire dal contesto della stringa. L'ho testato fino alla versione 5.0.45 di MySQL e l'utilizzo di un contesto stringa per una colonna intera non causa alcun problema.

$result = "SELECT fields FROM table WHERE id = ".(INT) $_GET['id'];

Funziona bene, anche meglio su sistemi a 64 bit. Fai attenzione ai limiti del tuo sistema sull'indirizzamento di grandi numeri, ma per gli ID di database questo funziona alla grande il 99% delle volte.

Dovresti usare una singola funzione / metodo anche per pulire i tuoi valori. Anche se questa funzione è solo un wrapper per mysql_real_escape_string (). Perché? Perché un giorno, quando viene rilevato un exploit per il tuo metodo preferito di pulizia dei dati, devi aggiornarlo solo in un punto, piuttosto che trovare e sostituire a livello di sistema.

perché, oh PERCHÉ, non includeresti virgolette intorno all'input dell'utente nella tua istruzione sql? sembra abbastanza sciocco non farlo! includere le virgolette nella tua istruzione sql renderebbe "1 o 1 = 1" un tentativo infruttuoso, no?

quindi ora dirai "cosa succede se l'utente include una citazione (o virgolette doppie) nell'input?"

beh, soluzione facile per questo: basta rimuovere le virgolette inserite dall'utente. ad esempio: input =~ s/'//g;. ora, mi sembra comunque, che l'input dell'utente sarebbe protetto ...