Cross scripting sito su una chiave unica

Question

Cross scripting sito su una chiave unica

#1 da (4 voti)

1

È possibile eseguire un attacco di scripting cross-site inserendo il mio script in un campo che è necessario per abbinare un valore specifico?

Sto eseguendo la scansione di un'applicazione per vulnerabilità e il mio strumento di scansione (OWASP ZAP) sta restituendo diverse vulnerabilità di scripting cross-site. I risultati restituiti includono un percorso per una richiesta REST, il metodo associato (GET o POST) e il parametro utilizzato per includere lo script.

Il problema è che per ogni vulnerabilità, il parametro utilizzato è un ID per un valore univoco. Ad esempio, una richiesta GET getUserPrivileges mostra una vulnerabilità utilizzando il parametro 'userId'. Se dovessi provare a fare questa richiesta in SoapUI, usando un userId non valido, otterrei una risposta "Bad Request". Non c'è neanche un posto nell'interfaccia utente che mi permetta di inserire il mio valore personale per questo parametro.

La mia ipotesi è che problemi come questi sono tutti falsi positivi, ma, non essendo molto informato su questo argomento, volevo controllare la mia ipotesi.

Se sono corretto in questa ipotesi, ci sarebbe qualche motivo per cui un tale falso positivo sarebbe venuto fuori? C'è qualcosa che potrebbe causare l'errore del mio strumento di scansione per un problema?

Modifica: qui ci sono due richieste di esempio. Uno di quelli che penso possa essere effettivamente un problema è l'Esempio 2. Osservo che il testo "" in quell'esempio è presente nella risposta non elaborata, ma non nella risposta HTML.

(Quando dico che il contenuto html non è accettato, mi riferisco al contenuto nella risposta alla richiesta.) Le impostazioni per questo sono sul lato server. In primavera, questo sembra apparire con l'assenza di qualcosa del tipo " produce = MediaType.TEXT_HTML_VALUE "nella dichiarazione del metodo e la sua sostituzione con qualcosa del tipo" produce = MediaType.APPLICATION_JSON_VALUE ".)

Esempio 1:

Request:
GET http://###.##.##.###:####/AAAAAAAA/BBBBBBBB/CCCCCCCC?    requestId=%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E&comments=%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E HTTP/1.1
Accept-Encoding: gzip,deflate
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d

Response (Raw):
HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
Content-Type: application/json;charset=UTF-8
Content-Length: 167
Date: Wed, 22 Aug 2018 ##:##:## GMT
Connection: close

{"timestamp":#############,"status":400,"error":"Bad Request","exception":"java.lang.NumberFormatException","message":"For input string: '<script>alert(1);</script>'"}

Response (HTML):
unsupported content-type [application/json;charset=UTF-8]

Esempio 2:

Request:
GET http://###.##.#.###:####/AAAAAAAA/BBBBBBBB/CCCCCCCC?requestId=%3Cscript%3Ealert%28%22hello%22%29%3B%3C%2Fscript%3E HTTP/1.1
Accept-Encoding: gzip,deflate
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
Host: ###.##.#.###:####
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

Response (raw):
HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
token: 2cd68a38-c3bd-a56b-e65c-b76da893cd4d
Content-Type: text/html;charset=UTF-8
Content-Length: 173
Date: Wed, 22 Aug 2018 ##:##:## GMT
Connection: close

{"timestamp":#############,
"status":400,
"error":"BadRequest",
"exception":"java.lang.NumberFormatException",
"message":"For input string: '<script>alert('hello');</script>'"}

Response (HTML):
{"timestamp":#############,
"status":400,
"error":"Bad Request",
"exception":"java.lang.NumberFormatException",
"message":"For input string: ''"}

xss zap

posta harrys 20.08.2018 - 22:50

fonte

1 risposta

Leggi altre domande sui tag xss zap

Come rilevare una scansione su un computer locale? Wireguard: è adatto per scenari da guerriero della strada?

score 4 · Accepted Answer

Come al solito quando si utilizzano scanner automatici, è necessario eseguire alcuni test manuali per confermare questa vulnerabilità o rifiutarla come falso positivo.

Perché ZAP dovrebbe etichettarlo come XSS?

Dalla documentazione ZAP (grazie @SimonBennetts) :

Cross Site Scripting (reflected)

This rule starts by submitting a 'safe' value and analyzing all of the locations in which this value occurs in the response (if any). It then performs a series of attacks specifically targeted at the location in which each of the instances occurs, including tag attributes, URL attributes, attributes in tags which support src attributes, html comments etc.

Ciò significa che il tasso di falsi positivi di ZAP per l'XSS riflesso è probabilmente piuttosto basso, ovvero la maggior parte di ciò che riporta è reale, perché riporta solo elementi in cui l'input viene riflesso nell'origine della pagina in un modo che appare vulnerabile a uno dei meccanismi XSS standard.

Tutto ciò che riporta merita un'ulteriore indagine manuale.

Che cosa succede se non c'è posto nell'interfaccia utente per inserirlo?

Non importa.

I tipi più pericolosi di XSS sono quelli in cui il carico utile malevolo si trova in un parametro GET URL, ad esempio:

http://server/cgi-bin/testcgi.exe?usedid=<script>alert("Hello!")</script>

perché posso inserire il link in un'email di phishing e, una volta fatto clic, eseguirai il mio codice!

Quindi, anche se non esiste un elemento dell'interfaccia utente, ZAP ha trovato alcuni parametri in cui è possibile iniettare il codice e il server lo ripeterà come parte della pagina HTML.

Esegui alcuni test manuali

Questo è il punto in cui dovrai ispezionare l'origine della pagina / iniziare a giocarci fino a quando non avrai generato un popup di avviso o ti sarai convinto che gli sviluppatori hanno eseguito correttamente l'escape dell'output.

Per iniziare, OWASP ha una grande guida ai test XSS:

link

Come sottolinea @AndrolGenhald, la pagina "Richiesta errata" probabilmente rimanda l'input a te senza farla scappare correttamente. Se colpisco il tuo server con usedid=<script>alert("Hello!")</script> , suppongo che mi risparmierà una pagina di errore che dice

Bad Request: "<script>alert("Hello!")</script>" is not a valid user.

Se guardi nel sorgente della pagina, spero che lo vedresti correttamente scappato:

Bad Request: &quot;&lt;script&gt;alert(&quot;Hello!&quot;)&lt;/script&gt;&quot; is not a valid user.

che dice al tuo browser di renderlo come testo, piuttosto che trattarlo come parte del codice HTML. Se non appare sfuggito nell'origine della pagina, con un po 'di gioco potresti probabilmente farlo visualizzare come:

Bad Request: "

che significa che in realtà ha eseguito lo script anziché renderlo come testo (e probabilmente avrai un bel popup per utilizzarlo). Ciao riflesso vettore di attacco XSS !! (Hai appena trovato una vulnerabilità, apri un ticket per i bug e vai a bere una birra)