En una aplicación web, podría haber dos enfoques para mitigar los ataques XSS:
¿Qué método debería preferirse desde el punto de vista de la seguridad?
Con cualquiera de los dos métodos, ¿cuáles son los errores?
Para la validación de entrada, recomiendo un enfoque de lista blanca combinado con pasar o rechazar. Así que define qué es válido y acepta solo entradas válidas, rechaza todo lo demás.
Si crea un editor de texto enriquecido que envía html a su servidor, puede usar JavaScript para desinfectar la entrada, de modo que pegar html desde Word podría terminar funcionando. Sin embargo, su servidor no aceptará ninguna entrada no saneada.
Tratar de limpiar está sujeto a fallas, ya que esto suele ser mucho más complejo que simplemente averiguar si la entrada es válida o no.
La lista blanca es esencial para una buena seguridad. Siempre puede decidir aceptar más entrada, mientras mantiene el control. En un enfoque de lista negra, siempre tendrás que ponerte al día con el último truco.
Para resultados, vea otras respuestas.
Estoy de acuerdo con @ Jorn's responde sobre la validación.
Sin embargo, todavía estás olvidando un paso muy muy importante aquí, y eso es codificación de salida .
P.ej. Codificación HTML (o codificación de Atributos, o codificación de Javascript, etc.) antes de emitir algo ... De hecho, podría decirse que incluso más es más importante que la validación de entrada (posiblemente, no del todo, y definitivamente no lo es todo) situaciones ...)
En cualquier caso, no debería ser ninguno de los dos, es definitivamente una validación de entrada estricta + codificación de salida.
Ahora, si te refieres a incluir etiquetas HTML "seguras" en la salida (entonces no es muy clara en tu pregunta), entonces deberías codificar cada y luego descodificar la información específica. etiquetas que está buscando sin ninguno de los atributos de la etiqueta .
P.s. Si te refieres a una aplicación .NET, MS AntiXSS (en WPL) proporciona un conjunto de métodos .GetSafeHTMLXXX .
su pregunta "Datos de entrada del usuario, ¿es suficiente el filtrado o debería analizarse?" Es más general que el caso XSS. Supongo que querías ser específico para XSS pero, por lo general, los comentarios de los usuarios pueden causar muchas vulnerabilidades adicionales como Inyección de SQL, Trayectoria de ruta, XSS ... A medida que su pregunta sea más específica en XSS, me referiré a lo que ya se ha dicho e iré para el filtrado de entrada y la codificación de salida (¡siempre en el lado del servidor!) Con algunas medidas correctivas conocidas como la proporcionada por OWASP .
Aún así, me gustaría señalarle que la mejor manera de resolver la Inyección SQL que puede ser causada por la entrada no verificada está en consultas parametrizadas ( Chuleta de Prevención de Inyección de SQL ), entonces, si considera las vulnerabilidades que atraviesan el camino, mi enfoque sería un enfoque de listas blancas.
La pregunta es demasiado amplia. La mejor respuesta es: depende. Depende del formato de los datos del usuario y de la política de seguridad que esté aplicando.
Por ejemplo, si incluye datos de usuario en una consulta SQL, la mejor respuesta es usar declaraciones preparadas.
Por ejemplo, si incluye datos de usuario, por ejemplo, su nombre completo, en una página HTML, la mejor respuesta puede ser utilizar la codificación de salida.
Por ejemplo, si está creando un servicio de correo web que permite a las personas enviar correos electrónicos HTML y desea mostrar un correo electrónico HTML al usuario, pero solo si el correo electrónico no contiene ningún contenido activo, entonces La mejor respuesta incluirá analizar y filtrar el contenido analizado.
La mejor respuesta depende del dominio. Para obtener una respuesta más útil, deberá proporcionar más detalles sobre el problema concreto que está tratando de resolver.
Recomiendo encarecidamente no reinventar la rueda. Claro, cada desarrollador web debe conocer los conceptos básicos de seguridad, pero si tiene la posibilidad de usar una solución robusta, úsela. Hay muchas posibilidades de que durante la implementación de su propio filtro se pierda algo. La validación correcta de la entrada no solo consiste en eliminar los caracteres incorrectos, es un tema complejo. De todos modos, si no tienes otra opción, mira cómo funcionan las otras WAF. Un conocido y robusto para aplicaciones PHP es enlace . Y en cuanto a los vectores de ataque, solo para recordar cuán "difusos" son - enlace .
Lea otras preguntas en las etiquetas web-application appsec xss attack-prevention