CLASE 3

Índice de Contenidos

• Repaso Sesión Anterior

• La Seguridad como Proceso General
• Lineamientos para Seguridad en el Desarrollo
• Directrices de Programación Segura
• Desarrollo Seguro en JAVA

2
 Repaso Sesión Anterior

3
 Repaso Sesión Anterior

• Criterios Mínimos para el Desarrollo y Adquisición de Software

• Soporte y Gestión Continua del Software
• Gestión de Usuarios, Sesiones y Privilegios
• Autenticación y Gestión de Credenciales
• Gestión de Registros de Auditoría
• Cifrado
• Codificación del Software
• Diseño de Software Seguro
• Sociedad del Conocimiento
• Software Digno de Confianza
✓Seguridad
✓Confianza
✓Fiabilidad
✓Supervivencia
4
 Repaso Sesión Anterior

• Cultura Organizacional y Capacitación

• Implementar Framework de Seguridad
• Aplicar Modelos de Defensa en Profundidad
• Cultura Organizacional y Capacitación
• Responsabilidades

5
 La Seguridad como Proceso General

6
 La Seguridad como Proceso General

Un proyecto informático está compuesto por muchas partes de las que son
responsables distintas personas, y cuanto más grande es el proyecto, mayor es
el número de actores que participan en el mismo y más delegada y repartida
está la responsabilidad, lo cual viene asociado normalmente a un mayor nivel de
especialización concreta en cada una de las áreas por parte de los profesionales
que se dedican a estas.

La parte negativa de esta separación es

el aislamiento, y en lo que respecta a
seguridad de la información, se
produce un efecto muy interesante que
es el aislamiento mental.

7
 La Seguridad como Proceso General

Si le preguntan a un administrador de sistemas sobre seguridad informática,

sus respuestas van a estar enfocadas a evitar que el potencial atacante consiga
una cuenta de “superusuario” en la máquina. Esto, para él, es la brecha total y
absoluta, el control total por parte del intruso del sistema, y todo lo que sea
impedir que el atacante llegue hasta aquí no es excesivamente crítico.

Por otro lado, un desarrollador

hablará de filtrado de la entrada del
usuario y de almacenamiento
criptográfico de información sensible,
y centrará sus respuestas en la
seguridad de la lógica de su aplicación
(desarrollo seguro de software).

8
 La Seguridad como Proceso General

Al responsable de contenidos todo lo anterior le da igual, porque si el

programa más seguro del mundo, en el data center más protegido y mejor
administrado, permite una política débil de contraseñas que haga que
cualquiera pueda acceder fácilmente a la cuenta de uno de los editores y así
cambiar el contenido de su portal, la seguridad ha sido comprometida y para él
en el punto más crítico.
En resumen: La seguridad es un proceso
general en el que deben estar involucrados
todos los actores que participan en el
desarrollo y despliegue de una aplicación, ya
que cada uno aportará su punto de vista sobre
los activos que hay que proteger.

9
 La Seguridad como Proceso General

"La seguridad es un proceso" es posiblemente la frase más repetida en textos y

conferencias de seguridad, y esto es así porque se trata de algo en lo que
absolutamente todos están de acuerdo. Todos excepto los que no se dedican a
ello.

Es un proceso vivo, continuamente

cambiante, en el que hay que estar
siempre alerta y pendiente de nuevas
técnicas y vulnerabilidades en general,
y de las que afectan directamente a
nuestras aplicaciones y sistemas en
particular. Por ejemplo: El sistema
operativo más seguro del mundo no
sirve de nada si no se le aplican los
parches de seguridad del fabricante con
frecuencia.
10
 La Seguridad como Proceso General

¿Qué prácticas debemos tener en cuenta para no caer en las vulnerabilidades

más comunes, y qué frameworks y tecnologías encontramos que ya hacen por
nosotros las tareas más delicadas, tales como: la autenticación, la autorización,
el mantenimiento de sesiones o la criptografía?.

Como regla general, podemos decir que si en algún

momento nos encontramos programando nuestra
propia manera de hacer alguna de estas cuatro
tareas, casi con un 100% de seguridad estaremos
cometiendo un error. Utilizando metodologías y
siguiendo estándares reconocidos, evitaremos
tener que desarrollar de manera personalizada.

11
 Lineamientos para Seguridad
en el Desarrollo

12
 Lineamientos para Seguridad en el Desarrollo

