Estaba leyendo este artículo aquí , en el medio vi que el autor usaba -confirm()- como carga útil.
Me gustaría saber qué es esta carga útil? Me refiero a cuál es la diferencia entre -confirm()- y <script>confirm()</script> . ¿Por qué funciona mientras que <script>confirm()</script> no?
Sería muy adecuado si alguien arrojara algo de luz sobre esto.
El problema es el carácter de escape que falta \ en el último parámetro.
Puedes intentarlo con una función vacía:
<script>
function somefunction(){
//do nothing
}
somefunction( 'wskw='-confirm(1)-'');
somefunction( 'wskw='+confirm(2)+'');
somefunction( 'wskw='*confirm(3)*'');
somefunction( 'wskw='/confirm(4)/'');
somefunction( 'wskw='%confirm(5)%'');
</script>
Es igual que <script>confirm(1)</script> o <script>confirm(1)</script>
Puede probarlo con este violín: enlace
En general, la entrada siempre debe estar urlencodificada, como% 27 en lugar de '. Se olvidaron de escapar del segundo parámetro.
'' cierra la cadena y después de 'puede haber cualquier código JavaScript que se ejecutará, que debe encapsularse en cualquiera de los siguientes operadores aritméticos de JavaScript (-, +, *, /%). Lo que está sucediendo aquí es un cálculo con el resultado de la llamada a la función alert () o confirm () que debe ejecutarse para obtener el resultado.
Como el código está directamente en esta forma en el código fuente, se genera en el lado del servidor y existe el problema de que falta el escape del parámetro, no hay un XSS directamente. Vulnerabilidad en las bibliotecas de JavaScript. En teoría, este código sin escape funciona con cualquier función y biblioteca en JavaScript. El problema es la generación del código en el lado del servidor.
<script type="text/javascript">
// Redirect click tracking
$.sliLinkTracker( ".redirect-link",'some_url_with_escape_characters', 'wskw='-confirm(1)-'');
</script>
En general, me pondré en contacto con el propietario del sitio web y les revelaré esto, ya que es fundamental.
Lea otras preguntas en las etiquetas xss attack-vector