Octubre 2011

Copyright and License

Copyright 2011 The OWASP Foundation.

This document is released under the Creative Commons Attribution ShareAlike 3.0 license. For any reuse or distribution, you must make clear to others the license terms of this work.http://creativecommons.org/licenses/by-sa/3.0/OWASP Secure Coding PracticesQuick Reference Guide

Sobre esta versin en espaolEsta versin de la Gua de referencia rpida en espaol ha sido desarrollada como parte de las actividades del captulo OWASP Uruguay para la comunidad de desarrolladores y seguridad informtica de habla hispana.Participaron de esta traduccin:

Canedo,GerardoFlores,MauroHill,AlbertoMartinez,MateoPapaleo,MauricioSoarez,NicolsTargetta, Cecilia

ndicendice2Introduccin4Visin General de la Seguridad en el Software y sus Principales Riesgos5Lista de Verificacin de Prcticas de Codificacin Segura7Validacin de entradas7Codificacin de salidas8Administracin de autenticacin y contraseas8Administracin de sesiones10Control de Acceso11Prcticas Critpogrficas12Manejo de errores y Logs12Proteccin de datos13Seguridad en las comunicaciones13Configuracin de los sistemas14Seguridad de Base de Datos15Manejo de Archivos15Manejo de Memoria16Practicas Generales para la Codificacin16Apndice A:18Referencias externas18Sitios recomendados sobre Seguridad18Apndice B: Glosario19

IntroduccinEl presente documento define un conjunto de prcticas comunes de codificacin de software, tecnolgicamente agnsticas, en formato de lista de verificacin con el fin de ser integrado al ciclo de desarrollo. La implementacin de estas prcticas mitiga las vulnerabilidades ms comunes del software.

En trminos generales, es mucho menos costoso construir software seguro que corregir problemas de seguridad cuando ha sido completado, sin mencionar los costos que pueden estar asociados a un quiebre en la seguridad.

Asegurar recursos crticos de software se ha vuelto ms importante que nunca debido a que el foco de los atacantes se ha desplazado hacia la capa de aplicacin. Un estudio en 2009 de la SANS1 determin que los ataques contra aplicaciones web constituyen ms del 60% del total de intentos de ataque observados en la Internet.

Utilizando la presente gua, el equipo de desarrollo debera comenzar evaluando el grado de madurez de su ciclo de desarrollo de software desde el punto de vista de la seguridad, as como el nivel de conocimiento de sus miembros. Dado que esta gua no cubre los detalles de implementacin de las prcticas de codificacin, los desarrolladores deben poseer previamente los conocimientos suficientes o bien tener disponibles recursos que los guen. Esta gua provee prcticas de codificacin que pueden ser traducidas en requisitos de codificacin sin la necesidad que el desarrollador posea un entendimiento profundo de vulnerabilidades de seguridad y exploits. Sin embargo, otros miembros del equipo de desarrollo deberan de poseer el entrenamiento adecuado, recursos y herramientas para ser responsables y validar que el diseo e implementacin del sistema es seguro.

En el apndice B se presenta un glosario de los trminos ms importantes utilizados en este documento, incluyendo los cabezales de seccin y las palabras resaltadas con itlicas.

Se encuentra fuera del alcance de este documento la informacin detallada de cmo implementar un proceso de desarrollo de software seguro, sin embargo, se recomiendan las siguientes prcticas y recursos: Definir claramente roles y responsabilidades. Proveer al equipo de desarrollo capacitacin suficiente en el rea de seguridad del software. Implementar un ciclo de desarrollo de software seguro. OWASP CLASP Project Establecer estndares de codificacin segura. OWASP Development Guide Project Construir una biblioteca de objetos reutilizable. OWASP Enterprise Security API (ESAPI) Project Verificar la efectividad de los controles de seguridad. OWASP Application Security Verification Standard (ASVS) Project Establecer prcticas de seguridad por fuera del ciclo de desarrollo, incluyendo requerimientos de seguridad y metodologas de verificacin tanto en los request for proposal (RFP) como en los contratos. OWASP Legal Project

Visin General de la Seguridad en el Software y sus Principales RiesgosLa construccin de software seguro requiere una comprensin bsica de los principios de seguridad. Si bien escapa al objetivo de esta gua una revisin exhaustiva de estos, se proporciona una visin general y rpida de los mismos.

El objetivo de la seguridad en el software es el de mantener la confidencialidad, integridad y disponibilidad de los recursos de informacin de modo de permitir el desarrollo exitoso de negocios. Este objetivo se consigue con la implementacin de controles de seguridad. La presente gua pone foco en los controles tcnicos especficos para mitigar la presencia de vulnerabilidades de ocurrencia frecuentes en el software. Si bien el foco principal est en las aplicaciones web y la infraestructura que las soporta, la mayora de los consejos puede aplicarse en cualquier plataforma de desarrollo de software.

