Limitar el último XSS basado en dom al configurar document.title

5

Dado algo de JavaScript que modifica el título de la página tomando datos variables

document.title = someVariable

Estoy buscando dirigir XSS basado en dom mientras mantengo el título bastante legible. Por lo tanto, hacer algo como escape() o encodeURI() no funcionará.

No necesariamente tengo control sobre cómo se puede usar el document.title en otros scripts, por lo que quiero asegurarme de que hago un poco de desinfección en la materia de menor destrucción, pero evito posibles escenarios donde la forma en que la variable se procesa más tarde posiblemente podría ser descodificado de tal manera que se convierta en XSS.

Mis primeros pensamientos fueron algo como esto:

someVariable = someVariable.replace('<script', 'noscript');
someVariable = someVariable.replace(/[<>'"]/g, '').replace(/%3[CEce]/, '');
document.title = someVariable;

Lo que es mínimamente destructivo desde el punto de vista de la legibilidad, eliminar estos caracteres podría romper el código posterior, pero preferiría dividir el código en favor de la seguridad.

Siento que estoy rodando por mi cuenta aquí, así que me gustaría saber si hay un mejor enfoque que cumpla con los requisitos de legibilidad. Si no, ¿hay otros filtros o desinfección recomendados?

    
pregunta Eric G 20.02.2015 - 05:39
fuente

2 respuestas

1

Si necesita para adoptar este enfoque, ¿por qué no elimina todo aparte de los caracteres alfanuméricos y del espacio? es decir, ir para una lista blanca en lugar de una lista negra. Usted no sabe cómo pueden cambiar los estándares en HTML y JavaScript en el futuro, por lo que solo permita que los caracteres sean buenos en lugar de rechazar los malos conocidos.

  

No necesariamente tengo control sobre cómo se puede usar el document.title en otros scripts, por lo que quiero asegurarme de que hago algo de desinfección en la materia de menor destrucción, pero evito posibles escenarios en los que la forma en que se procesa la variable posteriormente posiblemente podría ser descodificado de tal manera que este último se convierta en XSS.

Mi pregunta para usted es ¿quién tiene control? Por supuesto, la forma correcta de manejar esto es generar correctamente la codificación cuando se envía a la página. Solo me pregunto por qué esta no es una solución aceptable para su sistema. Si no puede controlar otros scripts, ¿cómo sabe que están protegidos de otra manera?

Reemplazar <script> no detiene la incrustación de scripts. Hay muchas otras formas de inyectar guiones. por ejemplo

<img src="x" onerror="alert('xss')" />
    
respondido por el SilverlightFox 21.02.2015 - 18:10
fuente
0

La mejor solución sería poner en una lista negra ciertos caracteres y secuencias (recursivamente). Todo depende de la facilidad de uso que estés dispuesto a sacrificar por la seguridad. Puede poner etiquetas de secuencias de comandos en la lista negra y alguien puede usar img src = # onerror, etc. No puede hacer nada si no se esperan estas secuencias pero, nuevamente, no sé el uso de su aplicación.

Creo que lo que estás haciendo no es bueno, pero es el mejor enfoque posible aquí.

    
respondido por el user3632719 29.06.2015 - 05:16
fuente

Lea otras preguntas en las etiquetas