Scripting cross-site in WordPress consigli pratici per la protezione del sito

In questa serie, diamo un'occhiata a come proteggere i nostri progetti WordPress da XSS - o cross-site scripting. Nel primo articolo della serie abbiamo definito cosa è in realtà lo scripting cross-site, comprendendo come funziona e perché è pericoloso.

Abbiamo anche passato un po 'di tempo a discutere su come questo influisce sui nostri sforzi quotidiani di sviluppo di WordPress e su cosa possiamo fare al riguardo. Sebbene ci siano alcune funzioni che WordPress ha a disposizione per aiutare a validare e disinfettare i dati, c'è più lavoro che possiamo fare per proteggere i nostri progetti.

In questo articolo finale, daremo un'occhiata ad alcuni suggerimenti pratici che possiamo seguire e alcuni test che possiamo amministrare per proteggere il nostro lavoro dagli attacchi XSS.


Le basi del testing XSS

In generale, il modo in cui vai a testare il tuo sito per le vulnerabilità degli script tra siti è trovare ovunque nel sito o nell'applicazione che accetta l'input dell'utente.

Ovviamente, ciò avverrà sotto forma di campi di input, textareas o simili.

Se il sito non esegue correttamente la sanitizzazione e / o la convalida, normalmente si avrà successo nel trovare gli exploit; tuttavia, se il sito è gestendo correttamente i dati in arrivo, probabilmente non vedrete alcun risultato per i vostri sforzi.

Diamo un'occhiata a diversi casi che possiamo amministrare sui nostri siti (o anche su altri, sebbene lo facciano quello a tuo rischio!).

1. Individuazione di una vulnerabilità legata agli script tra siti diversi

Una delle prime cose che possiamo fare per localizzare una vulnerabilità è il tentativo di iniettare del codice che determinerà se esiste o meno una vulnerabilità.

Il codice in questione è il seguente:

 '; alert (String.fromCharCode (88,83,83)) //'; alert (String.fromCharCode (88,83,83)) // "; alert (String.fromCharCode (88,83,83)) / /";alert(String.fromCharCode(88,83,83))//-->"> '>

Inserisci questo codice in qualsiasi campo di inserimento e invialo.

Se una vulnerabilità fa esiste, quindi verrà visualizzata la parola "XSS". Se non viene restituito, è probabile che tu sia sicuro (anche se questo non può essere garantito al 100%); tuttavia, se viene emesso, probabilmente significa che esiste una vulnerabilità che tu o qualcuno più malintenzionato riesci a sfruttare.

2. Tentativo di Cross-Site

Nell'ultimo articolo, abbiamo discusso la politica della stessa origine che sostanzialmente stabilisce che un sito non dovrebbe essere in grado di richiedere risorse da un dominio diverso da quello in cui risiede attualmente..

Per tentare di eseguire codice da un server remoto o da un server non parte della stessa origine - puoi eseguire il seguente codice:

 “>

Si noti che il prefisso per il caso di test è non un errore di battitura. È necessario per testare realmente la vulnerabilità. Se esiste effettivamente una vulnerabilità, quindi verrà visualizzato un cookie del browser dal dominio remoto; in caso contrario, non vedrai nulla o la tua console potrebbe restituire un messaggio sulla politica della stessa origine.

Puntelli a Janne per questa particolare tattica.

3. Attributi dell'immagine

Infine, una delle vulnerabilità più note sta tentando di eseguire codice JavaScript all'interno di un attributo di un 'img'tag.

Ad esempio, creando un elemento come:

 

Rivelerebbe una vulnerabilità che in realtà visualizzerebbe una finestra di avviso con 'XSS' come messaggio piuttosto che un'immagine rotta effettiva.

Semplice, non è vero? Tuttavia, richiede solo una vulnerabilità per esporre un exploit.


Altre risorse

Un Wiki di attacchi

Il fatto è, questo è appena la punta dell'iceberg per quanto riguarda i test XSS. In effetti, occorrerebbe un'intera wiki per documentare le varie vulnerabilità presenti.

In effetti, questo è esattamente ciò che il Apri la sicurezza delle applicazioni Web Il progetto ha mirato a fare: documentare le varie vulnerabilità XSS esistenti e come testarle. Puoi visitare l'intero elenco, vedere la definizione degli attacchi e come amministrarli.

Vulnerabilità HTML5

Ma non è tutto! Con l'emergere di nuove tecnologie, come HTML5, ci sono molte altre cose che dovremmo prendere in considerazione.

Sebbene possa sembrare un po 'strano che un linguaggio di markup possa essere suscettibile agli attacchi di cross-site scripting, ha senso soprattutto considerando alcuni degli attributi che gli elementi più recenti consentono.

Caso in questione:

  • Gli elementi del modulo supportano a FormAction attributo che può eseguire JavaScript
  • Gli elementi di input supportano un onfocus attributo che può anche eseguire JavaScript
  • Il nuovo elemento video supporta a manifesto attributo che può anche eseguire JavaScript

Certo, non tutti questi sono applicabili a ciascun browser, ma sono importanti da sapere in modo che tu possa testare correttamente nei browser pertinenti.

Detto questo, puoi trovare un foglio completo HTML5 di vulnerabilità note e i browser pertinenti sul sito di sicurezza HTML5.

Ha.ckers

Uno dei siti di risorse XSS più longevi sul web è Ha.ckers.org e hanno un utile strumento di calcolo dei fogli di XSS.

In parole povere, oltre ad offrire un dizionario di vulnerabilità note, il loro calcolatore codificherà automaticamente il tuo XSS in diversi tipi di codifica come esadecimale, decimale, Base64 e così via in modo che tu possa anche tentare di iniettare quelli traduzioni nella tua applicazione.

Dopotutto, metà della sicurezza si sta assicurando che tutti i tipi di input siano correttamente disinfettati, sfuggiti e convalidati - non solo il caso base.


Conclusione

Ovviamente, il campo di scripting cross-site è ricco di vulnerabilità che non sono limitate a un singolo browser, per non parlare di una singola versione del browser. Fortunatamente, ci sono un sacco di risorse, cheat sheet, come e altro materiale educativo a nostra disposizione non solo per tenerci informati di ciò che è là fuori, ma come possiamo programmare in modo difensivo contro di esso.

E sebbene questo articolo sia specificamente rivolto a noi sviluppatori di WordPress, le tattiche e le tecniche trascendono WordPress e sono applicabili a chiunque stia sviluppando applicazioni web.

Infine, vorrei offrire una parola di ringraziamento a Janne Ahlberg per aver ispirato il contenuto di questa serie. È uno specialista della sicurezza che fa un sacco di lavoro XSS che riferisce a Envato, quindi se sei interessato a questo argomento, in particolare per quanto riguarda la promozione del tuo lavoro su uno dei mercati di Envato, ti consiglio caldamente di seguire il suo blog.