¿Es seguro usar jQuery en el lado del servidor para la validación de la entrada del usuario?

Debe verificar que el HTML sea válido (por ejemplo, anidar correctamente ", ', & lt ;, >). De lo contrario, diferentes navegadores usarán diferentes algoritmos para" arreglarlo ". Estos resultados en ellos viendo diferentes cosas como etiquetas.

Además, existe un alto riesgo de que agregue demasiado a su lista blanca. Por ejemplo, el atributo href puede contener contenido activo. Por ejemplo: jaVascript: , vbscRipt: , java scriPt: entre otros.

En Internet Explorer hay una función de expresión () que se puede usar en CSS para ejecutar Javascript.

Le sugiero que utilice una de las bibliotecas existentes para las aportaciones de los usuarios, como purificador html .

Por favor, eche un vistazo al truco de la hoja XSS .

Por último, pero no menos importante, tenga en cuenta que un ataque podría funcionar completamente sin javascript, compre inyectando un formulario solicitando un nombre de usuario y una contraseña.

No, ya que parece indicar que está utilizando jQuery (experto en analizar información de etiquetas HTML) para hacer una validación de entrada en el usuario que ingresa el HTML que luego mostrará al usuario. La lista blanca de etiquetas HTML seguras, y la de listas negras de etiquetas HTML inseguras es el método incorrecto para prevenir el XSS.

El método correcto es utilizar un lenguaje de marcado de peso ligero como Markdown o reStructuredText para que el usuario ingrese datos con formato (como publicaciones de blog) , comentarios, etc). De esta manera, el usuario puede estilizar su texto en lo que quiera, agregar texto en negrita o enlaces dentro de su comentario con una sintaxis como **make this bold** o [text for a link](http://www.example.com/fake/link) que siempre se convierte en html para que se muestre como <a href="http://www.example.com/fake/link">text for a link</a> en el navegador del usuario. Esto le permite evitar completamente, por ejemplo, <script> insertando archivos javascript, o onclick onmouserover form con atributos de acción, ya que su lenguaje de marcado seguro limitado está configurado para no permitir esas etiquetas o atributos generales.

Por supuesto, debes configurar tu idioma para que esté en un safe_mode donde los caracteres especiales específicamente < , > , & , " , ' se escapan en HTML (en < , > , & " y ' que el usuario verá como el carácter real sin que el navegador lo interprete como fuente HTML de la parte), los atributos ( attributes=false ) no pueden ser ingresado (por ejemplo, onclick ), además de requerir enlaces para comenzar con una lista blanca limitada; por ejemplo, http , // , / , ftp , mailto , news , así que no dejes que los usuarios ingresen javascript como protocolo en sus enlaces.

(Esto también puede lograrse filtrando la entrada sin procesar a través del purificador de HTML, si desea que sus usuarios puedan escribir HTML directo como en la respuesta de Hendrik).

Al hacer esto con un lenguaje de marcado ligero y maduro, no se olvidará de eliminar algo sin importar qué tan oscuro es o cómo su biblioteca jQuery no detectó el HTML malformado mientras lo desinfectaba, pero sí lo hizo un navegador en particular. .

No. No es seguro. Los navegadores varían ampliamente en la forma en que analizan ciertos tipos de entrada (para HTML especialmente "inválido", donde "inválido" aquí no está especialmente bien definido, pero a veces incluso para HTML "válido"). Esto proporciona una gran cantidad de formas sutiles de contrabandear código HTML incorrecto en su documento HTML, sin que jQuery se dé cuenta.

La raíz del problema no es jQuery; La raíz del problema es su enfoque general para la eliminación de HTML. He realizado algunos experimentos, y he pedido a otros que escriban desinfectantes HTML. He encontrado que más de 2 / 3rds terminan siendo inseguros. Por lo tanto, mi recomendación es: no escriba su propio desinfectante HTML. Es muy probable que te equivoques.

En su lugar, sugiero usar una biblioteca de desinfectante HTML existente. Sugiero usar Desinfectante de HTML OWASP , Purificador de HTML , o NeatHtml ; están bien diseñados y bien considerados.

Hay muchas peculiaridades del navegador que podrían engañar a los comportamientos de su navegador. Los navegadores tienen diferentes motores, lo que podría llevar a analizar partes del HTML sintaxis rotas de diferentes maneras. Aquí es un ejemplo de tipo de comportamiento inesperado (le recomiendo que lea este libro, si desea obtener más información).

Además, no puede estar seguro de lo que traerá el futuro. Las nuevas etiquetas o atributos podrían ser añadidos. La forma más adecuada es evitar las listas negras y crear la lista blanca de etiquetas aceptables.

Aquí funciona cómo funciona la normalización de javascript / jquery:

var userinput = "<a href='javascript:alert(\"<iframe>\")'>\
<embed> </embed>\
<object classid='buggy plugin' hostileparams='' />\
<html></html> <script></script> < > <htmlx> </a> < > <> \
<htmz> <></a>\
<![CDATA[ > <script type=\"text/javascript\">document.write(\"X\")</script> ]]>";

var x = jQuery('<div/>').html(userinput);
var y = x;
document.write(jQuery('<div/>').text(x.html()).html());
document.write("<br/>" + y.html());

Salida:

X<a href='javascript:alert("<iframe>")'><embed> \
<object classid="buggy plugin" hostileparams="">\
</object> &lt; &gt; <htmlx> </htmlx></a>\
&lt; &gt; &lt;&gt; <htmz> &lt;&gt;<!--[CDATA[ --> ]]&gt;</htmz>
  < > < > <> <> ]]>

¡Esto es raro!