verificando como defensa para el ataque XSS

Muchos de los contramedidas de falsificación de solicitudes en todos los sitios harán que el XSS reflectivo sea más difícil Para explotar pero no imposible. Todavía puede ser posible explotar una de estas fallas con clickjacking o otros métodos . El clickjacking y otros vectores también deberían ser fijos, pero no es una solución simple ni infalible en comparación con la validación de entrada / saneamiento.

Hay problemas con el encabezado de referencia como medida de seguridad. Si la solicitud se origina en una página HTTPS que va a una página HTTP, el Referer estará ausente. El encabezado de origen se creó para abordar este problema. Un OWASP A10: los redireccionamientos sin validar y los fora también se pueden usar para omitir una verificación de referencia.

La protección del remitente no es infalible si tiene otras vulnerabilidades en el sitio.

Si tiene un redirección abierta en su sitio (o incluso uno con cheques para ver si el enlace está interno), podemos colocar la URL vulnerable en esta redirección, y los usuarios se envían a la página vulnerable con un referente correcto (interno).

La verificación de los remitentes ayudará con algunas clases de XSS - XSS reflejado y DOM XSS, pero no tendrá ningún efecto en el XSS almacenado .

^{Nota: haré una respuesta ya que la respuesta actual aceptada no respondió la pregunta.}

Reflective XSS básicamente implica engañar a una víctima para que haga clic en un enlace a su sitio web:

• Un atacante puede enviar por correo electrónico a una víctima el enlace your-website.com/query?<script>alert('hacked!');evil();</script>

• evil.com puede vincular a your-website.com/query?<script>alert('hacked!');evil();</script> y engañar a una víctima para que haga clic en él.

Si su sitio web realiza una comprobación estricta de referencias, rechazará las solicitudes como las anteriores.

Por supuesto, si su sitio web permite a los usuarios publicar enlaces, entonces un atacante puede publicar el enlace your-website.com/query?<script>alert('hacked!');evil();</script> debajo de su sitio web. La comprobación estricta del remitente fallará, ya que el remitente es su propio sitio web.

Creo que, en realidad, es bastante simple: desde la página a la que te redireccionamos, solo aceptas referencias de tu propio sitio (es decir, dominio), XSS es más difícil (solo se permite un sitio).

Pero eso tendría el inconveniente de que no se puede acceder a esa página desde el exterior, solo la referencia, lo que hace que la lectura de las URL sea bastante complicada (pero las desventajas están bastante bien explicadas por D.W.).

un ejemplo: Di que tienes un blog. el acceso directo al blog / post / id / 12 no está permitido (verificador de referencias), pero el acceso al enlace perma de la publicación (blog / post / perm / 12) está permitido. El enlace perma solo le sirve al remitente, el remitente redirige a la publicación (blog / post / id / 12) - ¡y listo!