Acabo de expirar con xss en mi propio servidor. Escribí un código como este:
<?php
if (isset($_POST['data'])) {
echo "<a href='".htmlentities($_POST['data'])."'>Click Here</a><br/>";
}
?>
Aquí hay un poco de vulnerabilidad: como dato de publicación, podemos enviar algo como
test' onerror=alert(1)
Después de enviar recibimos una línea como esta:
La pregunta es: ¿Hay alguna forma de evitar el filtro Chrome xss en este caso?
Aquí, simplemente puede usar la carga útil javascript:alert(1) , ya que el auditor no identifica las URL de javascript dentro de un atributo href como XSS. Al hacer clic en el enlace se ejecutará el código.
Sin embargo, será mucho más difícil ejecutar JS inyectando un atributo de controlador de eventos adicional de la forma en que lo intentó, ya que su ejemplo de código refleja directamente la entrada sin procesamiento adicional. Este es exactamente uno de los escenarios de ataque para los que está destinado el auditor de XSS. Intenta identificar las partes reflejadas para evitar su ejecución. Como comentó @NickMckenna, no hay una manera general de evitar al auditor en este escenario.
Lo que podría hacer es inyectar otros atributos que tengan efectos secundarios. Por ejemplo, aún puede usar el atributo style y aplicar CSS arbitrario (por ejemplo, ' style='background:red; ). En combinación con otras tecnologías como AngularJS, inyectar diferentes atributos puede llevar a XSS.
Tenga en cuenta que el auditor XSS es frágil. Dado que no comprende cómo se procesa el código en el lado del servidor, una simple sustitución en un programa más complejo podría ser suficiente para confundirlo, por ejemplo:
<?php
if (isset($_POST['data'])) {
// Filter bad words
$data = str_replace('BADWORD', '', $_POST['data']);
echo "<a href='".htmlentities($data)."'>Click Here</a><br/>";
}
?>
En este caso, una secuencia como ' onBADWORDmouseover='alert(1) pasaría por alto al auditor.
(Tenga en cuenta que el atributo onerror que intentó inyectar no es válido para las etiquetas <a> ).