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

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