Para tener un punto de referencia respecto a cómo están los estándares de

desarrollo seguro en Chile, lo mejor es partir por las recomendaciones y los
lineamientos generales que propone el Gobierno para todo equipo que
desarrolle software al interior de la Administración del Estado y los grupos de
desarrollo de los proveedores.

La adopción de buenas prácticas es fundamental para todas las etapas de

desarrollo de un sistema o aplicación informática. La guía técnica que pone a
disposición el gobierno propone un total de 20 lineamientos y consideraciones
para el desarrollo seguro de software.

13
 Lineamientos para Seguridad en el Desarrollo

1. Uso de Librerías y Frameworks de Seguridad

Se deben seleccionar librerías y framework de autores confiables, con
mantención y desarrollo activo, y que sean ampliamente utilizadas (y por ende,
validadas). Las librerías y frameworks de terceros confiables que incorporan
mecanismos de seguridad son fundamentales para evitar errores de
implementación en áreas en las que el desarrollador no se encuentre tan
familiarizado.

Es importante inventariar y catalogar dichas

librerías y frameworks para mantenerlas
actualizadas y prevenir vulnerabilidades en
ellas. Otra alternativa recomendada es
encapsular la librería y exponer sólo la
funcionalidad requerida en el sistema que se
está desarrollando.

14
 Lineamientos para Seguridad en el Desarrollo

2. Consultas Seguras a las Bases de Datos

Las vulnerabilidades de tipo SQL injection ocurren cuando datos no confiables
son incorporados de forma dinámica a una consulta SQL (muchas veces a través
de la concatenación directa de dos strings). Este tipo de ataque permite a un
adversario extraer, modificar o eliminar datos desde la base de datos e incluso
en ocasiones, tomar total control del sistema comprometido.

Para mitigar o prevenir este tipo de

ataques, se deben implementar
medidas de protección acordes a la
tecnología y plataforma utilizada. Se
proponen tres medidas base que
pueden ser implementadas por los
equipos de desarrollo.

15
 Lineamientos para Seguridad en el Desarrollo

2. Consultas Seguras a las Bases de Datos

(A) En el caso de estar utilizando un lenguaje orientado a objetos, se debe
utilizar el mapeo a través de ORM, asegurándose que la herramienta utilizada
no tenga vulnerabilidades de inyección, e implementar otros mecanismos de
defensa como codificar y escapar los datos.

(B) En el caso de no poder utilizar ORM de

forma justificada, se deben utilizar prepared
statements para prevenir posibles
inyecciones de código SQL.

Las prepared statements, también llamadas

consultas, comandos o sentencias preparadas,
son plantillas para consultas a sistemas de
bases de datos en lenguaje SQL cuyos
16 parámetros están desprovistos de valores.
 Lineamientos para Seguridad en el Desarrollo

2. Consultas Seguras a las Bases de Datos

(C) En el caso de contar con tecnología de base de datos específica o legacy
(Oracle, SQL Server, etc), en la cual se utilicen procedimientos almacenados
directamente en el motor, estos deben ser securitizados de forma correcta, por
ejemplo, utilizando bind variables.

Cuando se usan las variables Bind, no

se escribe el valor actual pero en su
lugar, se inserta un marcador de
posición dentro de la sentencia SQL.
De esta manera, no cambia la sentencia
cuando se ejecuta con valores
diferentes.

17
 Lineamientos para Seguridad en el Desarrollo

3. Codificar y Escapar los Datos

Éstas son técnicas defensivas cuyo objetivo es detener ataques de inyección, ya
sean SQL, XSS u otros. Codificar consiste en transformar o traducir ciertos
caracteres especiales por otros caracteres equivalentes pero inofensivos para
el intérprete. Por ejemplo, el carácter “<” se traduce en “&lt;”.

Escapar caracteres es una técnica similar, con la

diferencia que en lugar de reemplazar un carácter
por otro, se añade un carácter especial antes del
dato a escapar, para prevenir interpretaciones
erróneas, por ejemplo, añadiendo un “\” antes de
caracteres como “”” (comillas dobles), para que
sea interpretado como texto y no como el cierre
de un string.

18
 Lineamientos para Seguridad en el Desarrollo

3. Codificar y Escapar los Datos

