Queste due funzioni sono eccessive per la sanificazione?

Ad essere onesti, penso che l'autore di queste funzioni non abbia idea di cosa siano le iniezioni XSS e SQL o cosa faccia esattamente la funzione utilizzata.

Solo per citare due stranezze:

• Utilizzo di stripslashes dopo mysql_real_escape_string rimuove le barre aggiunte da mysql_real_escape_string .
• htmlentities sostituisce i chatacters < e > utilizzati in strip_tags per identificare i tag.

Inoltre:in generale, le funzioni che proteggono da XSS non sono adatte a proteggere da iniezioni SQL e viceversa. Perché ogni lingua e contesto ha i suoi caratteri speciali che devono essere curati.

Il mio consiglio è di imparare perché e come è possibile l'iniezione di codice e come proteggersi da esso. Impara le lingue con cui stai lavorando, in particolare i caratteri speciali e come evitarli.

Modifica Ecco qualche esempio (probabilmente strano):immagina di consentire ai tuoi utenti di inserire un valore che dovrebbe essere utilizzato come segmento di percorso in un URI che usi in un codice JavaScript in un onclick valore dell'attributo. Quindi il contesto linguistico è simile a questo:

• Valore attributo HTML
  • Stringa JavaScript
    • Segmento del percorso URI

E per renderlo più divertente:stai memorizzando questo valore di input in un database.

Ora per memorizzare correttamente questo valore di input nel tuo database, devi solo utilizzare una codifica adeguata per il contesto in cui stai per inserire quel valore nel linguaggio del tuo database (es. SQL); il resto non importa (ancora). Poiché si desidera inserirlo in una dichiarazione di stringa SQL, i caratteri speciali contestuali sono i caratteri che consentono di modificare quel contesto. Per quanto riguarda le dichiarazioni di stringa, questi caratteri sono (soprattutto) il " , ' e \ caratteri di cui è necessario eseguire l'escape. Ma come già affermato, le dichiarazioni preparate fanno tutto ciò che funziona per te, quindi usale.

Ora che hai il valore nel tuo database, vogliamo emetterli correttamente. Qui procediamo dal contesto più interno a quello più esterno e applichiamo la codifica corretta in ogni contesto:

• Per il segmento del percorso URI contesto dobbiamo sfuggire (almeno) a tutti quei caratteri che ci permettono di cambiare quel contesto; in questo caso / (lascia il segmento di percorso corrente), ? e # (entrambi lasciano il contesto del percorso URI). Possiamo usare rawurlencode per questo.
• Per la stringa JavaScript contesto dobbiamo occuparci di " , ' e \ . Possiamo usare json_encode per questo (se disponibile).
• Per il valore dell'attributo HTML dobbiamo occuparci di & , " , ' e < . Possiamo usare htmlspecialchars per questo.

Ora tutto insieme:

'… onclick="'.htmlspecialchars('window.open("http://example.com/'.json_encode(rawurlencode($row['user-input'])).'")').'" …'

Ora se $row['user-input'] è "bar/baz" l'output è:

… onclick="window.open("http://example.com/"%22bar%2Fbaz%22"")" …

Ma usare tutte queste funzioni in questi contesti non è eccessivo. Perché sebbene i contesti possano avere caratteri speciali simili, hanno sequenze di escape diverse. L'URI ha la cosiddetta codifica percentuale, JavaScript ha sequenze di escape come \" e HTML ha riferimenti a caratteri come " . E non usare solo una di queste funzioni permetterà di rompere il contesto.