Scansione PCI segnala Vulnerabilità di Apache XSS - è un falso positivo?

Naviga le tue risposte
1

La banca del mio cliente ha eseguito una conformità PCI sul proprio server Apache / PHP e ha segnalato alcune vulnerabilità XSS che ai miei occhi (certamente non esperti) sembrano essere falsi positivi.

Esempio: forniscono quanto segue come prova 

GET {IP ADDRESS}/"><script>alert(document.domain)</script>.html

Questo genera un errore 404 la risposta è il messaggio standard CPanel 404, incluso questo: 

<div class="info-heading">
{IP ADDRESS}/&quot;&gt;&lt;script&gt;alert(document.domain)&lt;/script&gt;.html (port 80)
</div>

Questo mi sembra sicuro secondo la regola OWASP n. 1 - Escape HTML prima di inserire dati non fidati nel contenuto dell'elemento HTML.

Modifica: come indicato nei commenti, sta già utilizzando entità html che sembrano strane, ma è quello che hanno fornito. Anche la versione senza escape sembra sicura: 

{IP ADDRESS}/"><script>;alert(document.domain)</script>.htm

Che produce questo output: 

<div class="info-heading">
{IP ADDRESS}/%22%3E%3Cscript%3E;alert(document.domain)%3C/script%3E.htm (port 80)
</div>

Un altro un po 'più oscuro è questo esempio: 

https://{IP ADDRESS}/category/%27%3bfunc(document.cookie)%3b%27

L'applicazione inserisce componenti dell'URL in variabili javascript, ma sempre come valori quotati.

Questo è nell'output e citato come prova di XSS: 

var gCategoryID="';func(document.cookie);'"

In base alla regola di prevenzione OWASP XSS n. 3: l'unico posto sicuro in cui inserire dati non attendibili in questo codice è all'interno di un quotato "valore dati", che ritengo sia quello che stiamo facendo.

Quindi, sono queste vulnerabilità reali che devo correggere? O sembra che li stiano chiamando semplicemente vulnerabilità perché i caratteri appaiono nell'output?

Non sono chiaro su come questi potrebbero essere utilizzati per consentire un attacco XSS effettivo.

    
posta Craig Jacobs 07.01.2017 - 18:28
fonte

1 risposta

1

1. 

<div class="info-heading">
{IP ADDRESS}/&quot;&gt;&lt;script&gt;alert(document.domain)&lt;/script&gt;.html (port 80)
</div>

Con questo particolare payload è un falso positivo. Tuttavia, la tua query contiene già delle entrate HTML come input che probabilmente non erano intenzionali: 

 GET {IP ADDRESS}/&quot;&gt;&lt;script&gt;alert(document.domain)&lt;/script&gt;.html

Puoi confermare che l'output è ancora codificato correttamente quando provi invece l'input senza escape? In questo modo: 

GET {IP ADDRESS}/"><script>alert(document.domain)</script>.html

2. 

var gCategoryID="';func(document.cookie);'"

Con il carico utile specificato, anche questo sembra un falso positivo, perché le virgolette singole non interferiscono con i limiti di una stringa doppia citazione. Tuttavia, se un utente malintenzionato potrebbe inserire virgolette doppie o chiudere il tag script circostante, sarebbe vulnerabile.

Quindi è necessario assicurarsi che qualcosa di simile sia anche sfuggito correttamente: 

https://{IP ADDRESS}/category/";alert(document.cookie);"

Se non lo è, puoi utilizzare json_encode() in PHP per preparare un stringa per l'output sicuro come stringa JS, ad esempio: 

var gCategoryID = <?php echo json_encode($category_id, JSON_HEX_QUOT|JSON_HEX_TAG|JSON_HEX_AMP|JSON_HEX_APOS); ?>
    
risposta data 07.01.2017 - 18:49
fonte

Leggi altre domande sui tag

Esiste una soluzione consigliata per proteggere il verificatore SRP da utilizzare in caso di perdita del DB? Metasploit automatizza le azioni quando si collega la shell inversa