Principios de codificacin segura Sumario Arquitectos y proveedores de soluciones necesitan una gua para producir aplicaciones seguras por

diseo, y pueden hacerlo no slo implementando los controles bsicos documentados en el texto principal, sino tambin refirindose al subyacente Por qu? en esos principios. Los principios de seguridad tales como confidencialidad, integridad, y disponibilidad aunque son importantes, amplios y vagos no cambian. Su aplicacin ser ms robusta cuanto ms los aplique. Por ejemplo, es correcto cuando en una implementacin de validacin de datos se incluye una rutina de validacin centralizada para todas las entradas. Sin embargo, es mejor ver una validacin a cada nivel para todas las entradas del usuario, asociadas con un apropiado manejo de errores y un robusto control de accesos. En el ltimo ao ms o menos, ha habido un esfuerzo significante para estandarizar la terminologa y taxonoma. Esta versin de la gua ha normalizado sus principios con aquellos de los grandes textos de la industria, mientras se han abandonado un principio o dos presentes en la primera edicin de la Gua. Se ha hecho as para prevenir confusin e incrementar la conformidad con un conjunto de principios fundamentales. Los principios que han sido eliminados estn adecuadamente cubiertos por controles dentro del texto. Clasificacin de activos La seleccin de controles slo es posible despus de clasificar los datos a proteger. Por

ejemplo, controles aplicables a sistemas de bajo valor tales como blogs y foros son diferentes al nivel y nmero de controles adecuados para la contabilidad, sistemas de alto valor de banca y comercio electrnico Sobre los atacantes En el diseo de controles para prevenir el mal uso de su aplicacin, debe considerar los atacantes ms probables (en orden de posibilidades y prdidas actualizadas de ms a menos): Equipo o desarrolladores descontentos. Ataques Accionados por como efectos secundarios o consecuencias directas de un virus, o ataque de gusano o troyano. Error! No se le ha dado un nombre al marcador. 34 Atacantes criminales motivados, tales como el crimen organizado. Atacantes criminales contra tu organizacin sin motivo, como defacers. Script kiddies Fjese en que no existe una entrada para el trmino hacker. Esto es debido al emotivo e incorrecto uso de la palabra hacker por los medios. El trmino correcto es criminal. Los tpicos criminales atrapados y perseguidos por la polica son script kiddies, principalmente dado que las organizaciones no estn dispuestas a ir a la polica y ayudarles a poner cargos contra los delincuentes ms serios. Sin embargo, ya es demasiado tarde para reclamar el uso incorrecto de la palabra hacker e intentar devolver a la palabra su correcto origen. La gua usa la palabra atacante

consistentemente cuando se denota que algo o alguien est intentado activamente explotar una caracterstica particular. Pilares esenciales de la seguridad de la informacin La seguridad de la informacin se ha mantenido sobre los siguientes pilares: Confidencialidad permitir acceso nicamente a los datos a los cuales el usuario est permitido. Integridad asegurar que los datos no se falsifican o alteran por usuarios no autorizados. Disponibilidad asegurar que los sistemas y datos estn disponibles para los usuarios autorizados cuando lo necesiten. Los siguientes principios estn todos relacionados a esos tres pilares. En efecto, cuando se considera la construccin de un control, considerar cada pilar sucesivamente ayudar en la produccin de un robusto control de seguridad. Arquitectura de Seguridad Las aplicaciones sin una arquitectura de seguridad son como puentes construidos sin un anlisis finito de elementos ni tests de tneles de viento. Seguramente, parecern puentes, pero caern a la primera sacudida de las alas de una mariposa. La necesidad de la seguridad de aplicaciones en forma de arquitectura de seguridad es tan grande como en la construccin de puentes o edificios. Los arquitectos de aplicaciones son los responsables de su construccin y diseo para cubrir los tpicos riesgos tanto de uso como de ataques extremos. Los diseadores de puentes OWASP Guide 2.0