Es fundamental realizar este escapado y/o codificación de datos en un entorno
confiable (en el servidor y no en el navegador del usuario) y, de forma tal, de
evitar el “doble escapado” que genera errores de despliegue de los datos (por
ejemplo, si escapamos antes de almacenar en la base de datos y nuevamente
cuando se despliega al usuario).

Para evitar ataques XSS se deben

utilizar los mecanismos conocidos
como Contextual Output Encoding,
que nos permiten prevenir el
despliegue de contenido malicioso en
el navegador del usuario.

19
 Lineamientos para Seguridad en el Desarrollo

3. Codificar y Escapar los Datos

Un sistema debe considerar como potencialmente inseguros todos los datos
que provengan desde fuera de la aplicación, así como también los datos que
provienen desde la base de datos (en caso de que se haya modificado
maliciosamente la misma). Por ello, deben ser correctamente codificados y/o
escapados siempre, pero sin olvidar el contexto de los datos, por ejemplo, si es
HTML, datos alfanuméricos u otros.

20
 Lineamientos para Seguridad en el Desarrollo

4. Validación de Datos
Esta es una técnica para asegurar que sólo los datos con el formato correcto
podrán ingresar al sistema a desarrollar. Esta validación debe ser correcta,
tanto sintáctica como semánticamente. Por ejemplo, si esperamos que en un
campo se ingresen sólo dígitos, no debemos aceptar otro tipo de caracteres
(validación sintáctica). La validación semántica es un poco más compleja y
consiste en validar que los datos tengan sentido en el contexto de la aplicación,
por ejemplo: una fecha de inicio no podría estar después de una fecha de fin.

La validación de datos debe ser, como mínimo,

a través de mecanismos de lista negra (datos
conocidos como maliciosos). Como una mejor
práctica también se validará a través de lista
blanca (datos conocidos como correctos, por
ejemplo, una lista de regiones).

21
 Lineamientos para Seguridad en el Desarrollo

4. Validación de Datos
La validación de datos, al igual que la codificación y escape, deben ser siempre
realizados en el servidor y nunca del lado del cliente (por ejemplo: no se debe
realizar en el navegador del usuario). No se debe confundir un aviso al usuario
(por ejemplo: para alertar de un campo mal ingresado) con la validación de
datos.

La validación de datos no convierte

automáticamente a los datos en
seguros, por lo que se debe utilizar en
conjunto con otras defensas, tales
como la parametrización de consultas y
escapado de datos, mencionadas
anteriormente.

22
 Lineamientos para Seguridad en el Desarrollo

5. Implementar Mecanismos de Autenticación Seguros

La autenticación hace referencia a un proceso para verificar que un individuo o
entidad es quien dice ser. Para estos efectos, podemos utilizar varios
mecanismos (también llamados factores de autenticación):

Nivel 1: Contraseñas
Las aplicaciones deben exigir al usuario el uso
de contraseñas de características y calidad
adecuadas, y que no sean contraseñas
previamente filtradas. Asimismo, se deben
implementar mecanismos seguros de
recuperación de contraseñas, ya sea
utilizando un segundo factor de autenticación
o a través de canales diferentes (como
teléfono móvil o correo electrónico).
23
 Lineamientos para Seguridad en el Desarrollo

5. Implementar Mecanismos de Autenticación Seguros

Nivel 1: Contraseñas
Una contraseña fuerte es aquélla que es difícil de detectar, tanto por humanos
como por software, protegiendo efectivamente los datos de un acceso no
autorizado. Una contraseña segura consta de al menos ocho (8) caracteres (y
mientras más caracteres, más fuerte es la contraseña), que son una
combinación de letras, números, símbolos y el uso de mayúsculas y minúsculas.

Se deben implementar mecanismos de

limitación de intentos de inicio de sesión,
ya sea ralentizando los intentos de inicio de
sesión, bloqueando la IP de origen de los
intentos fallidos o bloqueando las cuentas
después de un número predeterminado de
intentos fallidos.
24
 Lineamientos para Seguridad en el Desarrollo

5. Implementar Mecanismos de Autenticación Seguros

Nivel 2: Multifactor
Es el uso de múltiples factores de autenticación para verificar al usuario.
Habitualmente se usa una combinación de dos o más de los siguientes factores:

1. Lo que el usuario sabe (por ejemplo: una contraseña).

2. Lo que el usuario tiene (por ejemplo: un

dispositivo o una tarjeta de coordenadas).

3. Algo que el usuario es (por ejemplo: la

biometría).

