Lista bianca o sanificazione della lista nera per input internazionali?

Ecco perché esiste la classe di caratteri [[: alnum:]]; include i caratteri che sono considerati caratteri alfanumerici validi nelle impostazioni internazionali attualmente attive. Ovviamente, questo non funziona bene su un server web negli Stati Uniti quando qualcuno in Egitto sta tentando di fornire input tramite un modulo e non funziona con la punteggiatura. Ma non include anche spazi, e questo potrebbe essere completamente irrilevante.

--- --- Modifica Basandosi sulla risposta di Marco qui sotto e usando come riferimento il link , si potrebbe anche usare [\p{L}\p{N}] invece del carattere di alnum class nelle più comuni implementazioni regexp per riconoscere "tutti" lettere / numeri unicode in tutte le versioni locali note al motore regex in uso. La scelta dipende fondamentalmente dal fatto che l'applicazione che esegue il confronto sia in grado di sapere da quale ambiente l'input proviene o meno. E, naturalmente, se ci si aspetta che l'input sia composto da lettere e numeri o qualcos'altro (i nomi propri a volte contengono segni di punteggiatura, per esempio). :) --- --- Modifica

Per rispondere più direttamente alla domanda - sì, una lista bianca è sempre preferibile. Non è sempre pratico, però. Solo chi ha familiarità con l'applicazione specifica può effettuare chiamate su ciò che è effettivamente pratico.

Supponendo che lo stai chiedendo nel contesto dello sviluppo Web ...

È possibile rilevare set di caratteri appropriati con una semplice conferma delle espressioni regolari. Tuttavia, potresti anche essere vittima di un teatro di sicurezza: l'igienizzazione dell'input è non la risposta.

Se si sta tentando di convalidare per impostazioni locali specifiche e non si desidera accettare altre impostazioni locali, è possibile scegliere quelle specifiche utilizzando Regex. Ecco un esempio:

1. \p{InHan} per caratteri cinesi.
2. \p{InArabic} per l'arabo
3. \p{InThai} per Thai

Tuttavia, sono con O'Rooney qui: dovresti accettare tutto (finché è convalidato: length, null, format, whitelist) e usare Prepared Statements con output sanitation .

Avvertenze sulla whitelist basata sulla lingua

Se insisti ad andare con una lista bianca basata su unicode, tieni presente che devi comunque consentire [a-zA-Z0-9] , anche se stai accettando solo altre impostazioni locali. Sull'Internet cinese, le persone scrivono spesso con lettere inglesi. Ad esempio, possono tentare di eludere la censura tramite caratteri abbreviati (solo testo su wikipedia, ma comunque NSFW ). Molte persone usano anche pinyin e numeri romani.

Puoi anche utilizzare intervalli Unicode , ma quando si utilizzano ideogrammi combinati / set di lingue come CJK (cinese, giapponese e coreano, credo che \p{IsHan} sia CJK ), si verificheranno molti problemi di convalida.

Se vuoi escludere per lingua, avrai problemi con questo concetto quando ti aspetti input giapponesi, ma ottieni input cinesi, o viceversa. Lo stesso concetto si applica con il coreano contro il cinese o il giapponese. Dovrai trovare gli intervalli di unicode appropriati, ma nota che alcune lingue si sovrappongono occasionalmente: cinese ( Hanzi ) e giapponese (< a href="https://en.wikipedia.org/wiki/Kanji"> Kanji ) condividi alcuni personaggi .

Dato che sei preoccupato per gli input accettati, sembra che tu stia cercando un risanamento dei dati. Questo è l'approccio sbagliato. Dovresti non essere input "disinfettanti" che va in un database. La whitelist va bene (valori accettabili, ad esempio).

Gli elementi di Sanitizzazione e Validazione sono due cose diverse. Qual è la differenza?

1. Input di disinfezione potrebbe assomigliare a questo: stripApostrophesFromString(input);
2. La convalida dell'input potrebbe essere simile a questa: if (input != null && input.Length == acceptableNumber && regexFormatIsValid(input) && isWithinAcceptableRanges(input)) { } else { }

Per la convalida del set di caratteri, una variazione delle espressioni regolari elencate può essere sufficiente, ma non convalida la lunghezza, il formato, ecc. Se sei preoccupato dell'iniezione SQL (e dovresti be) , dovresti utilizzare prepared statements con output sanitation .

Il risanamento dell'output consiste essenzialmente nel convertire i caratteri non validi, come i tag di script, nella loro equivalente entità HTML. Ad esempio, < diventa < e > diventa > .

La nostra risposta è che per un'applicazione veramente internazionale, su input generali come i nomi delle persone, dovresti accettare tutto e codificarlo in fase di visualizzazione. Ammetto che (in una certa misura) passa il problema al ragazzo che scrive l'algoritmo Encode.

Tuttavia, se si dispone di un input che è una cosa specifica, ad esempio una targa del veicolo o un codice di identificazione aziendale, è necessario convalidarlo rispetto a tali regole, indipendentemente dal fatto che si tratti di un'applicazione internazionale. Ancora una volta, un'ulteriore avvertenza è che tali regole potrebbero essere ancora difficili da definire, ad esempio i simboli delle targhe variano a seconda del paese.

(Modifica) Perché preferisco la codifica rispetto alla convalida:

Al momento della convalida, i dati potrebbero potenzialmente andare ovunque: un file di testo CSV, una query SQL, una pagina Web, un'impostazione di configurazione. Non sai, e non puoi sapere, quali sono i personaggi rischiosi.

Al momento della codifica, per definizione sai dove stanno andando i dati, quindi puoi codificare definitivamente i personaggi rischiosi.