Lo scopo di sfuggire alle entità html

Qualsiasi scanner di analisi statica decente non segnalerebbe una vulnerabilità se stavi memorizzando codice HTML grezzo nel tuo database - dopo tutto, è solo una stringa.

Le sequenze di stringhe diventano pericolose solo quando passano attraverso una "funzione sink".

Ad esempio, <script> è completamente sicuro da memorizzare nel tuo database. Infatti lo è anche Robert'); DROP TABLE Students;-- .

Quest'ultimo è pericoloso solo quando viene passato da una variabile stringa e concatenato a una query codificata nell'applicazione perché l'intera stringa viene passata al server di database e non conosce la differenza tra la query e i dati. Questo è il motivo per cui dovresti utilizzare le query parametrizzate per passare i dati al tuo database - quindi il DB stesso sa cosa interpretare come dati strongmente tipizzati e cosa interpretare come il costrutto della query stesso.

Quando si esegue l'output sul browser, è qui che è necessario codificare come appropriato. Solitamente si uscirà in formato HTML, quindi è necessario codificare HTML ( & diventa & come dici tu). Se stai inviando a JSON o JavaScript (non è un campo minato), dovresti invece emettere il testo con la codifica di entità esadecimale ( \x38 ).

Se hai intenzione di mantenere quei caratteri, assicurati di aver usato variabili di binding (o istruzioni preparate) per persisterli.

Dovresti anche aggiungere la codifica HTML quando mostri le informazioni sulla tua interfaccia utente.

Se puoi evitare di memorizzare tali personaggi per i motivi che hai menzionato (e altri), questo è il meglio per te. Tuttavia, se sei costretto a considerare il tuo modello di business hai ancora un'opzione: indipendentemente dal linguaggio di programmazione che stai usando, puoi sempre fare affidamento sul concetto di query parametrizzate per raggiungere questo obiettivo. In questo modo prevedi iniezioni SQL .