PDF de programación - spsmm.0.5.1.es

INSTITUTE FOR SECURITY AND OPEN



METHODOLOGIES



SPSMM

STANDARD DE PROGRAMACIÓN SEGURA



Created by Victor A. Rodriguez



v0.5.1

CURRENT VERSION:
NOTES:
CHANGES:
DATE OF CURRENT VERSION: May 2002
DATE OF ORIGINAL VERSION:

Spanish

-

-

Any information contained within this document may not be modified or sold without the express consent of the author.

Copyright 2000-2003, Victor A. Rodriguez, the Institute for Security and Open Methodologies. All Rights Reserved,

available for free dissemination under the Open Methodology License (OML).

SPSMM – Secure Programming Standards Methodology Manual
May 2002

STANDARD DE PROGRAMACIÓN SEGURA - Victor A. Rodriguez (Bit-Man)



Cuando se expone una interfaz (de programacíon, usuario, etc.) subuso puede ser subvertido (uso
abusivo). Es este abuso el que debe ser evitado (seg'un en que lado uno se encuentre parado). Ya
que planeamos realizar un standard de esta metodolog'ia desde el lado de la programacíon, y
seguramente Ud. es un programador, arquitecto de sistemas, team leader u otra cosa por el estilo
querr'a mantener la interfaz limpia, usable y sin componentes que puedan ser abusadas.

A medida que las aplicaciones de Internet comienzan a ser m'as y más complejas, y la generación
de código comienza a ser cada vez más automatizada a través del uso de wizards, ambientes de
programación, frameworks y otras herramientas por el estilo comenzamos a estar en franca
desventaja. La técnicas para programación segura es algo que ha sido abordado desde muchas
formas y por muchos lenguajes. Lo que se trata de hacer es una única metodología independiente
de lenguajes de programación, ambientes de programación y herramientas de desarrollo.

La idea de convertirlo en un standard abierto nos da el inmediato beneficio que puede ser usado
por cualquiera, pero esto también incluye a los chicos malos. Sin embargo, si se sigue una
metodología seguramente los errores más comunes ya no aparecen. La contrapartida es que
cuanto más programadores lean y entiendan este manual, mayor es la posibilidad de desarrollar
aplicaiones en forma segura y ayudar a mejorar esta tecnología.
Agradecimientos

Quisiera agradecer a David A. Wheeler por escribir "Secure Programming for Linux and Unix HOWTO"
[1] que tanto me inspiró para hacer este trabajo. También una agrdecimiento a quienes escribieron
"[email protected] working document" [9], algo así como el "Primer Diccionario" sobre
"Programación Segurá.

Debo también dar un agradecimiento muy especial a Pete Herzog, por toda la ayuda brindada en
muchos de los aspectos de este trabajo.

Todos aquellos que contribuyeron a este manual en alguna forma son emncionados al principio de
este documento. Cada quien recibe un reconocimiento por el tipo de contribución, y no por lo que
ha contribuído. El uso de este ocultamiento es para prevenir la polarización al momento de la
interpretación. Sólo en la traducción del documento se saben las personas que realizaron la
contribución, ya que el traductor se convierte en el contacto del documento traducido que incluye,
no sólo el mantener actualizado el documento, sino también las FAQs, agregados y comentarios
hechos en el original, en Inglés, y traducido al lenguaje deseado.
Términos

• DoS (Denial of Service):Ataque cuyo porpósito es no permitir el uso del sistema. No

afecta los datos almacenados en el sistema.

• out-of-the-box:instalación standard, utilizando los parámetros por defecto.

2
Copyright 2000-2003 Victor A. Rodriguez, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org .
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

SPSMM – Secure Programming Standards Methodology Manual
May 2002

•

super-user: es un usuario especial (conocido como root o administrador) que no tiene
restricciones de acceso dentro del sistema.

Audiencia

Este manual fue escrito para profesionales de la programación que quieren establecer lineamientos
y/o procedimientos para la programación segura en cualquier proyecto de Tecnología de la
Información (IT), independiente del lenguaje de programación, ambiente de ejecución y
herramientas de desarrollo.

Este manual no examina la forma correcta de usar una herramienta de desarrollo en particular o
cómo programar en un lenguaje dado.

Los desarrolladores encontrarán muy útil este manualen realizar mejores programas, más resistentes
a ambientes hostiles tales como Internet.
Alcance

El objetivo es realizar un standard de metodología de programación segura que pueda ser usado
en cualquier proceso, manual o automático, y permita alcanzar los requerimientos de seguridad
para maximizar el uso y evitar su abuso. El resultado indirecto es la creación de una disciplina que
pueda actuar como un punto central en todas las pruebas de seguridad independientemente del
lenguaje de programación, ambiente de ejecución y herramientas de desarrollo.
Excepciones

Los casos no cubiertos, aún, en este trabajo son :

• Programas cuyo propósito es el manejo de la seguridad
• Programas que deben correr como super-user

Preparación para trabajar en un ambiente hostil

Esto no es tarea fácil, y fue hecho en diferentes maneras, cada una cubriendo su punto de vista,
comenzando en diferentes formas, etc. Aquí estableceré las mías propias.

Si le damos una mirada a Secure Programming for Linux and Unix HOWTO [1] (sección 2.2, Security
principles) la programacín segura puede ser interpretada como el cumplimiento de los siguientes
objetivos: confidencialidad, integridad y disponibilidad. Esto es correcto y puede ser moldeado para
cualquier ambiente en particular, pero es una muy buena respuesta genérica. El problema
comienza en cómo alcanzar esto objetivos. Lo que se tratará de enfatizar no es el arreglo de los
mismos, sino en una metodología open source que provea la base para el desarrollo de m'etodos
y/o procedimientos.

El trabajo de un sistema es implementar requerimientos funcionales que, debidamente acordados,
puedan ser probados. En una aproximación más detallada, la codificación se hace para cumplir
con este objetivo pero en una escala atómica (a nivel de subrutina o procedimiento de
programación). Lo que no es parte de los requerimientos funcionales es la disponibilidad del sistema,
la que establece las condiciones de uso tales como en qué días será usado (laborables, feriados,

3
Copyright 2000-2003 Victor A. Rodriguez, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org .
ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

SPSMM – Secure Programming Standards Methodology Manual
May 2002

etc.), ventana diario de uso (9:00 a 17:00 hs, etc.), m'aximo tiempo permitido sin acceso al sistema (2
horas mensuales, etc.) y toda una serie de requerimientos que definen el denominado Acuerdo de
Nivel de Servicio (SLA o Service Level Agreement).