Es de gran utilidad comprender qu se entiende por un riesgo, con el fin de proteger al negocio de riesgos inaceptables derivados de su dependencia en el software. Un riesgo es una combinacin de factores que amenazan al xito del negocio. Puede ser definido conceptualmente como: un agente amenazante que interacta con el sistema, que puede tener una vulnerabilidad a ser explotada de forma de generar un impacto.

Si bien este puede resultar un concepto abstracto, se lo puede pensar de esta forma: un ladrn de autos (agente amenazante) recorre un estacionamiento verificando los vehculos (el sistema) en busca de una puerta sin trabar (la vulnerabilidad) y cuando encuentra uno, abre la puerta (situacin a ser explotada) y toma algo de dentro del mismo (el impacto). Todos estos factores juegan un rol en el desarrollo de software seguro.

Existe una diferencia fundamental entre el enfoque que adopta un equipo de desarrollo y el que toma alguien que est realizando un ataque sobre la aplicacin. Un equipo de desarrollo adopta un enfoque basado en lo que tiene intenciones de realizar. En otras palabras, estn diseando una aplicacin para que realice tareas especficas basndose en los requerimientos funcionales y casos de uso que han sido documentados. Un atacante, por otra parte, est ms interesado en lo que puede llegar a hacerse con esa aplicacin y opera bajo el principio de cualquier accin que no haya sido denegada de forma expresa, est permitida.

Para hacer frente a esto, se deben integrar algunos elementos adicionales en las etapas tempranas del ciclo de desarrollo de software. Estos nuevos elementos son los requerimientos de seguridad y los casos de abuso. Esta gua fue creada para ayudar a identificar requerimientos de seguridad de alto nivel y hacer frente a muchos escenarios de abuso comunes.

Es importante que los equipos de desarrollo web entiendan que los controles desde el lado del cliente, tales como la validacin de lo que ingresa el cliente, campos ocultos y controles en la interfaz (por ejemplo: mens desplegables y botones de opcin) brindan poco si acaso algn beneficio desde el punto de vista de la seguridad. Un atacante puede utilizar herramientas tales como proxies del lado del cliente (por ejemplo: WebScarab o Burp de OWASP) o herramientas de capturas de paquetes de red (como WireShark) para analizar el trfico de la aplicacin y enviar solitudes hechas a medida, sin siquiera pasar por la interfaz. Adems de esto, Flash, Applets de Java y otros objetos del lado del cliente pueden ser descompilados y analizados en busca de fallas.

Las fallas de seguridad en el software pueden introducirse en cualquiera de las etapas del ciclo de desarrollo del software, derivados de: No identificar requerimientos de seguridad desde el inicio. Crear diseos conceptuales que contengan errores en la lgica. Utilizar prcticas dbiles de codificacin que introduzcan vulnerabilidades desde el punto de vista tcnico. Implantacin del software de forma inapropiada. Introduccin de fallas durante el mantenimiento o actualizacin del producto.

Es importante adems entender que las vulnerabilidades del software pueden escapar los lmites del software mismo. Dependiendo de la naturaleza del software, la vulnerabilidad y la infraestructura que da soporte, el impacto del xito en la intromisin puede comprometer a cualquiera o todas de las siguientes: El software y su informacin asociada. Los sistemas operativos de los servidores asociados. La base de datos del backend. Otras aplicaciones en el entorno compartido. El sistema del usuario. Otro software con el que interacte el usuario.

Lista de Verificacin de Prcticas de Codificacin SeguraValidacin de entradas Realizar todas las validaciones de datos en un sistema confiable (por ejemplo: el servidor). Identificar todas las fuentes de datos y clasificarlos como confiables o no confiables. Validar todos los datos provenientes de fuentes no confiables (por ejemplo: bases de datos, secuencias de archivo, etc.). Debera existir una rutina de validacin de datos de entrada centralizada para la aplicacin. Especificar sets de caracteres apropiados, tales como UTF-8, para todas las fuentes de entrada. Codificar los datos a un set de caracteres comn antes de validar (Canonicalizacin). Todas las fallas en la validacin deber terminar en el rechazo del dato de entrada. Determinar si el sistema soportar sets de caracteres UTF-8 extendidos y de ser as, validarlos luego de terminada la decodificacin del UTF-8. Validar todos los datos brindados por el cliente antes de procesarlos, incluyendo todos los parmetros, URLs y contenidos de cabeceras HTTP (por ejemplo nombres de Cookies y valores). Asegurarse de incluir post backs automticos desde JavaScript, Flash u otro cdigo embebido. Verificar que los valores de la cabecera tanto en solicitudes como en respuestas contengan solo caracteres ASCII. Validar datos redireccionados (un atacante puede enviar contenido malicioso directamente en el destino de la redireccin, eludiendo entonces la lgica de la aplicacin y cualquier otra validacin realizada antes de la redireccin). Validar tipos de datos no esperados. Validar rangos de datos. Validar largos de datos. Validar toda entrada con una lista blanca que contenga una lista de caracteres aceptados, siempre que sea posible. Si es necesario, permitir el ingreso de algn carcter considerado peligroso, asegrese de implementar controles adicionales tales como la codificacin de la salida, API de seguridad y el registro del uso de tales datos a lo largo de la aplicacin. Entre los ejemplos de caracteres peligrosos podemos encontrar: < > % ( ) & + \ / \ \. Si su rutina estndar de validacin no contempla el ingreso de los ejemplos de datos anteriormente ejemplificados, entonces debern verificarse de forma puntual. Compruebe si hay bytes nulos (%00). Compruebe si hay caracteres de nueva lnea (%0d, %0a, \r, \n). Compruebe si hay caracteres de alteraciones de ruta punto, punto, barra (../ o ..\). En los casos en que se soportan sets de caracteres UTF-8 extendidos, implemente representaciones alternativas tales como: %c0%ae%c0%ae/ (utilice la canonicalizacin como forma de implementar la doble codificacin u otras formas de ofuscacin de ataques).

