Forum libero

Scritto da: ::1
> Scritto da:
> > Ai tempi in cui me n'ero occupato si fondeva con il problema dell'erronea trasmissione di certi caratteri da parte dei browser (un baco forse risalente a Mosaic) per cui conveniva trasformare in entità via Javascript tutti i caratteri non lower ASCII, e anche qualcuno lower ASCII, prima di trasmetterli al server.
>
> Succede ancora oggi con IE che non onora il page encoding quando invia i form, a meno che non gli infili tra i dati da inviare un carattere tipo snowman o pile of poo che non sta nelle tabelle caratteri non unicode.

È una brutta notizia ma una soluzione intelligente è fegarsene. Se un utente lamenta il baco dai comunque la colpa a Exploder, rispondi che prima o poi lo correggeranno, inviti a usare Firefox. Non mi metterei a riscrivere un programma per star dietro a Explorer.

> > Suppongo che oggi i browser trasmettano correttamente tutti i caratteri Unicode, e allora mi chiedo, come dev'essere fatta oggi questa igienizzazione? Col Viakal?
> >
> > Una volta che la stringa inserita in un campo INPUT o TEXTAREA o altro è ricevuta dal server, questo che deve fare per evitare iniezioni di codice o altri problemi? Convertire in entità i caratteri aventi un significato particolare in HTML, JS e PHP, e opzionalmente tutto ciò che eccede il lower ASCII per prevenire problemi di encoding?
>
> Il trasporto dal browser al server avviene solitamente mediante percent encoding fatta dal browser (enctype application/x-www-form-urlencoded). Devi trasportare la stringa ricevuta, opportunamente trattata dal framework server che si usa, possibilmente così com'è (non come sul fdt) e escapare l'output con le apposite funzioni. Se usi un db usa sempre i prepared statement. Non fidarti del client per niente che non sia il mero dato richiesto, abusa della sessione utente (praticamente tutti i framework web la mettono a disposizione). Le operazioni di scrittura non vanno fatte con metodo http POST (verificalo sempre) per evitare che un link malevolo possa eseguire operazioni non desiderate.
> Il tuo punto di partenza comunque è owasp top 10 per le vulnerabilità più diffuse e i rimedi da usare: https://www.owasp.org/index.php/Category:OWASP_Top...

Eeeh ma non devo farlo io. Nell'eBay Clone ho trovato dei bachi - qui ci sarebbe da aprire una lunga parentesi sul mio karma, se nel pagliaio c'è un ago che nessuno ha mai trovato, mi ci siedo e mi si pianta nel culo - e a questo punto ho tre possibilità: correggerlo io (gran perdita di tempo e grazia di Dio), pagare qualcuno per correggerlo (perdita di soldi) o, perché no, comunicare un elenco dei bachi agli sviluppatori. Dopo tutto si tratta di un programma ancora sviluppato attivamente, a differenza da altri concorrenti derivati dallo stesso script originario, correggere i bachi è anche nel loro interesse.

Uno di questi bachi è che se l'input contiene caratteri speciali, viene tagliato tutto dal primo di essi in poi, dannati anglosassoni che non pensano mai alle altre lingue. Nel segnalarglielo pensavo anche di unire un suggerimento su come corregerlo in modo che facciano le cose come si deve, ma prima devo avere io le idee chiare.