35 necesitan superar cierta cantidad de coches y trfico a pie, pero tambin ciclones, terremotos, fuegos, accidentes de trfico e inundaciones. Los diseadores de aplicaciones deben superar eventos extremos como fuerza bruta o ataques de inyeccin y fraude. Los riesgos de los diseadores de aplicaciones son bien conocidos. Los das de no lo sabamos ya han pasado. La seguridad ahora es algo esperado, y no un caro complemento o algo dejado de lado. La arquitectura de seguridad se refiere a los pilares fundamentales: la aplicacin debe proporcionar controles para proteger la confidencialidad de la informacin, integridad de los datos, y proporcionar acceso a los datos cuando se requiera (disponibilidad) y solamente a los usuarios apropiados. La arquitectura de seguridad no es una markitecture, donde una cornucopia de productos de seguridad son lanzados juntos y denominados como solucin, no son ms que un conjunto de caractersticas cuidadosamente consideradas, controles, procesos seguros, y una postura de seguridad por defecto. Cuando se empieza una nueva aplicacin o se redisea una aplicacin existente, debera considerar cada caracterstica funcional y tener en cuenta: Son los procesos de alrededor de esta caracterstica lo ms seguro posibles? En otras palabras, es este un proceso con defectos? Si fuera malvado, cmo abusara de esta caracterstica? Se requiere esta caracterstica que este activa por defecto? Si es as, existen lmites u opciones que ayuden a reducir el riesgo de esta caracterstica?

Andrew van der Stock llamo al proceso anterior Thinking Evil, y recomienda ponerse en el lugar de el atacante y pensar en todas las posibles vas en que se puede abusar de cada caracterstica, sin considerar los tres pilares bsicos y usando el modelo STRIVE sucesivamente. . Siguiendo esta gua, y usando el modelo de riesgo de amenazas STRIDE / DREAD discutido aqu y en el libro de Howard y LeBlanc, ir bien en su camino de adoptar formalmente una arquitectura de seguridad para sus aplicaciones. El mejor diseo de sistema de arquitectura y documentos de diseo detallados contienen discusiones de seguridad en cada caracterstica, cmo se van a reducir los riesgos, y cmo se haca actualmente la codificacin. La arquitectura de seguridad empieza el da en que se modelan los requisitos del negocio, y no termina nunca hasta que la ltima copia de su aplicacin es retirada. La seguridad es un proceso de larga vida y no un disparo por accidente. Error! No se le ha dado un nombre al marcador. 36 Principios de Seguridad Estos principios de Seguridad han sido tomados de la edicin previa de la gua OWASP y se han normalizado con los principios de seguridad perfilados en el excelente libro Escribiendo cdigo seguro de Howard y LeBlanc. Minimizando el rea de la superficie de ataque Cada caracterstica que se aade a una aplicacin aade una cierta cantidad de riesgo a la aplicacin total. El objetivo del desarrollo seguro es reducir el total del riesgo reduciendo el rea

de la superficie de ataque. Por ejemplo, una aplicacin web implementa ayuda online con una funcin de bsqueda. La funcin de bsqueda puede ser vulnerable a ataques de inyeccin SQL. Si la caracterstica de ayuda se hubiera limitado a usuarios autorizados, la probabilidad del ataque se hubiera reducido. Si la caracterstica de ayuda de la funcin de bsqueda fuera introducida a travs de rutinas de validacin de datos centralizadas, la habilidad para realizar ataques de inyeccin SQL se hubiera reducido dramticamente. Sin embargo, si la caracterstica de ayuda fuera re-escrita para eliminar la funcin de bsqueda (por una interfaz de usuario mejorada, por ejemplo), esto eliminara al menos el rea de ataque, incluso si la caracterstica de ayuda estuviera disponible para toda Internet. Seguridad por defecto Hay muchas maneras de entregar una experiencia out of the box a los usuarios. Sin embargo, por defecto, la experiencia debera ser segura, y debera depender del usuario el reducir su seguridad si les est permitido. Por ejemplo, por defecto, debe habilitarse la complejidad de la contrasea y su duracin. A los usuarios se les puede permitir deshabilitar esas dos caractersticas para simplificar su uso de la aplicacin e incrementar su riesgo. Principio del mnimo privilegio El principio del mnimo privilegio recomienda que las cuentas tengan la mnima cantidad de privilegios necesarios para realizar sus procesos de negocio. Esto abarca a los derechos de

usuario, permisos de recursos tales como lmites de CPU, memoria, red y permisos del sistema de ficheros. OWASP Guide 2.0 37 Por ejemplo, si un servidor middleware requiere acceso slo a la red, acceso de lectura a la tabla de una base de datos, y la habilidad para escribir en un log, esto describe todos los permisos que deben concederse. Bajo ninguna circunstancia debera darse privilegios administrativos al middleware. Principio de defensa en profundidad El principio de defensa en profundidad sugiere que donde con un control sera razonable, ms controles contra diferentes tipos de riesgo seran mayores. Los controles, cuando se utilizan en profundidad, pueden hacrselo extraordinariamente difcil a severas vulnerabilidades y por lo tanto con poca probabilidad de que ocurran. Con la codificacin segura, esto puede tomar la forma de validacin basada en filas, controles de auditoria centralizados, y requerir a los usuarios hacer login en todas las pginas. Por ejemplo, una interfaz administrativa con defectos es poco probable que sea vulnerable a ataques annimos si incorpora el acceso correctamente a redes de administracin en produccin, chequea la autorizacin administrativa del usuario, y hace log de todos los accesos. Fallar de manera segura Las aplicaciones fallan regularmente al procesar transacciones debido a diversas razones. De

