En la programación defensiva, existen varias formas de comprobar que los datos introducidos por el usuario no crean problemas de seguridad en nuestro código. La más usual es suponer que los datos están contaminados (no son fiables) hasta que se pruebe lo contrario.
Nota: A falta de mejor traducción, usaré "contaminado" por "tainted".
El funcionamiento es bien sencillo:
- Marcamos los datos que introduce el (potencialmente maligno) usuario como contaminados.
- Marcamos los datos que introduce el (supuestamente competente) programador como no contaminados.
- Las funciones con las que trabaja el programa sólo deben permitir utilizar datos no contaminados.
- El programador debe definir, adicionalmente, ciertas funciones de comprobación de la validez de los datos y quita de contaminación.
De esta manera en el único sitio donde hay que mirar por si hay problemas de seguridad es en las funciones de "descontaminación". Generalmente son muy pocas.
El caso clásico es cuando se quieren detectar desbordamientos de búfer. Hasta que no comprobemos que la cadena ofrecida por el usuario cabe en el búfer, no descontaminamos esa cadena. Este simple mecanismo, de descontaminar cuando se hace una comprobación de la longitud, puede aplicarse automáticamente al código fuente con una herramienta externa. Incluso, cuando no se estén marcando como contaminados los datos en el programa.
El resultado es que se encuentran los puntos donde se usan cadenas introducidas por el usuario sin haber comprobado antes la longitud. Algunos de estos usos inseguros pueden explotarse para introducirse maliciosamente en nuestro sistema.
En definitiva, el simple método de marcar los datos (o los tipos de los datos si hacemos el análisis estático) como contaminados o no contaminados tiene una incidencia directa en la seguridad de nuestro programa. Algunos lenguajes lo hacen así, como Ruby. Otros, no.
0 comentarios:
Publicar un comentario