25
 Lineamientos para Seguridad en el Desarrollo

5. Implementar Mecanismos de Autenticación Seguros

Nivel 2: Multifactor
La biometría no se debe considerar un dato secreto, puesto que algunas
características biométricas pueden ser fácilmente reproducibles u obtenidas
sin conocimiento del usuario, por ejemplo, a través de una foto del rostro o
“levantando” huellas digitales de objetos, por lo que siempre debe usarse en
conjunto con otro factor de autenticación.

26
 Lineamientos para Seguridad en el Desarrollo

5. Implementar Mecanismos de Autenticación Seguros

Nivel 3: Autenticación Criptográfica
Se logra a través del uso de módulos de hardware criptográfico seguro, en
conjunto con algún mecanismo de autenticación adicional (password,
biometría, otros).

27
 Lineamientos para Seguridad en el Desarrollo

6. Implementar Mecanismos de Manejo de Sesión

Para el manejo de las sesiones se debe considerar al menos lo siguiente:

• El identificador de sesión debe ser único, suficientemente largo y aleatorio.

• Se deben generar (o rotar) los identificadores de sesión durante la

autenticación y re-autenticación.

• Se debe implementar un timeout por

inactividad que fuerce la re-autenticación al
usuario. La duración de este timeout debe
ser inversamente proporcional a la
sensibilidad de los datos a proteger, vale
decir, mientras más sensible, menor
28 duración.
 Lineamientos para Seguridad en el Desarrollo

7. Uso de Cookies para Manejo de Sesión

Para el uso de cookies se debe considerar lo siguiente:

• Deben ser accesibles por el mínimo de dominios requeridos para el correcto

funcionamiento del sistema.

• Deben caducar al momento en que expira la sesión, o luego de un corto

período.

• Deben tener el flag “secure”. Esto fuerza su transferencia a través de TLS.

• Deben tener el flag “HttpOnly”. Esto previene su acceso a través de

JavaScript.
29
 Lineamientos para Seguridad en el Desarrollo

8. Uso de Tokens de Sesión

Cuando sea necesario manejar sesiones stateless por razones de performance
u otras, se recomienda el uso de JWT2 (JSON Web Tokens), puesto que son un
mecanismo seguro e interoperable de manejo de sesión. Un JWT tiene
garantías criptográficas si son generados de forma segura, para lo cual se
recomienda utilizar los siguientes parámetros:

Nunca definir, en la configuración, el algoritmo

para firmar o cifrar como “none”. Esto
deshabilita todas las consideraciones
criptográficas. El parámetro “alg” es el que
permite definir el algoritmo que será utilizado
para estas tareas.

Se debe seleccionar un algoritmo lo

30 suficientemente fuerte.
 Lineamientos para Seguridad en el Desarrollo

9. Identificación de Datos
Los datos sensibles o críticos deben estar identificados, de forma de poder
implementar las protecciones que requieran de forma correcta. Por ejemplo, si
se manejan datos sensibles de ciudadanos, se requieren algunas protecciones
específicas que deben estar presentes.

10. Datos en Tránsito

Las comunicaciones de los componentes
que transporten información de los
usuarios entre sistemas, deberán siempre
estar protegidas mediante TLS, y los
sistemas correctamente configurados
para seleccionar el cifrado más fuerte
disponible.

31
 Lineamientos para Seguridad en el Desarrollo

TLS: Transport Layer Security

Es la siguiente generación del Certificado SSL (basado en la versión 3.0):
Permite y garantiza el intercambio de datos en un entorno securitizado y
privado entre dos entes, el usuario y el servidor, mediante aplicaciones como
HTTP, POP3, IMAP, SSH, SMTP o NNTP. En palabras simples encripta la
información compartida.

¿Cómo la encripta? Mediante dos protocolos en

capas diferentes:
• Protocolo de autenticación (TLS Record
Protocol)
• Protocolo de mutuo acuerdo (TLS Handshake
Protocol).

32
 Lineamientos para Seguridad en el Desarrollo

TLS: Transport Layer Security

Record: Se lleva a cabo la autenticación para que la transmisión de datos sea
mediante una conexión privada y fiable (se negocia la encriptación y la
integridad del emisor-receptor).

Handshake: Se negocia el mensaje de manera

segura. En cada mensaje se especifica el
protocolo en un campo (llamado content_type) y
se cifra y empaqueta con un código de
autentificación (o MAC).

