Si può solo array_map
strip_tags
-$_POST
, ma è molto più bello di scrivere una funzione personalizzata per ottenere dati da esso:
function post_data($name) {
global $post_cache;
if (in_array($name, $post_cache)) {
return $post_cache[$name];
}
$val = $_POST[$name];
if (is_string($val)) {
$val = strip_tags($val);
} else if (is_array($val)) {
$val = array_map('strip_tags', $val);
}
$post_cache[$name] = $val;
return $val;
}
Questo renderà il vostro codice più leggibile (altri che cercano in essa si assume, di norma che $_POST['foo']
è il dato nel campo modulo foo
, non qualcosa che è già stato preelaborato, non causerà problemi con plug-in o librerie che tentano di accedere direttamente a $ _POST, rende più facile aggiungere ulteriore logica alla pre-elaborazione $_POST
(unescape quando magic quotes sono abilitati è uno comune) senza cacciare tutto il posto s nel tuo codice in cui hai usato i dati POST e ti eviti da enormi mal di testa quando ti accorgi che ci sono alcuni campi POST in cui hai bisogno di tag HTML. In generale, è una pessima idea cambiare direttamente qualsiasi superglobale.
Inoltre, è meglio disinfettare i dati in uscita, non in ingresso. usi differenti richiedono metodi diversi, per esempio, se si utilizza
<div class="user_photo">
<img src="<?php echo photo_path($user_id) ?>" alt="<?php echo $user_name ?>" />
</div>
poi $user_name
è un vettore di attacco XSS, e strip_tags
non aiuta contro di essa a tutti; avresti bisogno di htmlspecialchars. Se i dati dell'utente vengono utilizzati come URL, è necessario un altro metodo per difendersi dagli URL javascript:
e così via.
Impressionante.Questo e 'esattamente quello che stavo cercando. –
Questo non riuscirà a proteggere da XSS quando ci sono campi modulo con nomi come 'foo [bar]' o 'foo []' che PHP converte automaticamente in array. – Tgr
@Tgr: sì, questo fallirà assolutamente come hai detto tu, ma penso che abbia avuto l'idea di personalizzare secondo ciò di cui ha bisogno – w00d