Codificacin de salidas Realice toda la codificacin en un ambiente seguro (por ejemplo: el servidor). Utilice una rutina probada y estndar para cada tipo de codificacin de salida. Contextualice la codificacin de salida de todos los datos devueltos por el cliente que se originen desde fuera de la frontera de confianza de la aplicacin. La codificacin de entidades HTML es un ejemplo, aunque no sea suficiente en todos los casos. Codifique todos los caracteres salvo que sean reconocidos como seguros por el interpretador al que estn destinados. Sanitice contextualmente todos las salidas de datos no confiables hacia consultas SQL, XML y LDAP. Sanitice todas las salidas de datos no confiables hacia un comando del sistema operativo.

Administracin de autenticacin y contraseas Requerir autenticacin para todos los recursos y pginas excepto aquellas especficamente clasificadas como pblicas. Todos los controles de autenticacin deben ser efectuados en un sistema en el cual se confe. (por ejemplo: el servidor). Establecer y utilizar servicios de autenticacin estndares y probados cuando sea posible. Utilizar una implementacin centralizada para todos los controles de autenticacin, incluyendo libreras que llamen a servicios externos de autenticacin. Segregar la lgica de la autenticacin del recurso solicitado y utilizar redireccin desde y hacia el control centralizado de autenticacin. Todos los controles de autenticacin deben fallar de una forma segura. Todas las funciones administrativas y de administracin de cuentas deben ser al menos tan seguras como el mecanismo primario de autenticacin. Si la aplicacin administra un almacenamiento de credenciales, se debe asegurar que nicamente se almacena el hash con sal (salty hash) de las contraseas y que el archivo/tabla que guarda las contraseas y claves solo puede ser escrito por la aplicacin (si es posible, no utilizar el algoritmo de hash MD5). El hash de las contraseas debe ser implementado en un sistema en el cual se confe. (por ejemplo: el servidor). Validar los datos de autenticacin nicamente luego haber completado todos los datos de entrada, especialmente en implementaciones de autenticacin secuencial. Las respuestas a los fallos en la autenticacin no deben indicar cual parte de la autenticacin fue incorrecta. A modo de ejemplo, en lugar de usuario invalido o contrasea invalida, utilizar usuario y/o contrasea invlidos en ambos casos. Las repuestas a los errores deben ser idnticas tanto a nivel de lo desplegado como a nivel de cdigo fuente. Utilizar autenticacin para conexiones a sistemas externos que involucren informacin o funciones sensibles. Las credenciales de autenticacin para acceder a servicios externos a la aplicacin deben ser encriptados y almacenados en ubicaciones protegidas en un sistema en el cual se confe (ejemplo: el servidor). El cdigo fuente NO es una ubicacin segura. Utilizar nicamente pedidos del tipo HTTP POST para la transmisin de credenciales de autenticacin. Utilizar nicamente conexiones encriptadas o datos encriptados para el envo de contraseas que no sean temporales (por ejemplo: correo encriptado). Contraseas temporales como aquellas asociadas con reseteos por correo electrnico, pueden ser una excepcin. Hacer cumplir por medio de una poltica o regulacin los requerimientos de complejidad de la contrasea. Las credenciales de autenticacin deben ser suficientes como para resistir aquellos ataques tpicos de las amenazas en el entorno del sistema. Ej: obligar el uso de combinaciones de caracteres numricos/alfanumricos y/o caracteres especiales. Hacer cumplir por medio de una poltica o regulacin los requerimientos de longitud de la contrasea. Comnmente se utilizan ocho caracteres, pero diecisis es mejor, adicionalmente considerar el uso de frases de varias palabras. No se debe desplegar en la pantalla la contrasea ingresada. A modo de ejemplo, en formularios web, utilizar el tipo de entrada password (input type password). Deshabilitar las cuentas luego de un nmero establecido de intentos invlidos de ingreso al sistema. A modo de ejemplo, cinco intentos fallidos es lo comn. La deshabilitacin de la cuenta debe ser por un periodo de tiempo suficiente como para desalentar una inferencia de credenciales por fuerza bruta, pero no tan alto como para permitir un ataque de negacin de servicio. El cambio y reseteo de contraseas requieren los mismos niveles de control como aquellos asociados a la creacin y autenticacin de cuentas. Las preguntas para el reseteo de contraseas deben contemplar un amplio rango de respuestas aleatorias. A modo de ejemplo: libro favorito? es una mala pregunta dado que la biblia es una respuesta muy comn. Si se utiliza un reseteo por correo electrnico, nicamente enviar un link o contraseas temporales a casillas previamente registradas en el sistema. Las contraseas y links temporales deben tener un corto periodo de validez. Forzar el cambio de contraseas temporales luego de su utilizacin. Notificar a los usuarios cada vez que se produce un reseteo de contrasea. Prevenir la reutilizacin de contraseas. Las contraseas deben tener al menos un da de antigedad antes de poder ser cambiadas, de forma de evitar ataques de reutilizacin de contraseas. Hacer cumplir por medio de una poltica o regulacin los requerimientos de cambio de contrasea. Los sistemas crticos pueden requerir cambios ms frecuentes que otros sistemas. El tiempo entre cada reseteo debe ser controlado administrativamente. Deshabilitar la funcionalidad de recordar campos de contraseas. El ltimo acceso (fallido o exitoso) debe ser reportado al usuario en su siguiente acceso exitoso. Implementar un monitoreo para identificar ataques a mltiples cuentas utilizando la misma contrasea. Este patrn de ataque es utilizado parar superar bloqueos estndar cuando los nombres de usuario pueden ser obtenidos o adivinados de alguna forma. Cambiar todos los usuarios y contraseas por defecto o deshabilitar las cuentas asociadas. Re autenticar usuarios antes de la realizacin de operaciones crticas. Utilizar autenticacin multi-factor para las cuentas ms sensibles o de mayor valor. Si se utiliza un cdigo de una tercera parte para la autenticacin, inspeccionarlo minuciosamente para asegurar que no se encuentre afectado por cualquier cdigo malicioso.

