Qual è la differenza tra il filtro esc_html e il filtro attributo_escape?


8

Qual è la differenza esatta tra esc_htmle attribute_escapefilter?

esc_html()usi esc_html filtere esc_attr()usi attribute_escape filter. Entrambi codifica <> & "'(minore di, maggiore di, e commerciale, virgolette doppie, virgolette singole).

Sono interessato a sapere cosa li rende esattamente diversi in termini di sicurezza (fuga).


beh, se non fossero diversi non ci sarebbe bisogno di avere entrambi ... la domanda dell'IMO non è chiara, è come chiedere qual è la differenza tra i filtri the_content e the_excerpt
Mark Kaplun,

1
Penso che sia quello che sta chiedendo, come sono diversi e perché?
Tom J Nowell

@TomJNowell, bene uno è chiamato per sfuggire agli attributi e l'altro per sfuggire all'HTML generale. Questo spiega il perché, e soprattutto spiega anche il come;) Dove dovrebbe iniziare una risposta qui, spiegando la differenza tra i caratteri consentiti negli attributi e HTML generale? questo suona un po 'troppo semplice (ma potrebbe essere quello che l'OP chiede su suppongo)
Mark Kaplun

2
Sarebbe bello, ma un esempio di qualcosa esc_attrche sfugge che esc_htmlnon sarebbe utile, dopotutto perché non usarlo esc_htmlovunque? Se per te è ovvio, potrebbe non sembrare una buona domanda, ma non è ovvio per chi si chiede come queste 2 funzioni differiscono dato che entrambi sfuggono ai personaggi previsti
Tom J Nowell

Risposte:


8

Sembrerebbe che fuori dalla scatola non ci sia differenza

function esc_html( $text ) {
    $safe_text = wp_check_invalid_utf8( $text );
    $safe_text = _wp_specialchars( $safe_text, ENT_QUOTES );
    /**
     * Filters a string cleaned and escaped for output in HTML.
     *
     * Text passed to esc_html() is stripped of invalid or special characters
     * before output.
     *
     * @since 2.8.0
     *
     * @param string $safe_text The text after it has been escaped.
     * @param string $text      The text prior to being escaped.
     */
    return apply_filters( 'esc_html', $safe_text, $text );
}
function esc_attr( $text ) {
    $safe_text = wp_check_invalid_utf8( $text );
    $safe_text = _wp_specialchars( $safe_text, ENT_QUOTES );
    /**
     * Filters a string cleaned and escaped for output in an HTML attribute.
     *
     * Text passed to esc_attr() is stripped of invalid or special characters
     * before output.
     *
     * @since 2.0.6
     *
     * @param string $safe_text The text after it has been escaped.
     * @param string $text      The text prior to being escaped.
     */
    return apply_filters( 'attribute_escape', $safe_text, $text );
}

L'unica differenza tra le 2 funzioni è il filtro applicato alla fine. WordPress non aggiunge nulla a questi filtri, quindi in un'installazione WP standard non sono operazioni. Sono forniti nel caso limite che qualcuno potrebbe averne bisogno.

Domande e risposte rapide

Quindi per impostazione predefinita sono identici?

Sì! Le funzioni esc_attre esc_htmlhanno la stessa implementazione

I filtri sono identici?

L'unica differenza è che hanno nomi diversi, funzionano allo stesso modo, sono usati allo stesso modo e nessuno dei due filtri è usato nel core.

I filtri fanno qualcosa?

No! Tutte le fughe vengono eseguite nella funzione quando wp_check_invalid_utf8e _wp_specialcharsvengono chiamate.

I filtri non eseguono l'escaping, sono un'opportunità per i plug-in di eseguire controlli ed elaborazioni aggiuntivi.

Ci sono casi limite?

Solo se usi i filtri, supponi di esserti collegato esc_htmlma non attribute_escapeviceversa, o viceversa. Per un'installazione WP standard, le 2 funzioni sono identiche, senza alcuna differenza.

Perché attribute_escapee no esc_attr?

Compatibilità con le versioni precedenti. C'era una attribute_escapefunzione, che ora è contrassegnata come obsoleta dopo l' esc_aggiunta delle funzioni di stile.

Perché dovrei usare questi filtri?

¯\_(ツ)_/¯questa sarebbe una situazione rara. Alcune persone potrebbero abusarne allo stesso modo in cui le API di traduzione vengono abusate per cercare di sostituire il testo. Questa è già una cattiva pratica poiché quei filtri vengono chiamati molto una piccola perdita di velocità viene ingrandita migliaia di volte

Ma considera che se non stai attento potresti compromettere la sicurezza di queste funzioni annullando l'escape che hanno aggiunto o aggiungendo contenuto senza escape alla fine. Per tale motivo i filtri sono pericolosi.

Devo preoccuparmi di questo?

No. Devi solo preoccuparti se hai usato quei filtri, che da soli avrebbero dovuto innescare enormi allarmi rossi che qualcosa nel tuo sviluppo è andato seriamente storto.

Le funzioni esc_attre esc_htmlsono sicure da usare e sfuggono al contenuto. Hai un obbligo etico e morale di usarli se apprezzi la sicurezza del tuo codice

Questo significa che dovrei semplicemente usare esc_html?

No, fuggire significa stabilire le aspettative. Se ti aspetti un attributo, usa esc_attr. Solo perché è funzionalmente lo stesso al momento, non significa che non cambierà in futuro con una versione di sicurezza


Grazie per la risposta. Forse ho bisogno di riformulare la mia domanda. Sono più interessato a sapere se c'è qualche differenza nell'implementazione di base dei due filtri sopra menzionati. Questo ci aiuterebbe davvero (sviluppatori) a sapere come funziona la fuga negli attributi e nell'HTML.
Djadmin,

Quei filtri non sono usati da Core, sono forniti per i plugin in caso di necessità. Consiglio vivamente di non usarli per motivi di sicurezza
Tom J Nowell

"I filtri esc_html e Attribute_escape sono quindi molto pericolosi." Non capisco davvero questo punto. Se non lo utilizziamo, come dovremmo evitare gli input dell'utente per impedire XSS?
Djadmin,

Come hai detto, passano attraverso un filtro prima di uscire. La mia domanda originale è come questi due filtri differiscono in termini di implementazione. Credo che ci sarebbe un caso limite che il esc_htmlfiltro fuoriesce e il attribute_escapefiltro non fa o viceversa.
Djadmin,

Non lo fanno. I filtri sono forniti per codice di terze parti e non sono utilizzati da Core. Il core non si aggancia ai filtri, né fa nulla con essi. Quei casi limite dovrebbero essere scritti da uno sviluppatore di temi o plugin, a quel punto sarebbe ovvio dato che saresti la persona che lo ha scritto
Tom J Nowell
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.