Quali caratteri Unicode (controllo) dovrebbero accettare (non) le app Web?

Question

Quali caratteri Unicode (controllo) dovrebbero accettare (non) le app Web?

#1 da (2 voti)
#2 da (2 voti)

3

QUESTO NON E 'SULLA XSS

Minaccia: Mallory immette i caratteri di controllo in un campo di testo di un'applicazione Web pubblica che altri utenti potrebbero utilizzare in un programma terminale (tramite copia + incolla o eseguendo uno script).

Un'altra minaccia è che un utente entra in un dominio di phishing (che viene visualizzato in seguito) e utilizza un carattere di controllo RTL in modo che appaia non-fasullo.

http://www.‮moc.lapyap

in realtà è http://www.\u202Emoc.lapyap

(Un altro motivo minore è che Postgres barfs se un utente immette il carattere null).

Non sto parlando di una normale iniezione XSS che esegue javascript. Sto usando JSoup per prevenire XSS e funziona bene, ma non blocca i caratteri di controllo (a meno che non capiti di creare un XSS)

Ho visto OWASP ESAPI Validator ma convalida solo i caratteri ASCII (ex nel metodo getValidPrintable ()).

Sembra che non ci siano buoni motivi per accettare:

\ u0000 - \ u001F (ad eccezione del ritorno a capo, avanzamento riga, scheda orizzontale)
\ u007F - \ u009F
\ U202E

Di quali altri dovrei preoccuparmi?

Escaping / encoding on save è errato come con XSS.

web-application

posta Neil McGuigan 08.04.2015 - 00:07

fonte

2 risposte

2

Accettali tutti, solo codificali in un formato sicuro al momento del ricevimento. Inoltre, se mi stai ponendo questa domanda, prima di procedere dovrei prima consultare una libreria di codifica per un'implementazione di base. La codifica può essere più complicata di quanto pensi, e vedo che le implementazioni personalizzate falliscono sempre.

In molti casi, non è il problema stesso a essere problematico, ma come si inserisce in un gruppo di personaggi.

Quindi mi asterrò dal darti una lista, in quanto estesa, e non ti condurrò al successo. Se questo è per la produzione, utilizzare un codice di base revisionato da peer per eseguire il filtraggio e la codifica. Se questo è allo scopo di scrivere una biblioteca, studia una di quelle basi di codice revisionate da colleghi.

Per essere chiari: Sulla via dei dati dovrebbe essere disinfettato, per prevenire l'iniezione (assicurati di utilizzare anche le query parametrizzate). Sulla via d'uscita i dati dovrebbero essere codificati, per prevenire l'XSS.

La maggior parte dei moderni Web Framework ha una classe di encoder decente. Se usi Java controlla l'implementazione che OWASP fornisce: link

risposta data 08.04.2015 - 00:25

fonte

Leggi altre domande sui tag web-application

È importante usare un hash lento in htpasswd? Documento di protocollo SSL "Indagini su SSL"

score 2 · Accepted Answer

Sarà molto difficile mettere in blacklist tutti i caratteri cattivi conosciuti a seconda del sistema in arrivo, dell'elaborazione, dei cambiamenti di formato (HTML, XML, JSON, ecc. / ASCII, ebcdic, ecc.). Mentre ci sono probabilmente alcuni casi in cui hai veramente bisogno di campi di input "aperti", sarebbe meglio definire i caratteri consentiti / autorizzati sulla base del campo di input.

Ad esempio, se chiedi un nome in inglese / romanizzato accetti solo azAZ_ o qualcosa di simile. Se hai a che fare con problemi multilingue, nella maggior parte dei casi devi aspettarti una sola lingua alla volta e potresti scegliere una lingua di input e quindi filtrare i caratteri richiesti in quella lingua nel contesto specificato.

Quando osservi le regole aziendali per la maggior parte delle app, dovrebbero esserci pochi casi in cui è necessario consentire set completi e 10 lingue contemporaneamente. Permettere il pieno inserimento potrebbe non essere il miglior bilanciamento di funzionalità con sicurezza a seconda delle tue esigenze.

Naturalmente, ci sono ancora casi come app di chat e forum generali, quindi è ancora una domanda valida per avere determinate blacklist o cattive combinazioni. Non sono a conoscenza di un elenco principale, quindi lo lascerò ad un'altra risposta. I personaggi di controllo sono la prima cosa che mi viene in mente e che sono poco utili per la maggior parte degli utenti finali.

Le seguenti letture possono essere utili:

Immaginerei che alcune soluzioni dipenderanno dai diversi sistemi e applicazioni nella tua pipeline di elaborazione e da cosa supportano, e come i dati vengono convertiti, potrebbe non esserci una risposta o un approccio comune applicabile globalmente.