2013-04-02 18 views
10

A questo collegamento: http://www.acunetix.com/websitesecurity/cross-site-scripting/ sotto The Theory of XSS, dice: the hacker infects a legitimate web page with his malicious client-side script. La mia prima domanda sulla lettura di questo è: se l'applicazione è distribuita su un server che è sicuro (come nel caso di una banca per esempio), come può mai l'hacker avere accesso al codice sorgente della pagina web? Oppure può iniettare lo script dannoso senza accedere al jsp di origine?Che cosa è lo scripting cross-site

+0

possibile duplicato di [? Che cosa è Croce Script sito Inclusione (XSSI modificando)] (http://stackoverflow.com/questions/8028511/what-is- cross-site-script-inclusion-xssi) –

risposta

34

Questa descrizione è un po 'fuorviante nel modo in cui è formulata. La pagina fornita dal server quando qualcuno lo richiede è inalterata. Invece, un attacco XSS sfrutta una debolezza in una pagina che include una variabile presentata in una richiesta per presentarsi in forma grezza nella risposta. La pagina riflette solo ciò che è stato inviato in quella richiesta ... ma il contenuto di quella richiesta potrebbe contenere caratteri che escono dal normale contenuto di testo e introdurre contenuti HTML o javascript che lo sviluppatore non intendeva.

Ecco un breve esempio. Supponiamo che tu abbia una sorta di linguaggio dei template creato per produrre una pagina HTML (come PHP, ASP, CGI o uno script Velocity o Freemarker). Prende la seguente pagina e sostituisce "<? = $ Nome? >" con il valore senza escape del parametro di query "nome".

<html> 
<head><title>Example</title></head> 
<body>Hi, <?=$name?></body> 
</html> 

Qualcuno chiama la pagina con il seguente URL:

http://example.com/unsafepage?name=Rumplestiltskin 

dovrebbe aspettare di vedere questo messaggio:

Hi, Rumplestiltskin 

Chiamando la stessa pagina con qualcosa di più dannoso può essere utilizzato per modificare la pagina o l'esperienza utente sostanzialmente.

http://example.com/unsafepage?name=Rumplestiltskin<script>alert('Boo!')</script> 

Invece di limitarsi a dire: "Ciao, Rumplestiltskin", questo URL potrebbe anche causare la pagina per pop-up un messaggio di avviso che dice: "Boo!". Questo è, ovviamente, un esempio semplicistico. Uno potrebbe fornire uno script sofisticato che cattura le battute o chiede un nome e una password da verificare, o cancella lo schermo e riscrive interamente la pagina con contenuti shock. Sembrerebbe ancora che provenga da example.com, perché la pagina stessa ha funzionato, ma il CONTENT viene fornito da qualche parte nella richiesta e viene semplicemente rispecchiato come parte della pagina.

Quindi, se la pagina sta solo restituendo il contenuto fornito dalla persona che lo richiede e richiede questa pagina, allora come fa un hacker a infettare la TUA richiesta? Di solito, questo si ottiene fornendo un collegamento, su una pagina Web o inviato via e-mail, o in una richiesta abbreviata dell'URL, quindi è difficile vedere il pasticcio nell'URL.

<a href="http://example.com?name=<script>alert('Malicious content')</script>"> 
Click Me! 
</a> 

Nulla sul server è mai "infetto".XSS è solo un trucco per far sembrare che le cose provengano da un server quando la pagina di quel server è nota per ripetere ciò che è stato inviato.

+0

Grazie per un'ottima spiegazione – Victor

+0

Ho avuto l'idea sbagliata che all'interno di una intranet aziendale, quando si tenta di accedere a un sito Web che si trova in un dominio diverso (all'interno della stessa azienda) solo allora XSS i problemi si verificano Bit sembra che l'XSS possa verificarsi in ogni momento. Anche se sto cercando di accedere a qualcosa come http: // localhost: 8080/someservlet – Victor

+0

La tua nuova comprensione è corretta. Stai descrivendo un pericolo valido, però. Inizialmente, l'XSS influisce solo sulla pagina a cui stai accedendo, ma il nuovo contenuto che inserisci ti può reindirizzare ovunque, ed è particolarmente pericoloso quando quel luogo è già stato autenticato da qualche parte. – phatfingers

1

Questo utente malintenzionato non ha bisogno di accedere al codice sorgente.

Un semplice esempio potrebbe essere un parametro URL che viene scritto sulla pagina. È possibile modificare il parametro URL per contenere tag di script.

Un altro esempio è un sistema di commenti. Se il sito Web non disinfetta correttamente l'input/output, un utente malintenzionato potrebbe aggiungere uno script a un commento, che verrà quindi visualizzato ed eseguito sui computer di chiunque abbia visualizzato il commento.

Questi sono semplici esempi. C'è molto di più e molti tipi diversi di attacchi XSS.

1

È meglio pensare che lo script venga inserito nel mezzo della conversazione tra la pagina Web mal codificata e il browser Web del client. In realtà non è iniettato nel codice della pagina web; ma piuttosto nel flusso di dati che va al browser web del cliente.

Ci sono due tipi di attacchi XSS:

  1. non persistenti: Questo sarebbe un URL appositamente predisposto che incorpora uno script come uno dei parametri alla pagina di destinazione. Il brutto URL può essere inviato in una e-mail con l'intento di indurre il destinatario a fare clic su di esso. La pagina di destinazione gestisce in modo errato il parametro e invia involontariamente il codice alla macchina del client che è stata passata originariamente attraverso la stringa dell'URL.
  2. Persistenza: questo attacco utilizza una pagina su un sito che salva i dati del modulo nel database senza gestire correttamente i dati di input. Un utente malintenzionato può incorporare un brutto script come parte di un tipico campo dati (come Last Name) che viene eseguito inconsapevolmente sul browser Web del client. Normalmente il brutto script verrebbe archiviato nel database ed eseguito nuovamente sulla visita di ogni cliente alla pagina infetta.

vedere il seguente per un esempio banale: What Is Cross-Site Scripting (XSS)?

Problemi correlati