la manera en que fallan se puede determinar si una aplicacin es segura o no. Por ejemplo: isAdmin = true; try { codeWhichMayFail(); isAdmin = isUserInRole( Administrator ); } catch (Exception ex) { log.write(ex.toString()); } S el cdigo codeWhichMayFail() falla, el usuario es administrador por defecto. Obviamente esto es un riesgo de seguridad. Los sistemas externos son inseguros Diversas organizaciones utilizan las capacidades de procesamiento de terceras compaas, las cuales ms que a menudo tienen diferentes polticas de seguridad y posturas que la suya. Es Error! No se le ha dado un nombre al marcador. 38 poco probable que pueda controlar o influenciar en una tercera parte externa, si ellas son usuarios domsticos o grandes suministradores o socios. De ah que, la confianza implcita de ejecutar sistemas externos, no est garantizada. Todos los sistemas externos deberan ser tratados de un modo similar. Por ejemplo, un fiel proveedor de programas proporciona datos que son utilizados para la Banca en Internet, proporciona el nmero de puntos de premio y una pequea lista de objetos potenciales de reembolso. Sin embargo, los datos deberan ser comprobados para asegurarse que

es seguro mostrarlo al usuario final, y que los puntos de premio son un nmero positivo, y no improbablemente largo. Separacin de funciones Un control clave del fraude es la separacin de funciones. Por ejemplo, alguien que solicita un ordenador no puede anunciarlo tambin, no debera recibir directamente el ordenador. Esto previene que el usuario solicite varios ordenadores y reclame que nunca le llegaron. Ciertos roles tienen niveles diferentes de confianza que los usuarios normales. En particular, los administradores son diferentes que los usuarios normales. En general, los administradores no deberan ser usuarios de la aplicacin. Por ejemplo, un administrador debera ser capaz de apagar y encender el sistema, configurar polticas de contraseas pero no debera ser capaz de hacer login en la aplicacin como un super usuario privilegiado, que fuera capaz de comprar objetos en nombre de otros usuarios. No confes en la seguridad a travs de la oscuridad La seguridad a travs de la oscuridad es un control de seguridad dbil, y adems siempre fallan cuando son el nico control. Esto no significa que mantener secretos es una mala idea, significa simplemente que la seguridad de los sistemas clave no debera basarse en mantener detalles ocultos. Por ejemplo, la seguridad de una aplicacin no debera basarse en mantener en secreto el conocimiento del cdigo fuente. La seguridad debera basarse en muchos otros factores,

incluyendo polticas razonables de contraseas, defensa en profanidad, lmites en las transacciones de negocios, arquitectura de red slida, y controles de auditoria y fraude. Un ejemplo prctico es Linux. El cdigo fuente de Linux est ampliamente disponible, y an as est asegurado apropiadamente. Linux es un sistema operativo resistente, seguro y robusto. OWASP Guide 2.0 39 Simplicidad El rea de la superficie de ataque y la simplicidad van de la mano. Ciertos ingenieros de software prefieren aproximaciones demasiado complejas hacia lo que de otra manera sera un cdigo relativamente sencillo y simple. Los desarrolladores deben evitar el uso de dobles negaciones y complejas arquitecturas en donde un enfoque simple sera ms rpido y simple. Por ejemplo, aunque pueda estar a la ltima tener unas cuantas entidades sencillas ejecutndose en un servidor separado, es ms seguro y rpido usar simplemente variables globales con un mecanismo apropiado de mutex para proteger contra las condiciones de carrera. Arreglar cuestiones de seguridad correctamente Una vez que un fallo de seguridad ha sido identificado, es importante desarrollar un test para l y comprender la raz del problema. Cuando se usan los patrones de diseo, es muy probable que el fallo de seguridad se encuentre muy extendido en todo el cdigo base, por lo que desarrollar la solucin correcta sin introducir regresiones es esencial.

Por ejemplo, un usuario ha visto que es capaz de ver las cuentas de otro usuario simplemente ajustando su cookie. La solucin parece ser relativamente sencilla, pero como el manejo de la cookie es compartido entre todas las aplicaciones, un cambio en una simple aplicacin repercutir en todas las dems. La solucin por lo tanto debe testearse en todas las aplicaciones afectadas.