Administracin de sesiones Utilizar los controles del servidor o del framework para la administracin de sesiones. La aplicacin solo debe reconocer estos identificadores como vlidos. La creacin de identificadores de sesin solo debe ser realizada en un sistema en cual se confe (por ejemplo: el servidor). Los controles de administracin de sesiones deben utilizar algoritmos que generen identificadores suficientemente aleatorios. Definir el dominio y ruta para las cookies que contienen identificadores de sesin autenticados con un valor apropiadamente estricto para el sitio. La funcin de logout debe terminar completamente con la sesin o conexin asociada. La funcin de logout debe estar disponible en todas las pginas protegidas por autenticacin. Establecer un tiempo de vida de la sesin lo ms corto posible, balanceando los riesgos con los requerimientos del negocio. En la mayora de los casos, nunca debera ser superior a varias horas. Deshabilitar logeos persistentes y efectuar finalizaciones peridicas de sesiones, incluso cuando la sesin se encuentra activa. Si una sesin fue establecida antes del login, cerrar dicha sesin y establecer una nueva luego de un login exitoso. Generar un nuevo identificador de sesin luego de cada re autenticacin. No permitir logeos concurrentes con el mismo usuario. No exponer identificadores de sesin en URLs, mensajes de error ni logs. Los identificadores de sesin solo deben ser ubicados en la cabecera de la cookie HTTP. A modo de ejemplo, no transmitir el identificador de sesin como un parmetro GET. Proteger la informacin sobre las sesiones del lado del servidor implementando los controles de acceso apropiados. Generar un nuevo identificador de sesin y desactivar el anterior de forma peridica. De esta forma se pueden mitigar algunos escenarios de robo de sesiones donde el identificador se compromete. Generar un nuevo identificador de sesin si la seguridad cambia de HTTP a HTTPS, como puede suceder durante la autenticacin. Dentro de la aplicacin es recomendable usar siempre HTTPS en lugar de cambiar entre HTTP y HTTPS. Manejo de sesin complementario para operaciones sensible del lado del servidor, como pueden ser: gestin de cuentas o utilizando tokens o parmetros por sesin. Este mtodo puede ser utilizado para prevenir ataques de Cross Site Request Forgery Attacks (Falsificacin de peticin en sitios cruzados, conocido por sus siglas CSRF). Manejo de sesin complementario para operaciones sensible o crticas utilizando tokens o parmetros por pedido (per request) en lugar de por sesin. Configurar el atributo seguro para las cookies transmitidas sobre una conexin TLS. Configurar las cookies con el atributo HttpOnly, salvo que se requiera especficamente scripts del lado del cliente en la aplicacin, para leer o configurar una cookie.

