Como lo menciona la respuesta de @Rook, la única forma en que JS puede protegerse contra XSS es cuando se usa un marco (como Angular) que recupera todo el contenido dinámico de la página a través de JS (generalmente usando XmlHttpRequest ) y luego lo inyecta de forma segura en la página. Como @GeorgeMauer señala, usted (o su marco) puede realizar este paso de inyección en la página de forma segura utilizando la propiedad textContent / innerText de un elemento DOM, pero luego pierde la capacidad de especificar cualquier tipo de Formato dinámico en absoluto. A veces esto está bien, a veces no.
El script del lado del cliente nunca puede proteger contra las inyecciones de XSS que van al servidor. Como sugiere su nombre, XSS a menudo se inyecta en todos los sitios, por lo que el código del lado del cliente no puede detectar la inyección porque ni siquiera está sucediendo en su sitio (y, por lo tanto, el código del lado del cliente no se está ejecutando). El XSS almacenado a menudo se inyecta desde el sitio de destino, pero de nuevo, la validación del lado del cliente no ayudará; el atacante puede (y lo hará) deshabilitar la validación (controlan al cliente; controlan el código del lado del cliente que se ejecuta en él) o simplemente crea la solicitud HTTP maliciosa (POST o lo que sea) a la medida usando una herramienta como curl o Burp Suite .
Del mismo modo, el código del lado del cliente no puede proteger contra el contenido HTML / JS malintencionado devuelto por el servidor web en respuesta a una solicitud de página. Para cuando se están ejecutando las verificaciones de desinfección (o lo que sea), también lo es el código malicioso; ¡es demasiado tarde! Tiene que hacer toda su validación / escape / lo que sea antes de que el código llegue al motor de renderizado / JS. Solo hay dos formas de hacerlo: ejecutarlo en el lado del cliente en cadenas JS que luego agregará al contenido de la página (así es como funcionan Angular y sus amigos, pero no son infalibles) o hacerlo en el servidor .
- ¿Escapar? ¡Gran idea, debes hacer que tu servidor haga eso!
- lista negra? Una idea terrible, una pérdida de tiempo y una falsa sensación de seguridad.
- ¿Lista blanca? Una buena técnica de validación de entrada; debe hacer que su servidor haga esto.
- Si usted hace su lado del servidor de prevención XSS, entonces el navegador no sabe ni le importa. Todos los navegadores comprenden URL, HTML y escapes de JavaScript.
- No hay "estándares" para la seguridad de XSS, como tampoco existen "estándares" para la seguridad de la memoria de código nativo.
Del mismo modo, no hay batería de pruebas que valga la pena el tiempo que tomó compilarlas. Puede lanzar cada escáner automatizado que desee a su código, pero si solo construyó sus protecciones al nivel necesario para vencer a esos escáneres, un atacante inteligente probablemente los omitirá. Lo hago todo el tiempo. Los escáneres solo tienen dos salidas: vulnerable y tal vez vulnerable . No pueden decirte que estás a salvo.
No vayas por una cobertura mínima. No trates de ser lindo y hacer todo lo posible por el lado del cliente; ¡incluso si está utilizando algo como Angular, funciona bajo el supuesto de que es vulnerable y realice la validación de entrada y la codificación de salida en el servidor! En lugar de intentar protegerse contra amenazas conocidas y espero que obtenga Protección actualizada contra las futuras, haga que su servidor solo devuelva el código que se garantiza que es seguro. Por supuesto, ejecute un escáner, pero también contrate a alguien que sepa lo que está haciendo para probarlo de verdad, si le preocupa la seguridad.