Sebbene mysql_escape_string() sia un buon metodo per prevenire l'iniezione SQL, le query parametrizzate sono un approccio molto migliore. mysql_escape_string() non è ancora perfetto; ad esempio il seguente è vulnerabile all'iniezione SQL:
$q="select * from user where uid=".mysql_real_escape_string($_GET[uid]);
Il PoC è semplice:
http://localhost/vuln.php?uid=sleep(30)
Utilizza query con parametri!
htmlentities() o htmlspecialchars() impedirà alcuni tipi di XSS. Non impediranno XSS negli eventi DOM . Questo metodo non impedirà ad esempio di iniettare eventi: value='junk' onclick=alert(/xss/) . htmlspecialchars($var,ENT_QUOTES) è un po 'meglio, perché impedisce l'iniezione di eventi DOM, ma puoi comunque dirottare un evento (vedi il post del blog "è un evento DOM").
Quindi queste due funzioni attenueranno parzialmente due vulnerabilità di un paio di migliaia . Per chiamare alcuni dei principali criminali che non saranno mitigati da mysql_real_escape_string() o htmlentites() abbiamo: Directory traversal (e LFI / RFI per PHP), LDAP injection, XPATH injection, HTTP Response Splitting, Log file injection .. . e l'elenco continua.
L'input di escape non ha nulla a che fare con la rimozione di "caratteri vietati". Riguarda la conversione di caratteri di escape (o sequenze di caratteri) nel loro " carattere letterale " in modo tale che i dati controllati dagli aggressori siano ancora interpretati come dati e non come codice eseguibile.