Instrucciones para escribir código seguro
Actualización: noviembre 2007
Las instrucciones siguientes proporcionan varias técnicas para escribir código seguro.
Se requiere
Utilice las herramientas de análisis de código.
Visual Studio Team System Development se distribuye con herramientas de análisis del código que pueden aumentar en gran medida la posibilidad de encontrar errores de seguridad en el código. Estas herramientas encuentran errores ocultos con mayor eficacia y menos esfuerzo. Para obtener más información, vea Detectar y corregir defectos de código de C/C++ y Detectar y corregir defectos de código administrado.
Realice una revisión de seguridad.
El objetivo de toda revisión de seguridad es mejorar la seguridad de los productos que ya se han lanzado (mediante revisiones y correcciones) o garantizar que no se distribuya ningún producto nuevo hasta que sea lo más seguro posible.
No revise el código de forma aleatoria. Prepare de antemano la revisión de seguridad y comience por crear un modelo exhaustivo de amenazas. Si no hace, puede desperdiciar mucho tiempo de su equipo. Dé prioridad al código que debe recibir la revisión de seguridad más intensa e indique qué errores de seguridad hay que buscar.
Sea concreto en cuanto a lo que se debe buscar durante una revisión de seguridad. Cuando se buscan problemas concretos, normalmente se encuentran. Examínelo con mayor atención si el equipo encuentra varios errores de seguridad en una sección; probablemente indique que existe un problema de arquitectura que hay que solucionar. Si no encuentra ningún error de seguridad, normalmente significa que la revisión de seguridad no se realizó correctamente.
Realice revisiones de seguridad como parte de la estabilización de cada hito y de la inserción de líneas de productos mayores establecidas por la dirección.
Utilice una lista de comprobación de revisión de código para mayor seguridad.
Independientemente de la función que desempeñe en el equipo de desarrollo de software, resulta de gran utilidad disponer de una lista de comprobación que seguir a fin de garantizar que el diseño y el código cumplen los requisitos mínimos.
Valide todos los datos introducidos por los usuarios.
Si permite que la aplicación acepte datos proporcionados por los usuarios, directa o indirectamente, debe validar esos datos antes de utilizarlos. Los usuarios malintencionados intentarán provocar errores en la aplicación manipulando los datos de modo que representen datos no válidos. La primera regla para los datos introducidos por el usuario es: todos los datos son erróneos hasta que se demuestre lo contrario.
Extreme las precauciones cuando utilice expresiones regulares para validar los datos introducidos por el usuario. Para expresiones complejas como las direcciones de correo electrónico, es fácil pensar que se efectúa una validación completa cuando no es así. Pida a sus compañeros que revisen todas las expresiones regulares.
Valide perfectamente todos los parámetros de las interfaces de programación de aplicaciones (API) exportadas.
Asegúrese de que todos los parámetros de las API exportadas son válidos. Esto incluye los datos que parecen ser coherentes pero que están más allá del intervalo de valores aceptado, como los tamaños búfer excesivos. No utilice aserciones para comprobar los parámetros de las API exportadas, porque las aserciones se quitarán en la versión de lanzamiento.
Utilice las API criptográficas de Windows.
En lugar de escribir a su propio software criptográfico, utilice la API criptográfica de Microsoft, que ya está disponible. Al utilizar una API criptográfica de Microsoft, los desarrolladores quedan libres para concentrarse en la generación de aplicaciones. Recuerde: el cifrado resuelve muy bien un reducido conjunto de problemas y se utiliza con frecuencia de maneras para las que no está diseñado. Para obtener más información, vea Información general sobre criptografía en MSDN Library.
Se debe evitar
Las saturaciones del búfer.
Una saturación del búfer estática se produce cuando un búfer declarado en la pila se sobrescribe porque se copian datos más grandes que él. Las variables declaradas en la pila se ubican junto a la dirección de devolución del llamador de la función. Las saturaciones del búfer también pueden aparecer en el montón y son igualmente peligrosas. Normalmente, la causa suele residir en datos introducidos por el usuario que se pasan a una función como strcpy, con el resultado de que la dirección de devolución de la función se sobrescribe por una dirección elegida por el atacante. Para evitar las saturaciones del búfer, es fundamental escribir una aplicación robusta.
Aserciones para la comprobación de los datos externos.
Las aserciones no se compilan en las versiones de lanzamiento. No utilice aserciones para comprobar los datos externos. Todos los parámetros de las funciones y los métodos exportados, todos los datos introducidos por el usuario y todos los datos de los archivos y socket deben verificarse atentamente para comprobar su validez, y rechazarse si hay algún error.
Combinaciones de Id. de usuario y contraseña dentro del código.
No utilice contraseñas contenidas dentro del código. Modifique el instalador para que, al crear las cuentas de usuario integradas, se soliciten al administrador contraseñas seguras para cada cuenta. De esta manera, se puede mantener la seguridad de los sistemas de nivel de producción del cliente.
Utilizar el cifrado para resolver todos los problemas de seguridad.
El cifrado resuelve muy bien un reducido conjunto de problemas y se utiliza con frecuencia de maneras para las que no está diseñado.
Rutas de acceso a archivos y direcciones URL canónicas.
Evite situaciones donde sea importante la ubicación de un archivo o una dirección URL. Utilice ACL del sistema de archivos en lugar de reglas basadas en nombres de archivo canónicos.
Se recomienda
Revise todos los defectos de seguridad anteriores de la aplicación.
Conozca bien los errores de seguridad que ha cometido en el pasado. Con frecuencia, el código se escribe basándose en la repetición de modelos. Por consiguiente, un error en una ubicación de una persona podría indicar que existe el mismo error en otras ubicaciones de otras personas.
Revise todas las rutas de acceso a errores.
A menudo, el código de las rutas de errores no se prueba bien y no limpia todos los objetos, como los bloqueos o la memoria asignada. Revise con atención estas rutas de errores y, si es preciso, cree pruebas de inserción de errores para ejecutar el código.
No se recomienda
Privilegios de administrador para que se ejecute la aplicación.
Las aplicaciones deben ejecutarse con el menor privilegio necesario para realizar el trabajo. Si un usuario detecta una vulnerabilidad de seguridad e inserta código en el proceso, este código malintencionado se ejecutará con los mismos privilegios que el proceso de host. Si el proceso se ejecuta como administrador, el código malintencionado se ejecuta como administrador. Para obtener más información, vea Developing Secure Applications en MSDN Library.