¿Por qué los atributos de ID necesitan una validación más estricta?

4

Según Hoja de trucos de prevención OWASP XSS , uno debería

  

Valide estrictamente los atributos no seguros, como el fondo, id y nombre

Entiendo que background podría contener data: urls y, por lo tanto, puede ser explotado incluso si el contenido está codificado en HTML de acuerdo con Rule 2 .

¿Pero por qué tengo que validar estrictamente id y name ? ¿Es solo porque se puede usar para inyectar anclajes que podrían desencadenar controladores de eventos que se inyectaron por otros medios? ¿O es para evitar XSS basados en DOM debido a las secuencias de comandos vulnerables que cargan código de los elementos que usan la ID (es decir, seguir a otro elemento que está presente en la página)?

    
pregunta 0x89 11.05.2015 - 14:21
fuente

2 respuestas

3

Esto no es para evitar que comillas dobles, comillas simples o espacios se salgan del contexto del atributo, ya que esto está cubierto por la "Codificación de entidad HTML agresiva".

Para background , es posible un ataque de esta manera :

<body background="javascript:alert('XSS')">

Para id y name , estos atributos se usan frecuentemente como puntos de referencia en el DOM.

Si un atacante puede falsificar estos puntos de referencia, puede ser capaz de engañar a los scripts existentes para que obtengan y establezcan valores desde lugares distintos a los diseñados, lo que puede ser peligroso dependiendo del contexto que se utilice.

Esto también se aplica a los formularios HTML donde se usa name para identificar el par de nombre / valor. Por ejemplo, si un sitio web no codifica un campo de formulario particular cuando se imprime, pero dado que el campo de formulario es generado por el servidor y el formulario está protegido contra CSRF mediante el uso de tokens, no puede ser explotado por medios normales. Sin embargo, un atacante puede atraer a un usuario para que visite una URL con un parámetro que se usa en name , que contiene una carga útil de XSS para que se ejecute al enviar el formulario.

por ejemplo Uso normal:

https://example.com/product?item_name=watch&qty=1

que hace un formulario

<form>

<input type="hidden" name="watch" value="1" />
<input type="hidden" name="shop_name" value="Bob's Supplies" />
<input type="hidden" name="anti-csrf" value="asdjasodhoai" />

<input type="submit" value="Click here to buy" />

</form>

Y luego obtiene salida como

Thank you for buying from Bob's Supplies.

Sin embargo, un atacante podría enviar un enlace al usuario así:

https://example.com/product?item_name=shop_name&qty=<script>alert('xss')</script>

Como la aplicación está correctamente codificada en HTML en este punto, representa el formulario como

<form>

<input type="hidden" name="shop_name" value="&lt;script&gt;alert(&#039;xss&#039;)&lt;/script&gt;" />
<input type="hidden" name="shop_name" value="Bob's Supplies" />
<input type="hidden" name="anti-csrf" value="asdjasodhoai" />

<input type="submit" value="Click here to buy" />

</form>

Esto luego obtiene salida como

Thank you for buying from <script>alert('xss')</script>.

ya que esta página no codifica HTML el parámetro shop_name porque es confiable y el marco de la aplicación siempre toma el primer valor en caso de duplicados. Muy artificial, pero fue lo primero que me cayó en la cabeza para demostrar el punto.

    
respondido por el SilverlightFox 12.05.2015 - 11:14
fuente
0

El texto dice que necesita validar una entrada no confiable cuando se usa como cualquier atributo. Es solo una reexpresión de " podrían causar grandes problemas.

    
respondido por el Neil Smithline 12.05.2015 - 03:10
fuente

Lea otras preguntas en las etiquetas