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 (1)

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 (4)

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.
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 (2)

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 (3)

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.

Separacin de funciones(5)
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(8)

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.

Simplicidad(6)
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.

Los sistemas externos son inseguros(10)

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 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.
https://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanish.pdf