Control de Acceso Utilizar nicamente objetos confiables del sistema. (por ejemplo: objetos de sesin del servidor para la toma de decisiones de autorizacin). Utilizar un nico componente para el chequeo de autorizaciones para todo el sitio. Esto incluye libreras que llamen a servicios de autorizacin externos. Los controles de acceso en caso de falla, deben actuar en forma segura. Denegar todos los accesos en caso de que la aplicacin no pueda acceder a la informacin de configuracin de seguridad. Requerir controles de autorizacin en cada solicitud o pedido, incluyendo aquellos creados por scripts en el servidor, includes y pedidos desde AJAX o Flash desde el lado del cliente. Separar lgica privilegiada de otro cdigo de la aplicacin. Restringir acceso a ficheros u otros recursos, incluyendo aquellos fuera del control directo de la aplicacin, nicamente a usuarios autorizados. Restringir el acceso a URLs protegidas, solo a usuarios autorizados. Restringir el acceso a funciones protegidas, solo a usuarios autorizados. Restringir las referencias directas a objetos, solo a usuarios autorizados. Restringir el acceso a servicios, solo a usuarios autorizados. Restringir el acceso a informacin de la aplicacin, solo a usuarios autorizados. Restringir el acceso a usuario, atributos y poltica de informacin utilizada por los controles de acceso. Restringir el acceso a informacin relevante de la configuracin, solo a usuarios autorizados. Las reglas de control de acceso implementadas del lado del servidor y en la capa de presentacin, deben coincidir. Si existen datos de estado que deben ser guardados en el cliente, use cifrado y chequeos de integridad del lado del servidor para poder evaluar el estado. Requerir flujos de aplicacin que cumplan con las reglas del negocio. Limitar el nmero de transacciones que un usuario comn o un dispositivo puede desarrollar en un cierto perodo de tiempo. Utilizar el header referer solo como un chequeo complementario. Nunca debe ser utilizado como chequeo de autorizacin, ya que es posible modificarlo. Si sesiones de autenticacin extensas son permitidas, peridicamente hay que re-validar la autorizacin de los usuarios y asegurar que sus privilegios no han sido modificados. Implementar auditoras de cuentas y requerir que se deshabiliten las contraseas de las cuentas. La aplicacin debe permitir deshabilitar y terminar cuentas una vez que se termina la autorizacin (Cambio de rol, estatus de empleo, etc). Cuentas de servicio o cuentas soportando conectividad deben tener el mnimo privilegio. Crear una poltica de control de acceso para documentar las reglas del negocio de la aplicacin, los tipos de datos, criterios para autorizacin de acceso y los controles asociados para otorgarlos y controlarlos. Esto incluye la identificacin de accesos requeridos tanto para los datos como para los sistemas.