Por lo tanto, en el protocolo TLS, se lleva a cabo un canal seguro y cifrado entre
cliente y servidor en donde se negocia la criptografía del mensaje, se
autentifican las claves del cifrado y se realiza una transmisión segura.
33
 Lineamientos para Seguridad en el Desarrollo

11. Datos en Reposo

Se debe evitar, cuando sea posible, el almacenamiento de datos sensibles por
parte de la aplicación. En caso que no se pueda evitar almacenar datos
sensibles, éstos deben ser protegidos mediante encriptación, para prevenir la
modificación o acceso no autorizado.

En caso de manejar datos que deban

considerarse como abiertos, éstos deberán
ser manejados y almacenados utilizando
formatos estándar que permitan su fácil
exportación a las plataformas
correspondientes.

34
 Lineamientos para Seguridad en el Desarrollo

12. Manejo de Secretos

Las aplicaciones habitualmente contienen múltiples secretos que son
necesarios para su operación. Éstos pueden incluir certificados digitales,
contraseñas para la base de datos, credenciales a otros servicios, llaves
criptográficas, entre otros.

Toda la información relacionada a

certificados digitales, contraseñas, llaves,
credenciales, incluidas las rutas de
almacenamiento u otras referencias a
estos objetos, deben quedar debidamente
parametrizadas en un archivo de
variables de entorno y éste debe ser
excluido de la herramienta de control de
versiones Git.

35
 Lineamientos para Seguridad en el Desarrollo

13. Desarrollo Orientado a Pruebas

Para efectos de trabajo con datos o ejercicios, el equipo de desarrollo deberá
tener un set de datos no válidos escogido para trabajar y cargar el sitio para
efectos de pruebas de integración continua o pruebas unitarias. Este set no
debe contener información que sea real y la cantidad de datos debe ser
reducida pero suficiente para generar pruebas sobre el código.

El desarrollo orientado a pruebas (TDD: test

driven development) es una técnica basada en
realizar pequeños tests que describen la
funcionalidad antes de desarrollarla. De esta
manera, el código final debe ir consiguiendo
pasar los test y avanzar mediante
refactorización.

36
 Lineamientos para Seguridad en el Desarrollo

14. Calidad de Código

El código deberá ser revisado de forma continua durante su construcción con
herramientas de inspección. El objetivo principal es encontrar posibles bugs de
seguridad, tanto dentro del código creado por el equipo de desarrollo, como en
sus dependencias.

15. Detección Preventiva

Para todo lo relacionado con las
aplicaciones, se debe configurar y usar
algún proyecto OWASP (Por ejemplo:
OWASP Zap) para la revisión en
búsqueda de vulnerabilidades en la
aplicación. Esto, para corregir antes de
entregar la aplicación.

37
 Lineamientos para Seguridad en el Desarrollo

16. Modelo Inicial de Datos

Las estructuras de base de datos no deberán contener datos, tan sólo los
esquemas y, de requerir la carga de datos externos producto de un proceso de
inicialización, estos datos no deben ir en el código y serán procesados por una
vía interna y privada, en el caso que se requiera.

17. Seeding de la Base de Datos y Creación de Datos Iniciales en el Despliegue

La creación de usuarios administrador iniciales o cualquier tipo de información
sensible, debe quedar fuera del sistema de versionamiento del código.

El proceso de creación de un usuario inicial de administración en este proceso,

así como cualquier otro dato sensible para el funcionamiento de la aplicación y
que su filtración involucre una merma de seguridad, debe ser documentando,
entregado confidencialmente y nunca ser registrado en un repositorio de
código.
38
 Lineamientos para Seguridad en el Desarrollo

18. Implementar Mecanismos de Registro

Se deben registrar distintos eventos del sistema para permitir que éstos sean
monitoreados de forma automatizada para efectos de seguridad:

• Registrar la cantidad de información correcta.

• Siempre registrar un timestamp e

información de identificación (IP,
usuario, etc).

• Nunca registrar información sensible en

los logs.

39
 Lineamientos para Seguridad en el Desarrollo

19. Manejo Seguro de Errores y Excepciones

Se debe desarrollar el sistema, de forma tal, que aplique el principio de "fallar
seguro". Es decir:

• No exponer información sensible o privada en los mensajes de error.

• Asegurarse de que una excepción o fallo no

