Prevenzione delle iniezioni JavaScript in un'applicazione Web PHP

Question

Quali sono le misure necessarie per impedire o interrompere l'inattività di JavaScript in un'applicazione Web PHP in modo che non vengano fornite informazioni riservate (best practice in PHP, HTML/XHTML e JavaScript)?

Answer 1

Un buon primo passo è applicare i metodi elencati nello question Gert G linked. Ciò riguarda in particolare la varietà di funzioni che possono essere utilizzati in diverse situazioni di purificare ingresso, tra mysql_real_escape_string, htmlentities(), htmlspecialchars(), strip_tags() e addslashes()

Un modo migliore, quando possibile, è quello di evitare di inserire input dell'utente direttamente nel database . Impiegare whitelist input validation: in qualsiasi situazione in cui si dispone solo di una gamma limitata di opzioni, scegliere tra i valori codificati per l'inserimento, piuttosto che prendere l'input da qualsiasi modulo sul lato client. Fondamentalmente, questo significa avere solo determinati valori che accetti, invece di cercare di eliminare/contrastare l'input malevolo/mal formato/malizioso.

Ad esempio: Se si dispone di un modulo con un menu a discesa per gli elementi, non utilizzare l'input da questo menu a discesa per l'inserimento. Ricorda che un client malintenzionato può modificare le informazioni inviate con l'invio del modulo, anche se pensi che abbiano solo opzioni limitate. Invece, fare in modo che il menu a discesa faccia riferimento a un indice in un array nel codice lato server. Quindi utilizzare tale matrice per scegliere cosa inserire. In questo modo, anche se un utente malintenzionato tenta di inviarti codice dannoso, non colpisce mai il tuo database.

Ovviamente, questo non funziona per applicazioni free-form come forum o blog. Per quelli, devi ricorrere alle tecniche del "primo passo". Tuttavia, esiste un'ampia gamma di opzioni che possono essere migliorate tramite la convalida dell'input di whitelist.

È inoltre possibile utilizzare parameterized queries (ovvero istruzioni preparate con variabili di collegamento) per le interazioni sql ove possibile. Questo dirà al server del database che tutto l'input è semplicemente un valore, quindi attenua molti potenziali problemi dagli attacchi di iniezione. In molte situazioni, questo può persino coprire applicazioni in forma libera.

Answer 2

Se il tuo non passare tutto ciò che deve essere formattato come HTML quindi utilizzare:

strip_tags() <- Eliminates any suspicious html 

e quindi eseguire le seguenti operazioni per pulire prima di salvare il db

mysql_real_escape_string() 

Se l'ajax è il risparmio l'utente ha inserito html tramite una casella di testo o wysiwyg, quindi cerca di utilizzare HTMLPurifier per rimuovere javascript ma consentire i tag html.

Answer 3

Trattare qualsiasi valore emesso in html con htmlspecialchars() per predefinito.

L'unica scusa per non utilizzare htmlspecialchars() è quando è necessario eseguire l'output su una stringa html che contiene esso stesso html. In questo caso devi essere sicuro che questa stringa provenga da una fonte completamente sicura. Se non si ha tale confidenza, è necessario passarlo attraverso il filtro html della lista bianca che consente solo un insieme limitato di tag, attributi e valori di attributi. Dovresti prestare particolare attenzione ai valori degli attributi. Non si dovrebbe mai permettere che tutto vada come valore di attributo, in particolare per attributi come src, hef, style.

Dovresti conoscere tutti i punti della tua webapp dove esporti qualcosa in html senza usare htmspeciachars(), assicurati di aver davvero bisogno di quei posti e di essere consapevole che, nonostante tutta la tua sicurezza, quei luoghi sono potenziali vulnerabilità.

Se state pensando che si tratti di troppa cautela: "Perché ho bisogno di htmlspecialchar() questa variabile che so che contiene solo numeri interi e perde tutti i preziosi cicli della CPU?"

Ricorda questo: non sai, pensi solo di sapere, i cicli della CPU sono la cosa più economica del mondo e quasi tutti saranno sprecati aspettando il database o il filesystem o persino l'accesso alla memoria.