Es en este punto donde, ejecutando en ambientes hostiles como Internet, poder brindar los niveles
requeridos del SLA (integridad), imposibilitar el robo de información (seguridad) o proveer la
información a la persona correcta (confidencialidad ) es de particular interés.

Una vez que conocemos sobre este y su impacto negativo, hay una gran preocupación en cóomo
adoptar una aproximación sistemática para resolverlo. Para comenzar, veamos los factores que
dan comienzo a esta problemática :

• qué no hacer: es muy difícil construir sobre lo que no debe hacerse. Protegerse de
algo que no se sabe su forma exacta es una tarea muy dura (un muy buen artículo
sobre este tema puede verse en el newsletter Crypto-gram de Noviembre de 1999 [2]).
Es similar a la defensa contra los microbios, uno no puede protegerse a menos que se
sepa de su existencia y de cómo derrocarlos.

• complejidad: esto da origen a uno de los mas viejos y difíciles problemas de la

humanidad. Se llama comunicación, y según se agrega complejidad a un sistema
este puede manejarse mejor si se divide en tareas ma;s pequeñas, se asignan a
distintos equipos que deben comunicarse entre si para alcanzar el objetivo: cuanto
m'as equipos hay mayor cantidad de comunicaciones deben establecerse y, como
es sabido, convierte a la construcción del sistema en un problema de crecimiento
exponencial (lo mejor s dar una mirada al título software essential difficulties de "No
silver bullet" [3]). Esto favorece la existencia de errores ocultos que son cubiertos por el
síndrome de "hay muchos lugares donde mirar".

Methodología

Como este trabajo es parte de "The Open-Source Security Testing Methodology Manual" (OSSTMM),
la misma metodología será usada, estableciendo los Parámetros y Tareas orientadas a la
Programación Segura, pero con una aproximación un tanto diferente. En OSSTMM se descubre que
hay un error, y ahora queremos saber dónde se haya ubicado, cóomo arreglarlo y evitar su
aparición en futuras codificaciones.

Esta sección trata de los dos primeros objetivos (descubrimiento y reparación) mientras que el
trabajo de cómo evitar estos problemas es un tema a ser tratado en un trabajo a ser desarrollado
(no incluido en este).
Datos entrantes

Debe notarse que las interfaces se basan en la implementación de alguna tecnología y que la
explotación de los problemas de seguridad deben ser arreglados para obtener una comp[leta
solución al problema. No es suficiente con arreglar la implementación de la interfaz o el programa
bajo prueba.

Algo a tener en cuenta es que los dato de entrada no son sólo los adquiridos a través del usuario o
de otros aplicaciones, sino también los obtenidos desde el sistema (fecha, variables de ambiente,

4
Copyr