comprometa la seguridad por un error de
programación en el sistema. Por ejemplo:
causar una denegación de servicio o ejecución
de código con privilegios incorrectos.

• Registrar las excepciones adecuadamente en

los sistemas que correspondan.
40
 Lineamientos para Seguridad en el Desarrollo

20. Compilación Limpia

De ser un lenguaje compilado y no interpretado, es necesario no contar con
ningún tipo de alerta en el momento de compilación. Para conseguir este
objetivo, lo mejor es dar las opciones al compilador para tratar las alertas
(warnings) como si fueran errores y, de esta forma, fallar en caso de existir una
alerta al momento de la compilación.

41
 Directrices de Programación Segura

42
 Directrices de Programación Segura

Como hemos visto durante el curso la seguridad de la información es un tema

que cada día cobra más fuerza, y la mayor parte de las vulnerabilidades tiene su
génesis desde el momento de codificar el software porque el desarrollador no
es consciente de los riesgos de seguridad a los que pueden estar expuestas las
aplicaciones (o derechamente no le importa).

La seguridad no debe quedar nunca

relegada a un segundo plano y debe estar
presente desde la concepción misma del
producto. Existen numerosas directrices y
consejos que un programador puede
implementar para ayudar en la
prevención de los errores de seguridad
comunes en las aplicaciones. Muchos de
estos pueden ser aplicados a cualquier
lenguaje de programación.
43
 Directrices de Programación Segura

Validaciones de Entrada
Los datos de entrada de una aplicación se pueden definir como el conjunto de
parámetros que van a ser digitados y posteriormente capturados para ser
manipulados en el código. En términos de implementación se debe validar cada
carácter de entrada y en caso no de considerarse como valido se debe generar
un error o ser manejado por medio de excepciones.

Los errores se deben traducir en un lenguaje

comprensible para el usuario. En ninguno de los
casos se debe arrojar la línea del código ni
tampoco se deben notar la clase, evento o
método ya que esto puede dar indicios al
presunto atacante sobre las tecnologías
implementadas.

44
 Directrices de Programación Segura

Código Comentado
Todo código comentado dentro de la aplicación debe ser eliminado antes de ser
lanzado en producción debido a que el código comentado puede generar el uso
accidental en producción que puede alterar el correcto funcionamiento de la
aplicación, como también puede llegar a contar con “código quemado” (hard-
code).

Consiste en dejar variables definidas por

defecto en el código, esto puede configurar
un problema de seguridad ya que algunas
de estos valores preestablecidos (usuario,
contraseña, dirección IP, etc) pueden salir
a un ambiente productivo y un atacante
puede aprovechar esta vulnerabilidad en el
código para conocer el entorno y hacer
explotación.
45
 Directrices de Programación Segura

Mensajes de Error
Todos los mensajes de error que lleguen al usuario final no deben contener
información confidencial, tal como: SO, red, lenguaje de programación, línea del
error, motor de BD. Estos errores deben tratarse y ser estandarizados de forma
genérica y comprensible para el desarrollador pero que sea entendible para el
usuario. Por ejemplo: “Se presentó el error 1281 no se pudo registrar el
usuario, póngase en contacto con el proveedor de servicio”.

Contenido URL
En el contenido URL nunca se debe mostrar
información como passwords, nombre de
servidores, direcciones IP, lenguaje de
programación o las rutas del sistema de
archivos que revelan la estructura de los
directorios del Servidor Web.
46
 Directrices de Programación Segura

Sentencias SQL
Cuando las consultas se construyen directamente con los datos del usuario
entre líneas o concatenan directamente con el texto de la consulta, en lugar de
utilizar los parámetros de vinculación de tipo seguro, esto puede permitir al
atacante realizar un ataque de inyección SQL y consiste en una debilidad de
programación en que la aplicación construye dinámicamente consultas SQL
utilizando la concatenación de cadenas de datos.

47
 Desarrollo Seguro en JAVA

48
 Desarrollo Seguro en JAVA

En la actualidad JAVA es uno de los lenguajes de programación más populares,

debido a que funciona con las principales plataformas de hardware y sistemas
operativos. Entre las características más relevantes de este lenguaje se puede
mencionar que es simple, orientado a objetos y robusto.

Muchos autores agregan a esta lista de