Prcticas Critpogrficas Todas las funciones de criptografa de la aplicacin deben ser implementadas en sistemas de confiables (por ejemplo: el servidor). Proteger secretos maestros (master secrets) del acceso no autorizado. Los mdulos de criptografa deberan en caso de falla, fallar en forma segura. Todos los nmeros aleatorios, nombre aleatorios, GUIDs, y frases aleatorias, deberan generarse utilizando mdulos aprobados para su generacin. Los mdulos criptrogrficos del sistema, deben cumplir con FIPS 140-2 o con su estndar equivalente. (Ver http://csrc.nist.gov/groups/STM/cmvp/validation.html). Establecer y utilizar una poltica y un proceso de cmo manejar las claves criptogrficas.

Manejo de errores y Logs No difundir informacin sensible en respuestas de error, incluyendo detalles del sistema, identificadores de sesin o informacin de la cuenta. Utilizar manejadores de errores que no muestren informacin de debugging o de memoria. Implementar mensajes de error genricos y utilizar pginas de error adaptadas. La aplicacin debera manejar los errores de la aplicacin y basarse en la configuracin del servidor. Liberar espacio de memoria en cuanto una condicin de error ocurra. L a lgica para la gestin de errores debe estar asociada a que los controles de seguridad no permitirn acceso por defecto. Todos los controles de logging deben estar implementados en sistemas confiables. El logging de controles de acceso debe incluir tanto los casos de xito como de falla. Asegurar que los datos del registro de log contengan informacin importante. Asegurar que los logs de entrada que incluyen informacin no segura, no sern ejecutados en interfaces o aplicativos. Restringir el acceso a los logs, solo a personal autorizado. Utilizar una rutina centralizada para todas las operaciones de logging. No guardar informacin sensible en logs, incluyendo detalles innecesarios del sistema. Asegurar que existen mecanismos para conducir un anlisis de los logs. Registrar en un log todas las fallas de validacin. Registrar en un log todos los intentos de autenticacin, en particular los fallidos. Registrar en un log todas las fallas en los controles de acceso. Registrar en un log todos los eventos de intento de evasin de controles, incluyendo cambios en el estado de la informacin no esperados. Registrar en un log todos los intentos de conexin con tokens invlidos o vencidos. Registrar en un log todas las excepciones del sistema. Registrar en un log todas las funciones administrativas, incluyendo cambios en la configuracin de seguridad. Registrar en un log, todas las fallas de conexin de TLS. Registrar en un log las fallas de los mdulos criptogrficos. Utilizar una funcin de hash para validar la integridad de los logs.

Proteccin de datos Implementar el mnimo privilegio, restringir el acceso de los usuarios solamente a la funcionalidad, datos y sistemas de informacin que son necesarios para realizar sus tareas. Proteger todos los almacenamientos temporales (en memoria o archivo -cached) de los datos sensibles guardados en el servidor de los accesos no autorizados y eliminar todos los archivos y memoria de trabajo temporal tan pronto como no sean requeridos. Encriptar toda la informacin altamente sensible almacenada, como por ejemplo: datos para la verificacin de la autenticacin, inclusive tambin en el servidor. Siempre utilice algoritmos de encriptacin que hayan sido chequeados y con buenos antecedentes. Vea Prcticas Criptogrficas para obtener informacin adicional. Proteja el cdigo fuente del servidor de forma de que no pueda ser descargado por el usuario. No almacene contraseas, cadenas de conexin u otra informacin sensible en texto claro o de forma que no sea criptogrficamente segura del lado del cliente. Esto incluye incluirla en formatos inseguros tales como: MS Viewstate, Adobe Flash o cdigo compilado. Remueva los comentarios en el cdigo de produccin que sea accesible por el usuario que puedan revelar informacin sobre los servidores o informacin sensible. Remueva cualquier aplicacin que no sea necesaria y la documentacin de los sistemas que pueda revelar informacin til para los atacantes. No incluya informacin sensible en los parmetros del HTTP GET. Deshabilite las funcionalidades de completar automticamente en aquellos formularios que contienen informacin sensible, incluyendo la autenticacin. Deshabilite el almacenamiento temporal del lado del cliente de pginas que contienen informacin sensible. Cache-Control: no-store debera ser utilizado en conjunto con el control en el cabezal de HTTP Pragma: no-cache, que es menos efectivo, pero mantiene compatibilidad con HTTP/1.0. La aplicacin debe de soportar la eliminacin de datos sensibles cuando los datos ya no son requeridos (por ejemplo: informacin personal o ciertos datos financieros). Implementar controles de accesos apropiados para los datos sensibles almacenados en el servidor. Esto incluye memoria temporal, archivos temporales y datos que solamente puedan ser accedidos por usuarios especficos del sistema

Seguridad en las comunicaciones Implemente encriptacin para todas las transmisiones de informacin sensible. Esto debera incluir TLS para proteger la conexin y se puede combinar con una encriptacin discreta de archivos sensibles en conexines que no estn basadas en HTTP. Los certificados TLS deben de ser vlidos y contener el nombre de dominio correcto, no deben estar expirados y debern ser instalados con los certificados intermedios si son requeridos. Las conexiones TLS que fallen no deben de transformarse en una conexin insegura. Utilizar conexiones TLS para todo el contenido que requiera acceso autenticado y para todo otro tipo de informacin sensible. Utilizar TLS para las conexione a sistemas externos que involucren funciones o informacin sensible. Utilizar una nica implementacin estndar de TLS que se encuentre configurada correctamente. Especificar los caracteres de codificacin para todas las conexiones. Filtrar los parmetros que contengan informacin sensible de los referer HTTP, cuando existen vnculos a sitios externos.

Configuracin de los sistemas Asegurarse de que los servidores, los frameworks y los componentes del sistema estn corriendo la ltima versin aprobada. Asegurar que los servidores, los frameworks y los componentes del sistema estn actualizados con todos los parches emitidos para las versiones en uso. Deshabilitar el listado de directorio. Restringir el servidor web, los procesos y las cuentas de servicios con el mnimo privilegio posible. Cuando ocurra una excepcin, se debe de fallar seguro. Remover todas las funcionalidades y archivos que no sean necesarios. Remover cdigo de testeo o cualquier funcionalidad que no sea tenida en cuenta en produccin, previo a realizar la puesta en produccin. Prevenir la revelacin de la estructura de directorios en el archivo robots.txt colocando directorios que estn disponibles para el ndice pblico en un directorio raz aislado. Luego Deshabilitar el directorio raz en el archivo robots.txt en vez de Deshabilitar cada directorio individual. Definir cules de los mtodos HTTP, GET o POST, la aplicacin va a soportar y si deben de ser manejados de forma diferente en las distintas pginas de la aplicacin. Deshabilitar mtodos HTTP innecesarios como extensiones WebDAV. Si una extensin del mtodo HTTP que soporte manejo de archivos es necesaria, utilice un mecanismo de autenticacin bien comprobado. Si el servidor web maneja HTTP 1.0 y HTTP 1.1, asegurarse que ambos estn configurados de manera similar asegurarse de entender bien las diferencias que puedan existir (por ejemplo: el manejo de mtodos extendidos de HTTP). Remover informacin innecesaria en los cabezales de HTTP de respuesta referidas al SO, versin del servidor web y frameworks de aplicacin. La configuracin de seguridad de donde se encuentra almacenada la aplicacin debe de ser listada en un formato legible para su auditora. Implementar un Sistema de Manejo de Activos y registrar los componentes del sistema en l. Aislar los ambientes de desarrollo de los ambientes de produccin y permitir el acceso solamente a los grupos de desarrollo y testeo especficamente autorizados. Los ambientes de desarrollo a menudo son configurados de forma menos segura que los ambientes de produccin y los atacantes pueden utilizar estas diferencias para descubrir vulnerabilidades o como un camino para poder explotarlas. Implementar un Sistema de Control de Cambios del Software para manejar y registrar los cambios al cdigo tanto para los ambientes de desarrollo como para los de produccin.

Seguridad de Base de Datos Utilice consultas parametrizadas con tipos de datos fuertemente tipados. Utilice validacin de las entradas y codificacin de las salidas y asegrese de manejar los meta caracteres. Si esto falla, no ejecute el comando de la base de datos. Asegrese de que todas las variables tengan tipos de datos asociados. La aplicacin debe de utilizar el mnimo nivel de privilegios cuando accede a la base de datos. Utilice credenciales seguras para acceder a la base de datos. Las cadenas de conexin a la base de datos no deben de estar incluidas en el cdigo de la aplicacin. Las cadenas de conexin a la base de datos deben de estar en un archivo de configuracin separado en un sistema confiable y debera de estar encriptado. Utilice procedimientos almacenados para abstraer el acceso a los datos y elimine los permisos de las tablas en la base de datos. Cierre la conexin a la base de datos tan pronto como sea posible. Remueva o cambie todas las contraseas administrativas por defecto. Utilice contraseas fuertes o frases o implemente autenticacin de mltiples factores. Deshabilite todas las funcionalidades innecesarias de la base de datos (por ejemplo: procedimientos almacenados innecesarios, servicios no utilizados, paquetes de utilidades, instale solo el conjunto mnimo de funcionalidades y opciones requeridas (reduce el rea de ataque)). Eliminar el contenido innecesario incluido por el proveedor (por ejemplo: esquemas de ejemplo). Deshabilitar las cuentas por omisin que no son necesarias para la operativa del negocio. La aplicacin debera conectarse a la base de datos con credenciales diferentes para cada nivel de confianza (por ejemplo: usuarios, usuarios solo lectura, invitados, administrador).

Manejo de Archivos No utilizar directamente informacin provista por el usuario en ninguna operacin dinmica. Exigir autenticacin antes de permitir la transferencia de un archivo al servidor. Permita transferir al servidor nicamente los tipos de archivo (por ejemplo: pdf, doc, etc) requeridos por la operativa del negocio. Validar los tipos de archivo transferidos verificando la estructura de los encabezados. La validacin del tipo de archivo nicamente por la extensin no es suficiente. No guardar los archivos transferidos en el mismo contexto que la aplicacin web. Los archivos deben almacenarse en un repositorio especfico o en una base de datos. Evite o restrinja la transferencia de archivos que puedan ser interpretados por el servidor web (por ejemplo: asp, php, jsp, etc). Eliminar los permisos de ejecucin a los archivos transferidos. Implemente una transferencia de archivos segura en UNIX mediante el uso de discos lgicos y el uso de las rutas (path) correspondientes o mediante la utilizacin de un entorno chroot. Cuando se referencie a un archivo existente en el servidor, utilizar una lista blanca de nombres y extensiones vlidas. Validar el contenido del parmetro pasado contra esta lista blanca y si se encuentra una coincidencia, denegar la operacin o utilizar transferir un archivo pre definido. No utilizar informacin provista por el usuario para la generacin de redirecciones dinmicas. Si se debe proveer esta funcionalidad, la redireccin debe aceptar nicamente caminos relativos dentro de la URL previamente establecidos (lista blanca de directorios relativos). No incluir en parmetros nombres de directorios o rutas de archivos, en su lugar utilizar ndices que internamente se asocien a directorios o rutas pre definidas. Nunca enve la ruta absoluta de un archivo al cliente. Asegrese que los archivos y recursos de la aplicacin sean de solo lectura. Revise los archivos transferidos por los clientes en busca de virus y malware.

Manejo de Memoria Utilice controles en la entrada y la salida de informacin no confiable. Revise dos veces que el largo de los buffer sean los requeridos y especificados. Cuando utilice primitivas que requieran el nmero de bytes a copiar, como ser strncpy(), sea consciente que si el tamao del buffer destino es igual al tamao del buffer origen, el destino podra quedar son el NULL-byte requerido del final. Verifique los lmites de los buffers si se llama a las funciones dentro de un loop y asegrese de no correr riesgo de escribir fuera del espacio reservado. Truncar el largo de todos los strings de entrada a un tamao razonable antes de pasarlos a una funcin de copia o concatenacin. Especficamente libere los recursos, no confe en el garbage collector (por ejemplo: objetos de conexin, handlers de archivos, etc.) Utilice stacks no ejecutables cuando sea posible (NX bit). Evite el uso de primitivas con vulnerabilidades conocidas (por ejemplo: printf, strcat, strcpy, etc). Libere adecuadamente la memoria previa a la salida de una funcin y de todos los puntos de finalizacin de la aplicacin.

Practicas Generales para la Codificacin Para las tareas habituales, utilice cdigo probado y verificado en lugar de crear cdigos especficos. Utilice las APIs previstas para el acceso a funciones especficas del sistema operativo. No permita que la aplicacin ejecute comandos directamente en el sistema operativo, menos an mediante la invocacin de una shell. Utilizar funciones de control de integridad (hash, CRC o checksum) para verificar la integridad del cdigo interpretado, bibliotecas, ejecutables y archivos de configuracin previo a su utilizacin. Utilice locks para evitar mltiples accesos simultneos a los recursos o mecanismos de sincronizacin (por ejemplo: semforos) para evitar condiciones de borde (race conditions). Proteja las variables y recursos compartidos de accesos concurrentes inadecuados. Explcitamente inicialice todas las variables y mecanismos de almacenamiento de informacin (por ejemplo: buffers), durante su declaracin o antes de usarlos por primera vez. Las aplicaciones que requieran privilegios especiales, debern elevar los privilegios solo cuando sea necesario y devolverlos (bajar privilegios) lo antes posible. Mantener los privilegios especiales nicamente cuando sea estrictamente necesario. Evitar errores de clculo comprendiendo la forma en que el lenguaje de programacin maneja las operaciones matemticas y las representaciones numricas. Prestar especial atencin a las discrepancias en la cantidad de bytes utilizados para la representacin, la precisin, diferencias entre valores con y sin signo, truncamiento, conversiones y casting entre tipos de variables, clculos no-numricos y como el lenguaje maneja los nmeros demasiado grandes o demasiado pequeos para su representacin. No utilizar datos provistos por el usuario para ninguna funcin dinmica. Evite que los usuarios introduzcan o modifiquen cdigo de la aplicacin. Revisar todas las aplicaciones secundarias, cdigo provisto por terceros y bibliotecas para determinar la necesidad del negocio para su utilizacin y validar el funcionamiento seguro, ya que estos pueden introducir nuevas vulnerabilidades. Implementar mecanismos seguros para las actualizaciones. Si la aplicacin realiza actualizaciones automticas, utilizar firmas criptogrficas para el cdigo y asegurarse que el cliente que descarga la aplicacin verifique dichas firma. Utilizar canales encriptados para las transferencias de cdigo desde el servidor de actualizacin.

Apndice B: GlosarioAgente de Amenaza: Cualquier entidad que puede poseer un impacto negativo en el sistema. Puede ser desde un usuario malicioso que desea comprometer los controles de seguridad del sistema; sin embargo, tambin puede referirse al mal uso accidental del sistema o a una amenaza fsica como fuego o inundacin.Autenticacin: Conjunto de Controles utilizados para verificar la identidad de un usuario o entidad que interacta con el softwareAutenticacin Multi-Factor: Proceso de autenticacin que le requiere al usuario producir mltiples y distintos tipos de credenciales. Tpicamente son basados en algo que el usuario tiene (por ejemplo: una tarjeta inteligente), algo que conoce (por ejemplo: un pin), o algo que es (por ejemplo: datos provenientes de un lector biomtrico).Autenticacin secuencial: Cuando los datos de autenticacin son solicitados en pginas sucesivas e vez de ser solicitados todos de una sola vez en una nica pgina.Canonicalizar: Convertir distintas codificaciones y representaciones de datos a una forma estndar predefinida.Caracteres considerados peligrosos: Cualquier carcter o representacin codificada de un carcter que puede afectar la operacin intencionada de la aplicacin o sistema asociado por ser interpretado de una manera especial, fuera del uso intencionado del carcter. Estos caracteres pueden ser utilizados para: Alterar la estructura de las sentencias o cdigo existente Insertar cdigo inintencionado Alterar caminos Causar salidas inesperadas de rutinas o funciones Causar condiciones de error Obtener cualquiera de los efectos anteriores sobre el flujo de aplicaciones o sistemasCaso de Abuso: Especificacin de un tipo de interaccin completa entre un sistema y uno o ms actores, donde los resultados de la interaccin son perjudiciales para el sistema, uno de los actores o uno de los interesados en el sistemaCodificacin de Entidades HTML: Proceso por el cual se reemplazan ciertos caracteres ASCII por sus entidades equivalentes en HTML. Por ejemplo: este proceso reemplazara el carcter de menor "