2010-08-09 11 views
7

Come si evitano gli attacchi di script cross-site?Come evitare "Cross-Site Script Attacks"

Cross-site script attacks (o cross-site scripting) è se per esempio avete un libro degli ospiti nella tua home page e un post client un codice javascript che fx reindirizza ad un altro sito web o invia i cookie in una e-mail a un utente malintenzionato o potrebbe essere un sacco di altre cose che possono rivelarsi molto dannose per te e le persone che visitano la tua pagina.

Sono sicuro che può essere fatto fx. in PHP di moduli di convalida ma non ho esperienza sufficiente per fx. divieto javascript o altre cose che possono farti del male.

Spero che tu capisca la mia domanda e che tu sia in grado di aiutarmi.

+0

Framework di destinazione? PHP? – Arthur

+0

Ci sono opzioni per qualsiasi lingua/struttura/ecc. Otterrai risposte più specifiche, come htmlencode, se fornisci ulteriori informazioni sulla configurazione. (Pila). – Tobiasopdenbrouw

+0

Hai ragione, Tobiasopdenbrouw, ma in realtà era più simile a una domanda generale che altre persone potrebbero anche ottenere da :) – Latze

risposta

12

Sono sicuro che può essere fatto fx. in PHP convalidando i moduli

Non proprio. Lo stadio di input è completamente nel posto sbagliato per affrontare i problemi XSS.

Se l'utente digita, ad esempio <script>alert(document.cookie)</script> in un input, non c'è nulla di sbagliato in sé stesso. L'ho appena fatto in questo messaggio, e se StackOverflow non lo permetteva avremmo grandi difficoltà a parlare di JavaScript sul sito! Nella maggior parte dei casi, si desidera consentire qualsiasi input (*), in modo che gli utenti possano utilizzare un carattere < per significare letteralmente un segno di minore importanza.

Il fatto è che quando si scrive del testo in una pagina HTML, è necessario eseguirlo correttamente per il contesto in cui si trova. Per PHP, questo significa che utilizzando htmlspecialchars() nella fase uscita:

<p> Hello, <?php echo htmlspecialchars($name); ?>! </p> 

[PHP suggerimento: è possibile definire te stesso una funzione con un nome più breve per fare echo htmlspecialchars, poiché questo è un bel po 'di digitare per fare ogni tempo in cui desideri inserire una variabile in HTML.]

Ciò è necessario indipendentemente da dove proviene il testo, indipendentemente dal fatto che provenga da un modulo inviato dall'utente o meno. Anche se i dati inviati dagli utenti sono il posto più pericoloso per dimenticare la codifica HTML, il punto è che stai prendendo una stringa in un formato (testo normale) e inserendola in un contesto in un altro formato (HTML).Ogni volta che lanci il testo in un contesto diverso, avrai bisogno di uno schema di codifica/escape appropriato per quel contesto.

Ad esempio, se si inserisce del testo in una stringa letterale JavaScript, è necessario sfuggire al carattere di citazione, alla barra rovesciata e alla nuova riga. Se si inserisce del testo in un componente di query in un URL, sarà necessario convertire la maggior parte dei non alfanumerici nelle sequenze %xx. Ogni contesto ha le sue regole; devi sapere quale è la funzione giusta per ogni contesto nella lingua/struttura scelta. Non è possibile risolvere questi problemi tagliando gli invii di form nella fase di input, anche se molti programmatori PHP ingenui provano, ed è per questo che così tante app rovinano il tuo input nei casi d'angolo e non sono ancora sicuri.

(*: beh, quasi. C'è un argomento ragionevole per filtrare i caratteri di controllo ASCII dal testo inviato.È molto improbabile che consentirebbe loro di fare qualcosa di buono. Inoltre, naturalmente, si avranno convalide specifiche dell'applicazione che vorrai fare, ad esempio assicurarti che un campo di posta elettronica assomigli ad un indirizzo di posta elettronica o che i numeri siano effettivamente numerici, ma questo non è qualcosa che può essere applicato a tutti gli input per tirarti fuori dai guai.

9

Gli attacchi XSS (cross-site scripting) si verificano quando un server accetta l'input dal client e quindi scrive ciecamente quell'input alla pagina. La maggior parte della protezione da questi attacchi comporta la fuga dell'output, quindi Javascript si trasforma in un semplice HTML.

Una cosa da tenere a mente è che non sono solo i dati provenienti direttamente dal client che possono contenere un attacco. A L'attacco memorizzato XSS prevede la scrittura di codice JavaScript dannoso in un database, il cui contenuto viene quindi interrogato dall'applicazione Web. Se il database può essere scritto separatamente dal client, l'applicazione potrebbe non essere in grado di essere sicuro che i dati siano stati salvati correttamente. Per questo motivo, l'applicazione Web deve trattare TUTTI i dati che scrive sul client come se potesse contenere un attacco.

Vedi questo link per una risorsa approfondita su come proteggersi: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

+0

Ottimo punto: vedo troppe chiacchiere di solito di "input scrubbing", quando in realtà non è sempre possibile o anche saggio, e comunque non risolve completamente il problema. Le soluzioni devono avvenire al momento dell'output. Inoltre, è importante notare che l'HTML non è l'unico contesto vulnerabile: SQL Injection è in realtà solo una variazione sullo stesso tema. – Pointy

+0

Convalida ingressi, uscite di uscita –

Problemi correlati