Inoltre, non utilizzare mai filtri html della lista nera. Youtube ha commesso questo errore e qualcuno all'improvviso ha scoperto che solo il primo <script> viene rimosso e se inserisci il secondo nel commento puoi inserire qualsiasi Javascript nel browser dei visitatori.

Analogamente per evitare che le Iniezioni SQL trattino con mysql_real_escape_string() tutti i valori che incollate alla query SQL, o meglio ancora usano le istruzioni Preparate PDO.

Answer 4

Non sono completamente d'accordo con le altre risposte fornite, quindi posterò i miei consigli.

Letture consigliate XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

iniezione Html: Ogni volta che la visualizzazione di qualsiasi contenuto inviato dall'utente, occorre opportunamente ripulito con htmlspecialchars o htmlentities quando si specifica ENT_QUOTES se utilizzato all'interno di apici singoli. Non raccomanderei mai di incapsulare tra virgolette singole e incapsulare sempre gli attributi tra virgolette (non li omettere). Questo vale per le cose come:

<input value="<?php echo htmlspecialchars($var); ?>" /> 
<textarea><?php echo htmlspecialchars($var); ?></textarea> 
<p><?php echo htmlspecialchars($var); ?></p> 
<img width="<?php echo htmlspecialchars($var); ?>" /> 

Javascript Injection: Si tratta di buone pratiche (ma non sempre pratico) a mai i contenuti degli utenti eco in eventi e javascript. Tuttavia, se lo fai ci sono alcune cose che possono essere fatte per ridurre il rischio. Passa solo ID intero. Se si richiede qualcosa come un identificatore di tipo, quindi utilizzare una whitelist e/o un controllo condizionale in anticipo prima dell'output. È possibile forzare il contenuto utente in alfanumerico solo se appropriato; preg_replace("/[^A-Za-z0-9]/", '', $string); ma stai molto attento a ciò che permetti qui. Includere il contenuto solo quando è racchiuso tra virgolette e notare che htmlspecialchars/htmlentities non ti protegge qui. Sarà interpretato in fase di esecuzione anche se è stato tradotto in entità html. Questo vale per cose come:

<a href="www.stackoverlow.com/?id=<?php echo (int)$id; ?>">Click</a> 
href, src, style, onClick, etc. 

Non eco alcun contenuto utente in altri settori, come il corpo del tag script ecc se non è stato costretto a un int o qualche altro set di caratteri molto molto limitato (se Sai cosa stai facendo).

SQL Injection: Usa Prepared statements, contenuti creati dagli utenti si legano a loro, e non inserire direttamente i contenuti degli utenti nella query. Consiglierei di creare una classe per le istruzioni preparate con le funzioni di supporto per i diversi tipi di istruzione di base (e mentre sull'argomento, funzionalizzare tutte le istruzioni del database). Se si sceglie di non utilizzare istruzioni preparate, utilizzare mysql_real_escape_string() o simile (non addslashes()). Convalidare il contenuto quando possibile prima di archiviarlo nel database, ad esempio forzare/verificare il tipo di dati integer, i controlli condizionali sui tipi, ecc. Utilizzare tipi di colonne e lunghezze appropriate del database. Ricorda che l'obiettivo principale qui è quello di prevenire l'iniezione di sql ma puoi anche fare la protezione dell'iniezione html/javascript qui.

Altre risorse Ho fatto qualche ricerca online nella speranza di trovare una soluzione semplice già disponibile pubblicamente. Ho trovato ESAPI OWASP ma sembra abbastanza datato. I collegamenti alla versione php sono suddivisi in diversi punti. Credo di averlo trovato qui; ESAPI PHP ma ancora una volta è piuttosto datato e non così semplice come speravo. Potresti trovarlo utile comunque.

Tutto sommato, non dare per scontato che tu sia protetto come l'utilizzo di HTML in un attributo onClick. È necessario utilizzare lo strumento giusto nella posizione corretta ed evitare di fare le cose nella posizione sbagliata.