PCI scan informa de la vulnerabilidad de Apache XSS: ¿es un falso positivo?

Navega tus respuestas
1

El banco de mi cliente realizó un cumplimiento de PCI en su servidor Apache / PHP e informó sobre algunas vulnerabilidades de XSS que a mi parecer (aparentemente no expertos) parecen ser falsos positivos.

Ejemplo: proporcionan lo siguiente como evidencia 

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

Esto genera un error 404, la respuesta es el mensaje estándar de CPanel 404, incluido esto: 

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

Esto me parece seguro según la regla OWASP # 1: Escape HTML antes de insertar datos no confiables en el contenido del elemento HTML.

Editar: como se señaló en los comentarios, esto ya está usando entidades html, lo que parece extraño, pero eso es lo que proporcionaron. La versión no escapada también parece segura: 

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

Que produce esta salida: 

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

Otro ejemplo más turbio es este ejemplo: 

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

La aplicación coloca los componentes de la url en variables de javascript, pero siempre como valores citados.

Esto está en la salida, y se cita como evidencia de XSS: 

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

De acuerdo con la regla de prevención Nº 3 de OWASP XSS: el único lugar seguro para poner datos no confiables en este código es dentro de un "valor de datos" citado, que creo que es lo que estamos haciendo.

Entonces, ¿son estas vulnerabilidades reales que necesito arreglar? ¿O parece que simplemente los están llamando vulnerabilidades porque los caracteres aparecen en la salida?

No tengo claro cómo podrían usarse para permitir un ataque XSS real.

    
pregunta Craig Jacobs 07.01.2017 - 18:28
fuente

1 respuesta

1

1. 

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

Con esta carga útil en particular es un falso positivo. Sin embargo, su consulta ya contiene elementos HTML como entrada que probablemente no fue intencional: 

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

¿Puede confirmar que la salida todavía está codificada correctamente cuando intenta una entrada sin escapar en su lugar? Así: 

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

2. 

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

Con la carga útil dada, esto también parece un falso positivo, porque las comillas simples no interfieren con los límites de una cadena de comillas dobles. Sin embargo, si un atacante pudiera insertar comillas dobles o cerrar la etiqueta del script circundante, sería vulnerable.

Por lo tanto, debe asegurarse de que algo como esto también se escape correctamente: 

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

Si no lo está, puede usar json_encode() en PHP para preparar un cadena para una salida segura como una cadena JS, por ejemplo: 

var gCategoryID = <?php echo json_encode($category_id, JSON_HEX_QUOT|JSON_HEX_TAG|JSON_HEX_AMP|JSON_HEX_APOS); ?>
    
respondido por el Arminius 07.01.2017 - 18:49
fuente

Lea otras preguntas en las etiquetas

¿Cómo enviar cookies de manera segura de un sitio a otro a través de userscript? ¿Se recomienda utilizar una solución recomendada para proteger el verificador SRP si se filtra la base de datos?