atributos que es un lenguaje seguro, o al menos
más seguro que el resto. Una gran parte de las
vulnerabilidades de una aplicación están
asociadas al acceso a memoria, por lo mismo,
JAVA está diseñado eliminando las
características que facilitan esta práctica,
además de incorporar algunos métodos que
corrigen problemas relacionados con los
accesos ilegales a memoria.

49
 Desarrollo Seguro en JAVA

Eliminación de la aritmética con punteros. JAVA elimina por completo la

aritmética con punteros, que es una de las mayores fuentes de accesos ilegales
a memoria en otros lenguajes. De cualquier forma, esto no quiere decir que
Java no disponga de la noción de puntero, la incluye dándole el nombre de
referencia.

Comprobación de rangos en el acceso a

vectores. En JAVA se controlan todos
los accesos a vector y se lanza una
excepción cuando intentamos un acceso
fuera de rango. En los lenguajes que esto
no se hace, el programador puede
acceder a memoria que está más allá de
la reservada para el vector y modificar
valores de otras variables de forma no
controlada.
50
 Desarrollo Seguro en JAVA

Definición del comportamiento de las variables sin inicializar. En otros

lenguajes los valores de las variables no inicializadas están indeterminados, por
lo que si accedemos a ellas antes de darles un valor podemos obtener
resultados impredecibles. Esto en JAVA no es así, toda la memoria se inicializa
automáticamente.
Eliminación de la liberación de memoria
controlada directamente por el programador. En
otros lenguajes, cuando un objeto creado
dinámicamente deja de ser necesario el
responsable de liberar la memoria que tiene
asignada es el programador. JAVA elimina este
problema no proporcionando funciones de
liberación de memoria; cuando las variables u
objetos ya no son referenciadas la memoria que
ocupan es liberada por un sistema de recolección
de basura automático (garbage collection).
51
 Desarrollo Seguro en JAVA

Además de lo anterior, también existen otras características del lenguaje JAVA

que contribuyen a escribir código seguro:

• El sistema de verificación de tipos en tiempo de compilación, que garantiza

que las variables son de los tipos correctos.

• Los niveles de acceso a los miembros de las clases, que permite controlar la
visibilidad de atributos y métodos.

• El modificador final, que permite impedir que se definan subclases cuando se

aplica a una clase o que se puedan redefinir atributos cuando se les aplica a
ellos.

52
 Desarrollo Seguro en JAVA

Impresión de Mensajes de Salida

La impresión de mensajes de consola es ampliamente utilizada en el proceso de
codificación de software debido a que le permite al desarrollador realizar
seguimiento a funcionalidades y navegar por métodos, clases dejando
simplemente mensajes alrededor del código.

El problema de esta práctica es que en

algunas ocasiones se olvida eliminar
estos mensajes y salen al ambiente de
producción siendo de gran ayuda para
un potencial atacante, pudiendo
conocer nombres de clases, métodos, la
tecnología usada, consultas a la base de
datos, etc.

53
 Desarrollo Seguro en JAVA

Encapsulación
En JAVA si se declara una clase, método o campo sin un modificador de acceso
(privado, público y protegido) luego estos paquetes por defecto tienen acceso a
ninguna clase dentro del mismo paquete, se debe tener en cuenta que si bien
esto proporciona encapsulación para el paquete, esto sólo sucede si cada trozo
de código que se carga en el paquete es controlado por personas autorizadas.

Un usuario malintencionado puede insertar sus

propias clases y tener pleno acceso a todas las
clases, métodos y campos en el paquete. La idea de
usar correctamente la encapsulación es poder
ocultar detalles de implementación tales como
variables internas que mantienen el estado de un
objeto y los mecanismos internos como son
algoritmos entre otros.
54
 Desarrollo Seguro en JAVA

Manejo de Excepciones
El manejo de excepciones es fundamental para lograr un correcto desarrollo
seguro de código ya que cuando un código JAVA viola restricciones semánticas
del lenguaje se produce un error que es lanzado por la máquina virtual. Existen
muchas clases de errores que generan excepciones y nos dan a entender fallos
como desbordamiento de búfer, desbordamiento de memoria, intentar acceder
a un vector fuera de sus límites, entre otras.

Si no se capturan adecuadamente le
puede dar indicios a un atacante sobre
fallos en el código, nombre de la clase o
método que genera el problema y le
puede dar las bases para un futuro
ataque.

55
 Recuerde utilizar los foros de cada módulo
56
CLASE 3