Contaminación de prototipo: una amenaza infravalorada

Aunque en algunos sitios hablan de la contaminación de prototipo como una nueva técnica de ataque a sitios web, en realidad esa novedad es relativa, pues ya en 2018 es posible encontrar algún CVE, como éste que afectaba a lodash. Más sonado fue cuando, el año pasado, se detectó un problema similar en jQuery. Lo que no se mencionó tanto en aquel momento es que, en realidad, era la segunda incidencia del mismo tipo, y que la anterior había tenido lugar tres años antes. Por lo tanto, y a la vista de las fechas, en realidad hablamos de un problema identificado desde hace ya bastante tiempo.

Si no lo conoces debes saber que Javascript se basa en emplea la herencia, de modo que cuando se crea un nuevo objeto, éste adquiere por defecto las propiedades del modelo en el que se basa, que es el prototipo. Obviamente, en el momento en el que, ya sea durante desarrollo o en tiempo de ejecución, se asignan valores concretos a dichas propiedades, las heredadas del prototipo son eliminadas. Que el nuevo objeto no venga «vacío», y que el desarrollador pueda emplear el prototipo para realizar ajustes una única vez, y no por cada objeto, aportan bastante agilidad al desarrollo.

El problema que plantea la contaminación de prototipo es que un actor malintencionado puede evitarse atacar a un objeto concreto del código y, en su lugar, apuntar hacia el prototipo, en el que centrará sus esfuerzos. Y tiene todo el sentido del mundo, porque la modificación del objeto puede tener un alcance limitado, mientras que la del prototipo proporciona un alcance más global, pues llega a todos los objetos que estén heredando propiedades del mismo.

Y la contaminación de prototipo, si no es detectada, ofrece otra ventaja adicional frente a la modificación de los objetos de manera individual, y es que la herencia de las propiedades del mismo no solo se aplicará a los objetos ya existentes, sino también a los que se puedan añadir en el futuro. Mientras que el prototipo permanezca contaminado, todos los objetos, presentes y futuros, se verán comprometidos por este problema.

No hablamos, en puridad, de una técnica de ataque especialmente novedosa, al fin y al cabo la inyección de código lleva ya muchos años estando presente. La particularidad de la contaminación de prototipo es que afecta a un contexto muy específico, los frameworks de desarrollo de Javascript. Además, y hasta 2018, e incluso en algunas discusiones de 2019, se dudaba de si era un problema de seguridad que afectaba solo al frontend (clientside) o, por el contrario, también podía tener efectos en el backend (serverside). Esto ha propiciado que, pese a ser una amenaza muy seria, se haya subestimado, quedando un tanto fuera del radar.

A estas alturas, sin embargo, ya no hay dudas sobre la incidencia que puede tener la contaminación de prototipo en el lado del servidor, se ha podido comprobar, por ejemplo, que la contaminación de prototipo se puede emplear para llevar a cabo un ataque de denegación de servicio apoyado en NodeJS, otro popular framework de Javascript.

Con respecto a las soluciones, y dado que el ataque se efectúa en el lado del cliente, una de las principales recomendaciones es limitar al máximo las posibilidades de entrada del del usuario. Establecer límites férreos en qué objetos, y de qué manera pueden ser modificados por los mismos, es a día de hoy la principal manera de combatir el riesgo que plantea la contaminación de prototipo. Y es que otras opciones, como la revisión individual de todos los tipos de objetos que se pueden ver comprometidos, se escapa (por volumen de trabajo) a la inmensa mayoría.

Con información de The Daily Swig