Pgina | 0

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s






Plataforma Avanza Local Soluciones
AL e-fcil
Buenas prcticas de calidad en el desarrollo de
aplicaciones
SEGURIDAD

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

S
o
l
u
c
i
o
n
e
s



Pgina | 1

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s


ndice:

1. Introduccin
2. Principios del desarrollo seguro
3. Recomendaciones
3.1 Acceso a base de datos
3.1.1 Inyeccin SQL
3.1.2 Control de acceso
3.2 Acceso al sistema de ficheros
3.2.1 Manipulacin de rutas
3.2.2 Inyeccin de comandos
3.2.3 Uso indebido: subida de archivos
3.3 Gestin de logs
3.3.1 Falsificacin de log
3.3.2 Usos indebidos
3.4 Configuracin
3.4.1 Contraseas en ficheros de configuracin
3.4.2 Esquema XML dbil
3.5 Generacin de contenido web
3.5.1 Cross-Site Scripting (XSS)
3.5.2 Manipulacin de cabeceras
3.5.3 Cross-Site Request Forgery
3.6 Criptografa
3.6.1 Encriptacin dbil
3.7 Control de acceso
3.7.1 Fijacin de sesin
3.8 Diseo
3.8.1 Condicin de carrera: Variable miembro Singleton
3.8.2 Almacenar objetos no serializables en sesin
3.9 Gestin de recursos
3.9.1 Recurso no liberado
3.9.2 Denegacin de servicio
3.10 Revelacin de informacin
3.10.1 Violacin de privacidad
3.10.2 Fuga de informacin del sistema
3.10.3 Contraseas escritas directamente en el cdigo
4. Verificacin
5. Valoracin de la seguridad de las aplicaciones
6. ENS (Esquema Nacional de Seguridad)




Pgina | 2

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

1. INTRODUCCION

Esta gua se encuentra dividida en tres apartados principales. La informacin en cada
uno de estos apartados se estructura de la siguiente manera:

En primer lugar, se describen los principios en los que debe basarse el
desarrollo de software para mejorar la calidad de la aplicacin en cada una de las
categoras.

Como segundo punto se detallan recomendaciones a nivel de codificacin, orientadas
principalmente a usuarios con perfil de desarrollador dentro de la comunidad.

A continuacin, como tercer punto, se especifican pautas que deben llevarse a cabo
para verificar si las recomendaciones de codificacin han sido implementadas y, por
tanto, la aplicacin no contiene problemas de seguridad. En este caso, las
recomendaciones estn orientadas a aquellos usuarios que poseen un rol de auditor
dentro de la comunidad.

Por ltimo, el gestor de la comunidad ser el encargado de valorar los resultados obtenidos en
el punto anterior con el fin de determinar el grado de cumplimiento de las recomendaciones
establecidas en el mbito de la seguridad, adoptando acciones correctivas siempre que sea
necesario.

Seguridad

Como se ha comentado anteriormente, la seguridad de la informacin se basa en los tres
siguientes pilares principales:
Confidencialidad. Slo se debe permitir el acceso a los datos a los cuales el
usuario est autorizado.
Integridad. Se debe asegurar que los datos no son manipulados por usuarios
no autorizados.
Disponibilidad. Los datos deben estar disponibles de manera permanente para
los usuarios autorizados.

Para garantizar el cumplimiento de estos tres fundamentos, durante el desarrollo de las
aplicaciones deben implementarse distintos controles de seguridad. En general, pueden
encajarse en los siguientes grupos en funcin del objeto para el cual se construyan:
Controles de prevencin de accesos no autorizados.
Controles sobre las entradas de datos en la aplicacin, para evitar que ciertos
datos provoquen que la aplicacin no se comporte de la manera deseada.
Controles para asegurar el funcionamiento correcto de la aplicacin cuando
est siendo directamente atacada.
Controles de gestin de la propia aplicacin para monitorizar la actividad de la
aplicacin y configurar su comportamiento.


Pgina | 3

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

Piensa como el atacante
Los desarrolladores involucrados en la implementacin de estos controles de seguridad
deben ponerse en la piel de un usuario atacante, valorando en cada una de las
funcionalidades que est implementando los siguientes puntos:
el proceso que envuelve a la funcionalidad es seguro?
de qu manera podra abusar de esa funcionalidad?
es necesario que la funcionalidad est activa por defecto? Si es as, qu
opciones minimizan el riesgo de uso de la misma?

Toda entrada es maliciosa
Adems, el desarrollador debe tener en cuenta en todo momento durante el desarrollo que la
aplicacin debe considerar que toda entrada es potencialmente maliciosa y reaccionar
aplicando las medidas necesarias que aseguren que un atacante no pueda utilizar estas
entradas como medio para comprometer la aplicacin.

No existe el software libre de errores
El software siempre tendr errores y, por extensin, vulnerabilidades de seguridad. Por lo
tanto, un objetivo prctico en el ciclo de vida de desarrollo de software seguro debera ser
reducir al mximo (no necesariamente eliminar), el nmero de vulnerabilidades introducidas y
la severidad de aquellas que no hayan sido eliminadas.

Una sola vulnerabilidad S es suficiente
La explotacin de una nica vulnerabilidad en una aplicacin web es suficiente para
interrumpir de manera significativa el negocio, provocar prdida de datos, daar la confianza
del cliente, etc. Por ello, cuanto antes sean identificadas y corregidas las vulnerabilidades,
menor ser la oportunidad para un atacante de explotarlas maliciosamente.


















Pgina | 4

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

2. PRINCIPIOS DE DESARROLLO SEGURO

Independientemente del lenguaje y la arquitectura utilizados, el desarrollo de la
aplicacin y de los controles de seguridad necesarios deben llevarse a cabo teniendo
en cuenta una serie de principios de seguridad que traten de reducir la probabilidad de
la realizacin de
amenazas y el impacto de stas en el caso de que se hayan producido ya.
Aunque estos principios pueden servir como pautas generales, para que sean
realmente tiles, deben ser evaluados, interpretados y aplicados para abordar cada
problema especfico. La consideracin de cada uno de ellos puede derivar en la
identificacin de requisitos de seguridad, la toma de decisiones relativas a la
arquitectura y la implementacin e identificacin de posibles debilidades en el sistema.

Minimizar la superficie de ataque
Cada funcionalidad que se incorpora a una aplicacin aade cierto riesgo al conjunto.
Uno de los principios de la programacin segura consiste en disminuir el riesgo
reduciendo la superficie de ataque.
Por ejemplo, si una aplicacin implementa un mdulo de ayuda con una funcionalidad
de bsqueda, dicha funcionalidad puede ser vulnerable a inyeccin SQL. Si la ayuda
est limitada a usuarios autorizados, la posibilidad de ataque se reduce. Si adems la
funcionalidad de bsqueda utiliza rutinas de validacin de los datos de entrada, la
posibilidad de inyeccin SQL disminuye drsticamente. Sin embargo, si la ayuda se
redisea y se elimina la posibilidad de bsqueda (proporcionando como alternativa una
mejor interfaz de usuario), esto prcticamente elimina la superficie de ataque del
mdulo de ayuda, incluso si la ayuda fuese accesible desde Internet.

Seguridad por defecto
Cuando una aplicacin se despliega en su entorno de produccin, utiliza una serie de
opciones de configuracin que se establecen por defecto. Estas opciones por defecto
deben ser tales que la aplicacin sea segura. Es responsabilidad del usuario modificar
dichas opciones an a costa de disminuir la seguridad.
Por ejemplo, por defecto una aplicacin debera tener habilitada la expiracin de
contraseas y una poltica de complejidad de claves adecuada. Una vez desplegada, los
usuarios podran deshabilitar estas opciones o relajar las restricciones an a costa de
aumentar el riesgo, pero siempre bajo su responsabilidad.


Ejecucin con los mnimos privilegios
El principio de mnimos privilegios establece que las cuentas deben tener el menor
nivel de privilegios posible para realizar las tareas de negocio. Este nivel de privilegios
abarca tanto permisos de usuarios como permisos sobre recursos como CPU, memoria,
red, sistema de ficheros, etc.
Por ejemplo, si una aplicacin slo requiere acceso a la red, permisos de lectura sobre
una tabla de la base de datos y la posibilidad de escribir en un fichero de log, estos

Pgina | 5

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

deben ser los nicos permisos que debe tener la cuenta bajo la que se ejecute la
aplicacin. Bajo ningn concepto la aplicacin debe tener permisos administrativos.

Defensa en profundidad
El principio de defensa en profundidad sugiere que donde un nico control de
seguridad podra ser asumible, sera mejor utilizar varios controles que afronten el
riesgo desde distintos puntos de vista. Los controles de seguridad, cuando se utilizan
con el enfoque de defensa en profundidad, hacen que vulnerabilidades que pueden ser
muy graves, sean tremendamente difciles de explotar.
Por ejemplo, siguiendo este principio, una aplicacin implementara distintas medidas
en varias capas para prevenir inyecciones SQL: rutinas de validacin de datos para
comprobar las entradas del usuario, consultas parametrizadas a la hora de ejecutar las
sentencias SQL y establecimiento adecuado de permisos a nivel de tablas y
procedimientos almacenados en la base de datos.

Fallar de forma segura
En muchas ocasiones se producen errores cuando las aplicaciones realizan una
transaccin. El estado en que la aplicacin queda cuando se produce dicho error,
determina si la aplicacin es segura o no. Supongamos el siguiente fragmento de
cdigo.

isAdmin = true;
try {
codeWhichMayFail();
isAdmin = isUserInRole( Administrator );
}
catch (Exception ex) {
log.write(ex.toString());
}

Si los mtodos codeWhichMayFail() o isUserInRole() fallan o lanzan una excepcin, el
usuario queda como administrador (isAdmin=true), lo cual, obviamente, es un
problema de seguridad. La aplicacin debe garantizar, en este ejemplo, que en caso de
error el valor de isAdmin sea false.

Deteccin de intrusos
La deteccin de intrusiones requiere la existencia de tres elementos:
Capacidad para incluir en el log eventos relevantes de seguridad.
Procedimientos que aseguren que los logs son monitorizados con
regularidad.
Procedimientos para responder adecuadamente a una intrusin una
vez ha sido detectada.
Toda la informacin de seguridad relevante debe ser registrada en un log. Es posible
que un problema que no pudo ser detectado en tiempo de ejecucin, pueda serlo
gracias a la revisin de los logs. Para ello, es fundamental que se registre suficiente
informacin para ayudar a localizar al atacante y que se proporcione un mtodo para

Pgina | 6

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

gestionar la informacin registrada. Si al analizar los eventos registrados no se puede
determinar cules de ellos son procesables, se pierde el valor que posee el registro
de dichos eventos.
No se debe confiar en otras tecnologas para detectar intrusiones. El cdigo de cada
aplicacin es el nico componente del sistema que tiene suficiente informacin para
detectar ataques de manera fiable. Slo la propia aplicacin conoce qu parmetros
son vlidos, qu acciones estn permitidas para el usuario, etc. Por ello, debe
construirse dentro de la misma.
La importancia de la deteccin de intrusiones reside en que, sin ella, se proporciona al
atacante tiempo ilimitado para perfeccionar un ataque. Si la deteccin de intrusiones
fuese perfecta, el atacante tendra un nico intento antes de ser detectado y de que
pueda lanzar otros ataques.
















No confiar en los servicios

Muchas organizaciones utilizan servicios proporcionados por terceras partes para
realizar determinados procesos de negocio. Sin embargo, estas terceras partes pueden
tener criterios y polticas de seguridad muy distintas a las de la organizacin que usa el
servicio.
Por lo tanto, todos los sistemas y servicios externos deben ser tratados como no
confiables. Por ejemplo, una aplicacin de banca puede utilizar un servicio externo que
ofrece informacin sobre cotizacin de acciones. Pues bien, la aplicacin de banca
debera validar todos los datos que le llegan de este servicio externo para comprobar
que son seguros para ser mostrados en una pgina web, que tienen el tipo y rango
correctos, etc.

Evitar la seguridad por ocultacin
La seguridad por ocultacin es un mecanismo de seguridad dbil y generalmente falla
cuando es el nico control existente. La seguridad de un sistema nunca debe recaer en
la cultacin de secretos.
Por ejemplo, la seguridad de una aplicacin no puede depender de mantener en

Pgina | 7

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

secreto el cdigo fuente. Un ejemplo podra ser el sistema operativo Linux; su cdigo
fuente est disponible, sin embargo, cuando est correctamente configurado, es un
sistema seguro.

Mantener la simplicidad

Cuando el cdigo fuente es muy complejo es ms complicado hacerlo seguro. Es mejor
mantenerlo simple.
Hay que tener en cuenta que cuando se desarrollan nuevas versiones o se solucionan
defectos, los programadores que intentan hacer segura la aplicacin pueden no ser los
mismos que desarrollaron el cdigo inicialmente. Cuantas ms lneas de cdigo hay,
ms probabilidades de introducir vulnerabilidades.

Solucionar correctamente los problemas de seguridad
Una vez que se ha detectado un problema de seguridad, es fundamental desarrollar
pruebas para reproducirlo y detectar la causa raz. Una vez que se desarrolla una
solucin vlida es clave garantizar que no se introducen problemas de regresin.
Por ejemplo, un usuario descubre que puede ver datos de otro usuario modificando un
valor en una cookie. Pero debido a que el mecanismo de gestin de cookies es
compartido por todas las aplicaciones, un cambio en el cdigo de este control afecta no
slo a la aplicacin en la que se detect el problema, sino a todas. Por lo tanto, la
solucin debe ser probada en todas las aplicaciones.















Pgina | 8

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

3. Recomendaciones

Como se ha tratado anteriormente, durante el desarrollo de una aplicacin deben
implementarse controles que garanticen la seguridad de la misma. Los errores de
programacin que se cometen durante esta implementacin pueden desembocar en
vulnerabilidades de seguridad en las aplicaciones.
A continuacin se describen algunos de estos problemas o vulnerabilidades de
seguridad, basados en las siguientes listas de referencia, en las que se incluyen los
errores ms crticos y extendidos que pueden conducir a vulnerabilidades serias en las
aplicaciones, generalmente fciles de encontrar y explotar:
2010 CWE/SANS Top 25 Most Dangerous Programming Errors
OWASP Top Ten Project
El grado de explotacin de muchas de estas vulnerabilidades es mayor de lo que un
desarrollador pueda pensar a priori. En el grfico siguiente, basado en el estudio
realizado por WhiteHat Security en el ao 2010, puede verse la probabilidad de
aparicin de algunas de estas vulnerabilidades:
Como puede verse, el 64% de los sitios web del estudio posean al menos una
vulnerabilidad de fuga de informacin del sistema y de Cross-Site Scripting. Adems, en
el estudio se destaca el crecimiento respecto a aos anteriores del porcentaje de
vulnerabilidades de Cross-Site Request Forgery. Por ltimo, el estudio subraya que, a

Pgina | 9

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

pesar de que se resolvieron gran cantidad de vulnerabilidades de tipo SQL Injection, en
un 14% de los sitios web se detect todava este tipo de problema.
En los apartados que se encuentran a continuacin se explica cmo puede ser
explotado cada tipo de vulnerabilidad, proporcionando ejemplos y recomendaciones
en lenguaje Java para prevenir posibles ataques que puedan aprovechar la
vulnerabilidad en cuestin.

3.1 Acceso a bases de datos
3.1. Inyeccin SQL

Descripcin
Construir una sentencia SQL dinmica utilizando para ello la entrada proporcionada por
un usuario podra permitir a un atacante modificar el significado de la sentencia o
incluso ejecutar comandos SQL arbitrarios.
Los errores de inyeccin SQL se presentan cuando se cumplen las siguientes
condiciones:
El programa recibe datos que proceden de una fuente no confiable.
Dichos datos son utilizados para construir dinmicamente una
sentencia SQL.

Ejemplo 1:
El siguiente cdigo construye dinmicamente y ejecuta una sentencia SQL que sirve
para buscar elementos cuyo nombre coincida con un texto determinado. La sentencia
limita el nmero de elementos mostrados a aqullos cuyo propietario coincida con el
nombre de usuario del usuario actualmente autenticado.
...
String userName = ctx.getAuthenticatedUserName();
String itemName = request.getParameter("itemName");
String query = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ itemName + "'";
ResultSet rs = stmt.execute(query);
...




La sentencia que este cdigo pretende ejecutar es la siguiente:
SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;

Sin embargo, y debido a que la sentencia es construida dinmicamente concatenando
una cadena fija con cadenas procedentes de la entrada del usuario, la sentencia se
comporta como es esperado slo si <itemName> no contiene un carcter de comilla
simple (). Si un atacante con nombre de usuario wiley introduce la cadena "name'

Pgina | 10

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

OR 'a'='a'" para el parmetro <itemName>, entonces la sentencia resultante es la
siguiente:
SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';

Al aadir OR 'a'='a' a la clusula WHERE, sta siempre es evaluada a verdadero, por lo
que la sentencia es lgicamente equivalente a la sentencia ms simple:
SELECT * FROM items;

La simplificacin de la sentencia permite al atacante saltarse el requerimiento de que
slo se deben devolver los elementos que pertenezcan al usuario autenticado. De esta
forma, se devuelven todos los elementos de la tabla, independientemente de a qu
usuario correspondan.
Ejemplo 2:
El siguiente ejemplo examina el efecto producido utilizando un valor malicioso distinto
del usado en el ejemplo anterior. Si el atacante con nombre de usuario wiley
introduce la cadena "name'; DELETE FROM items; --" para el parmetro <itemName>,
entonces la sentencia se convierte en lo siguiente:
SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';
DELETE FROM items;
--'

Muchos servidores de bases de datos (por ejemplo, Microsoft SQL Server 2000)
permiten que mltiples sentencias separadas por un punto y coma sean ejecutadas de
una vez.
Mientras que esta cadena maliciosa dara lugar a un error en Oracle y otros sistemas
gestores de bases de datos que no permiten la ejecucin por lotes de sentencias
separadas por punto y coma, en los sistemas que s lo permiten, este tipo de ataque
permitira a un atacante ejecutar comandos SQL arbitrarios contra la base de datos.
Hay que hacer notar el par de guiones que se utilizan al final de la sentencia (--). La
mayora de los sistemas gestores de bases de datos interpretan estos caracteres como
que el resto de la sentencia es un comentario y por lo tanto no debe ser ejecutada. En
este caso, los caracteres de comentario sirven para anular el carcter de comilla simple
que queda al final de la sentencia modificada. En los sistemas de bases de datos que no
permiten que los caracteres de comentario sean utilizados de esta forma, el ataque
todava puede hacerse efectivo usando para ello un truco similar al del ejemplo 1. Si un
atacante introduce la cadena "name'; DELETE FROM items; SELECT * FROM items
WHERE 'a'='a'", entonces se crearn las siguientes tres sentencias vlidas:
SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';
DELETE FROM items;
SELECT * FROM items WHERE 'a'='a';

Pgina | 11

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s


Un enfoque tradicional para prevenir este tipo de ataques de inyeccin SQL es tratarlos
como un problema de validacin de datos de entrada y slo aceptar los caracteres que
se encuentran en una lista blanca de valores seguros o bien identificar y utilizar
secuencias de escape sobre valores potencialmente maliciosos de una lista negra. El
uso de listas blancas puede ser una forma efectiva de forzar reglas estrictas de
validacin, pero las sentencias SQL parametrizadas requieren menos mantenimiento y
pueden ofrecer ms garantas en lo que se refiere a la seguridad. En la mayora de los
casos, las listas negras estn plagadas de omisiones que las hacen inefectivas para
prevenir ataques de inyeccin SQL. Por ejemplo, un atacante puede:
Dirigir el ataque a campos que no estn contemplados en la lista
negra.
Encontrar formas de evitar la obligacin de utilizar secuencias de
escape con determinados caracteres.
Utilizar procedimientos almacenados para ocultar los caracteres
inyectados.
La aplicacin de secuencias de escape manualmente a las entradas de sentencias SQL
puede ayudar en ocasiones, pero no es una forma efectiva de hacer las aplicaciones
seguras frente a ataques de inyeccin SQL.
Otra solucin comnmente propuesta para prevenir ataques de inyeccin SQL es
utilizar procedimientos almacenados. A pesar de que los procedimientos almacenados
pueden servir para prevenir ciertos tipos de ataques de inyeccin SQL, no pueden
prevenir muchos otros tipos. Tpicamente, los procedimientos almacenados ayudan a
prevenir los ataques de inyeccin SQL limitando el tipo de sentencias que pueden
pasarse como valores de sus parmetros. Sin embargo, hay muchas formas de saltarse
estas limitaciones y hay muchas sentencias interesantes que s pueden ser pasadas a
los procedimientos almacenados. Por lo tanto, los procedimientos almacenados
pueden evitar ciertos exploits, pero no hacen a la aplicacin completamente segura
frente a los ataques de inyeccin SQL.

Recomendaciones
La causa raz de una vulnerabilidad de inyeccin SQL es la habilidad de un atacante
para cambiar el contexto en una sentencia SQL, provocando que un valor que el
programador pretenda fuese interpretado como datos sea interpretado como un
comando. Cuando una sentencia SQL es construida, el programador sabe qu tiene que
ser interpretado como datos y qu tiene que ser interpretado como parte de un
comando. Las sentencias SQL parametrizadas pueden forzar este comportamiento,
evitando as la prctica totalidad de los ataques por inyeccin SQL.
Las sentencias SQL parametrizadas se construyen utilizando cadenas de SQL normal,
pero en los puntos en los que se requiere incluir datos procedentes del usuario, se
incluyen parmetros de enlace (bind parameters) que no son ms que marcadores de
posicin (placeholders) para datos que se insertan posteriormente. En otras palabras,
los parmetros de enlace permiten al programador especificar explcitamente qu
debe ser tratado como datos y qu debe ser tratado como comandos. Cuando el
programa est listo para ejecutar una sentencia, sta proporciona al motor de base de

Pgina | 12

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

datos los valores de los parmetros de enlace sin correr el peligro de que estos valores
sean interpretados como parte de la sentencia.
El ejemplo anteriormente utilizado puede ser reescrito usando sentencias SQL
parametrizadas (en vez de concatenando cadenas proporcionadas por el usuario):
...
String userName = ctx.getAuthenticatedUserName();
String itemName = request.getParameter("itemName");
String query =
"SELECT * FROM items WHERE itemname=? AND owner=?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setString(1, itemName);
stmt.setString(2, userName);
ResultSet results = stmt.execute();

En escenarios ms complicados, que generalmente se encuentran en el mbito de la
generacin de informes, se requiere que la entrada del usuario afecte a la estructura
de la sentencia SQL, por ejemplo, aadiendo dinmicamente una restriccin a una
clusula WHERE. No hay que utilizar esto como una excusa para concatenar
directamente la entrada del usuario para crear la sentencia SQL. En estos casos se
pueden prevenir los ataques de inyeccin SQL introduciendo un nivel de indireccin
adicional: crear un conjunto de cadenas legtimas que se correspondan con los
distintos elementos que se deben incluir en la sentencia SQL; cuando se construya la
sentencia, utilizar la entrada de usuario para seleccionar el elemento adecuado de esta
lista de valores controlados. Un error habitual es utilizar sentencias SQL parametrizadas
que se construyen concatenando cadenas introducidas por el usuario. Evidentemente,
esto anula el propsito de las sentencias parametrizadas. Si no se est seguro de que
las cadenas utilizadas para formar la sentencia SQL parametrizadas provienen de
constantes controladas por la aplicacin, no asuma que son seguras por el simple
hecho de que no se ejecutan directamente como cadenas SQL. Investigue todos los
usos de las cadenas controladas por el usuario en sentencias SQL y verifique que no
pueden ser utilizadas para modificar el comportamiento de la sentencia.

3.1.2 Control de acceso

Descripcin
Sin el control de acceso adecuado, ejecutar una sentencia SQL que contenga una clave
primaria controlada por el usuario puede provocar que un atacante tenga acceso a
registros que no est autorizado a ver.
Los errores de control de acceso a base de datos se dan cuando:
El programa recibe datos que proceden de una fuente no confiable.
Los datos son utilizados para especificar el valor de una clave primaria
en una sentencia SQL.
Ejemplo 1:
El siguiente cdigo utiliza sentencias parametrizadas, que previenen ataques de tipo
inyeccin SQL, para ejecutar una consulta que busca facturas que coincidan con el
identificador proporcionado. El identificador se selecciona de una lista que contiene

Pgina | 13

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

todas las facturas asociadas al usuario actualmente autenticado.
...
id = Integer.decode(request.getParameter("invoiceID"));
String query = "SELECT * FROM invoices WHERE id = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setString(1, id);
ResultSet results = stmt.execute();
...

El problema reside en que el programador no ha tenido en cuenta todos los posibles
valores que puede tener el parmetro invoiceID. A pesar de que la interfaz de usuario
presenta una lista con los identificadores de facturas que pertenecen al usuario actual,
un atacante puede evitar la interfaz y hacer una peticin especificando cualquier
identificador de factura.
Puesto que el cdigo no comprueba que el usuario tenga permisos para ver la factura
solicitada, mostrar cualquier factura, independientemente de que pertenezca o no al
usuario autenticado.

Recomendaciones
En vez de confiar en la interfaz de usuario para restringir los valores que pueden ser
enviados por el usuario, la aplicacin y la capa de base de datos deben implementar un
control de acceso. Bajo ninguna circunstancia se debe permitir que un usuario obtenga
o modifique un registro de la base de datos sin tener los permisos adecuados. Esta
poltica debe ser aplicada a toda consulta que llegue a la base de datos, lo cual puede
hacerse simplemente incluyendo en la consulta el nombre de usuario del usuario
actualmente autenticado.
Ejemplo 2:
El siguiente ejemplo implementa la misma funcionalidad que el ejemplo 1, pero
impone una restriccin adicional exigiendo que el usuario autenticado tenga acceso
especfico a la factura.

...
userName = ctx.getAuthenticatedUserName();
id = Integer.decode(request.getParameter("invoiceID"));
String query =
"SELECT * FROM invoices WHERE id = ? AND user = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setString(1, id);
stmt.setString(2, userName);
ResultSet results = stmt.execute();

3.2 Acceso al sistema de ficheros
3.2.1 Manipulacin de rutas

Descripcin
Permitir que las entradas de usuario controlen las rutas utilizadas en operaciones con

Pgina | 14

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

el sistema de ficheros puede permitir a un atacante acceder o modificar recursos que
de otra manera estaran protegidos.
Los errores de manipulacin de rutas se dan cuando se cumplen las dos siguientes
condiciones:
Un atacante puede especificar una ruta utilizada en una operacin
con el sistema de ficheros.
Al especificar el recurso, el atacante adquiere unos privilegios que de
otra forma no tendra.
Por ejemplo, el programa puede dar a un atacante la posibilidad de sobrescribir un
fichero o ejecutarse bajo una configuracin controlada por el atacante.
Ejemplo 1:
El siguiente cdigo utiliza la entrada procedente de una peticin HTTP para crear el
nombre de un fichero. El programador no ha considerado la posibilidad de que un
atacante pueda especificar un nombre de fichero como "../../tomcat/conf/server.xml",
lo que causara que la aplicacin sobrescribiese uno de sus ficheros de configuracin.
String rName = request.getParameter("reportName");
File rFile = new File("/usr/local/apfr/reports/" + rName);
...
rFile.delete();

Ejemplo 2:
El siguiente cdigo utiliza la entrada procedente de un fichero de configuracin para
determinar qu fichero tiene que abrir y devolver el contenido al usuario. Si la
aplicacin se ejecuta con determinados privilegios y un atacante puede modificar el
fichero de configuracin, podra utilizar la aplicacin para leer cualquier fichero del
sistema cuya extensin sea .txt.

fis = new FileInputStream(cfg.getProperty("sub")+".txt");
amt = fis.read(arr);
out.println(arr);

Recomendaciones
La mejor forma de evitar la manipulacin de rutas es introducir un nivel de indireccin:
crear una lista de nombres de recursos legtimos que un usuario pueda especificar y
nicamente permitir al usuario seleccionar de esta lista. De esta forma, la entrada del
usuario nunca es utilizada directamente para especificar el nombre del recurso.
En algunas situaciones, este enfoque no es prctico, porque la lista de nombres de
recursos legtimos es demasiado larga. En estas ocasiones, los programadores suelen
utilizar listas negras. Las listas negras rechazan de forma selectiva o bien aplican
secuencias de escape a caracteres potencialmente peligrosos antes de utilizar la
entrada del usuario. Sin embargo, cualquier lista negra tiene una alta probabilidad de
ser incompleta y frecuentemente queda desfasada. Una mejor estrategia consiste en
crear una lista blanca de los caracteres que estn permitidos en el nombre del recurso
y aceptar exclusivamente las entradas que contengan esos caracteres.
Es notablemente difcil realizar una implementacin adecuada de una lista negra. Si la

Pgina | 15

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

lgica de validacin recae en una lista negra, sea escptico. Tenga en cuenta los
distintos tipos de codificaciones de datos de entrada y los distintos tipos de meta-
caracteres que pueden tener un significado especial cuando son interpretados por
distintos sistemas operativos, bases de datos u otros recursos. Tenga en cuenta si la
lista negra puede ser actualizada fcil, correcta y completamente si estos
requerimientos cambian.

3.2.2 Inyeccin de comandos

Descripcin
Ejecutar comandos procedentes de una fuente no confiable o en un entorno no
confiable puede provocar que la aplicacin ejecute comandos maliciosos en nombre
del atacante.
Las vulnerabilidades de inyeccin de comandos pueden adoptar dos formas:
Un atacante puede modificar el comando que ejecuta una aplicacin,
controlando as explcitamente lo que el comando es.
Un atacante puede modificar el entorno en el que se ejecuta un
comando, controlando as implcitamente lo que el comando significa.
Centrndonos principalmente en el primer escenario, es decir, la posibilidad de que un
atacante pueda controlar el comando que se ejecuta, las vulnerabilidades de inyeccin
de
comandos de este tipo se producen cuando:
1. El programa recibe datos que proceden de una fuente no confiable.
2. Dichos datos son utilizados como parte de una cadena que representa el
comando que es ejecutado por la aplicacin.
3. Al ejecutar el comando, la aplicacin otorga al atacante un privilegio o
capacidad que de otra forma no tendra.

Ejemplo 1:
El siguiente cdigo de una utilidad de sistema utiliza la propiedad de sistema APPHOME
para determinar el directorio en el que est instalada y ejecutar un script de
inicializacin basado en una ruta relativa a dicho directorio.
...
String home = System.getProperty("APPHOME");
String cmd = home + INITCMD;
java.lang.Runtime.getRuntime().exec(cmd);
...

El cdigo en el ejemplo 1 permite a un atacante ejecutar comandos arbitrarios con el
nivel de privilegios correspondiente a la aplicacin simplemente modificando la
propiedad de sistema APPHOME para que apunte a una ruta diferente que contenga
una versin maliciosa de INITCMD. Debido a que la aplicacin no valida el valor ledo
de la propiedad APPHOME, la aplicacin puede ser engaada para que ejecute cdigo
malicioso que tome el control del sistema.

Ejemplo 2:

Pgina | 16

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

El siguiente cdigo corresponde a una aplicacin web de administracin que permite a
los usuarios realizar un backup de una base de datos Oracle utilizando para ello un
script rmanDB.bat que utiliza la utilidad rman y despus un script cleanup.bat que
elimina algunos ficheros temporales.
El script rmanDB.bat acepta un nico parmetro por lnea de comandos que especifica
qu tipo de backup realizar. Debido a que el acceso a la base de datos est restringido,
la aplicacin se ejecuta bajo un usuario con privilegios elevados.
...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\utl\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...

El problema aqu es que el programa no hace ninguna validacin sobre el valor del
parmetro que se lee de la lnea de comandos. Tpicamente, la funcin Runtime.exec()
no ejecuta comandos mltiples, pero en este caso el programa primero ejecuta el shell
cmd.exe con el propsito de ejecutar mltiples comandos a travs de una nica
llamada a Runtime.exec(). Una vez que se ha ejecutado el shell, ste ejecutar sin
problemas mltiples comandos separados por &&. Si un atacante pasa una cadena con
la forma "&& del c:\\dbms\\*.*", entonces la aplicacin ejecutar este comando junto
con cualquier otro especificado por el programa. Por las caractersticas de la aplicacin,
sta se ejecuta con privilegios suficientes para interactuar con la base de datos, lo que
significa que cualquier comando que el atacante logre inyectar se ejecutar tambin
con estos privilegios.
Ejemplo 3:
El siguiente cdigo corresponde a una aplicacin web que da acceso a los usuarios a
una interfaz a travs de la cual pueden actualizar su contrasea en el sistema. Parte del
proceso para actualizar contraseas en determinados entornos de red consiste en
ejecutar un comando make en el directorio /var/yp, para la cual sirve el siguiente
cdigo:
...
System.Runtime.getRuntime().exec("make");
...
El problema aqu est en que el programa no especifica una ruta absoluta para el
comando make y en que falla al limpiar su entorno antes de ejecutar la llamada a
Runtime.exec(). Si un atacante puede modificar la variable $PATH para apuntar a un
binario malicioso llamado make, y forzar al programa a que sea ejecutado en esas
condiciones, entonces el binario malicioso ser cargado en vez del que se pretenda.
Debido a las caractersticas de la aplicacin, sta se ejecuta con privilegios suficientes
para ejecutar tareas de sistema, lo que significa que el binario make del atacante ser
ejecutado con esos privilegios, posiblemente otorgando al atacante control total sobre
el sistema.

Recomendaciones
No permita a los usuarios tener control directo sobre los comandos que ejecuta una

Pgina | 17

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

aplicacin. En los casos en los que la entrada del usuario deba afectar al comando que
se va a ejecutar, utilice la entrada slo para realizar una seleccin de una lista
predeterminada de comandos seguros. Si la entrada del usuario parece maliciosa, el
valor que se pase a la funcin que ejecuta el comando debe ser un valor por defecto
que garantice que se elige un elemento seguro de la lista o bien se debe denegar
completamente la ejecucin del comando.
En el caso de que se deba utilizar la entrada de usuario como argumento a un comando
que ser ejecutado por la aplicacin, el enfoque anterior no es prctico, ya que se
debera controlar una lista muy amplia de argumentos legtimos. En estas ocasiones,
los programadores suelen utilizar listas negras. Las listas negras rechazan de forma
selectiva o bien aplican secuencias de escape a caracteres potencialmente peligrosos
antes de utilizar la entrada del usuario. Sin embargo, cualquier lista negra tiene una
alta probabilidad de ser incompleta y es muy dependiente del sistema donde se
ejecutan los comandos. Una mejor estrategia consiste en crear una lista blanca de los
caracteres que estn permitidos en las entradas de usuario y aceptar exclusivamente
las entradas que contengan esos caracteres.
Un atacante puede controlar indirectamente los comandos ejecutados por una
aplicacin modificando el entorno en el que dichos comandos se ejecutan. No se debe
confiar en el entorno y se deben tomar precauciones para prevenir que un atacante
pueda manipular dicho entorno para realizar un ataque. Siempre que sea posible, los
comandos deben ser controlados por la aplicacin y deben ser ejecutados utilizando
una ruta absoluta. En los casos en los que la ruta no se conoce en tiempo de
compilacin (por ejemplo, aplicaciones multiplataforma), se debe construir una ruta
absoluta durante la ejecucin siempre a partir de valores confiables. Los valores y rutas
pasadas a los comandos y que procedan de ficheros de configuracin o de variables de
entorno deben ser saneados y contrastados contra una lista de valores vlidos.
Tambin se pueden realizar otras comprobaciones para detectar si la fuente de los
datos ha sido manipulada. Por ejemplo, si un fichero de configuracin es editable, el
programa puede no ejecutarse. En los casos en los que se conoce con antelacin la
informacin sobre un binario que tiene que ser ejecutado, la aplicacin debe verificar
la identidad de dicho binario.
Si un archivo binario debe pertenecer a un usuario determinado o tener una serie de
permisos asignados, la aplicacin debe comprobar estas condiciones
programticamente antes de ejecutar el binario.
Aunque puede ser imposible proteger completamente un programa de un atacante con
imaginacin y totalmente volcado en controlar los comandos que ejecuta la aplicacin,
hay que estar seguro de aplicar siempre el principio de mnimo privilegio all donde el
programa ejecute un comando procedente de fuentes externas: nunca utilice o
mantenga privilegios que no son estrictamente necesarios para la ejecucin de dicho
comando.

3.2.3 Uso indebido: Subida de archivos

Descripcin
Dejar a los usuarios que suban ficheros puede permitir a los atacantes inyectar
contenido o cdigo malicioso en el servidor.

Pgina | 18

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s


Recomendaciones
No se deben aceptar archivos adjuntos si se puede evitar. Si un programa tiene que
aceptar archivos adjuntos, debe restringir la posibilidad de que un atacante introduzca
contenido malicioso controlando que se aceptan nicamente los tipos de contenidos
especficos que el programa espera.
La mayora de los ataques que se basan en contenidos subidos requieren que el
atacante pueda proporcionar contenido de su eleccin. Estableciendo restricciones en
el contenido que el programa acepta, se limita en gran medida el abanico de posibles
ataques. Revise los nombres de archivos, extensiones, y los contenidos para asegurarse
que son los esperados y son aceptables para ser usados por la aplicacin.
Haga que resulte difcil para el atacante determinar el nombre y localizacin de los
archivos subidos. Estas soluciones son, a menudo, especficas de cada programa y
varan desde almacenar los archivos subidos en un directorio con un nombre generado
a partir de un valor aleatorio cuando el programa se inicializa, a asignar a cada archivo
subido un nombre aleatorio y que se guarde como entrada en una base de datos.

3.3 Gestin de logs

3.3.1 Falsificacin de log

Descripcin
Si escribe entradas de usuario no validadas en los archivos de log, puede permitir a un
atacante falsificar las entradas del log o inyectar contenido malicioso en el mismo.

Recomendaciones
Prevenir los ataques de falsificacin del log con indireccin: crear un conjunto de
entradas de log legtimas que correspondan con diferentes eventos que deban ser
registrados y slo registrar entradas de este conjunto. Para capturar el contenido
dinmico, como la salida de usuarios del sistema, siempre se deben utilizar valores
controlados por el servidor en lugar de valores o datos proporcionados por el usuario.
De esta forma, se asegura que las entradas que proporciona el usuario nunca sern
directamente registradas en el log.
En algunas situaciones este enfoque es impracticable, ya que el conjunto de entradas
de log legtimas es demasiado grande o complejo. En estas situaciones, los
desarrolladores suelen recurrir a listas negras. Las listas negras rechazan o evitan de
forma selectiva caracteres potencialmente peligrosos antes de utilizar la entrada. Sin
embargo, una lista de caracteres no seguros puede llegar a estar rpidamente
incompleta o desactualizada. Un mejor enfoque es crear una lista blanca de caracteres
que pueden aparecer en las entradas de log y aceptar exclusivamente caracteres del
conjunto aprobado. El carcter ms crtico en la mayora de los ataques de falsificacin
del log es el carcter '\ n' (salto de lnea), que nunca debe aparecer en una lista blanca
de entradas de log.
Muchas operaciones de registro de log se crean slo con el propsito de depurar un
programa durante las fases de desarrollo y pruebas. Basndose en la experiencia, la

Pgina | 19

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

depuracin se activar de forma accidental o a propsito en la fase de produccin en
algn momento, por lo que no puede servir de excusa el hecho de prevenir este tipo de
ataques porque un programador piense No tengo planes de activar este log en
produccin.

3.3.2 Usos indebidos

Descripcin
En el desarrollo de la funcin de logging suelen llevarse a cabo malas prcticas que
pueden derivar en vulnerabilidades de seguridad en la aplicacin. Entre ellas, destacan
las siguientes:
No declarar logger como static final. El siguiente cdigo declara
incorrectamente el objeto logger como non-static.

private final Logger logger =
Logger.getLogger(MyClass.class);


Utilizar mltiples loggers en una nica clase en vez de distintos
niveles de logging. En el siguiente ejemplo puede verse como, en la clase
MyClass se declaran tres objetos de logger:
public class MyClass {
private final static Logger good =
Logger.getLogger(MyClass.class);
private final static Logger bad =
Logger.getLogger(MyClass.class);
private final static Logger ugly =
Logger.getLogger(MyClass.class);
...
}

Utilizar System.out o System.err en vez de un log dedicado. El uso de
estas funciones dificulta la monitorizacin del comportamiento de la
aplicacin. En el siguiente cdigo de ejemplo se ve cmo se utiliza de forma
incorrecta System.out:
public class MyClass
public static void main(String[] args) {
System.out.println("hello world");
}
}

Mientras la mayora de programadores adquieren conocimientos avanzados en
distintos enfoques del lenguaje Java, un nmero sorprendente contina escribiendo
mensajes en la salida estndar utilizando System.out.println().
El problema se produce porque la escritura directa en la salida estndar se utiliza la
mayora de las veces como una forma no estructurada de logging. Las funciones de

Pgina | 20

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

logging estructurado proporcionan caractersticas como niveles de logging, formato
uniforme, timestamps, y quiz lo ms crtico, la habilidad de registrar mensajes en el
sitio adecuado. Cuando el uso de flujos de salida estndar del sistema se mezcla con el
cdigo utilizado por logger, el resultado suele ser un log en el que se pierde
informacin crtica. Adems, la utilizacin de la salida estndar del sistema puede
causar que los mensajes registrados sean devueltos accidentalmente a los usuarios
finales, revelando informacin interna a los atacantes.
La mayora de los desarrolladores aceptan la necesidad del uso de un registro (logging)
estructurado, pero muchos continan utilizando la salida estndar en el desarrollo en
preproduccin. Si el cdigo que se est revisando ha pasado las fases iniciales del
desarrollo, el uso de System.out o System.err podra indicar un descuido en el cambio a
un sistema estructurado de logging.

Recomendaciones
Es una buena prctica compartir un nico objeto de tipo logger entre
todas las instancias de una clase concreta y utilizar el mismo objeto logger
en toda la duracin del programa. Por ello, se recomienda declarar dicho
objeto como static final.
Se debe evitar el uso de la salida estndar del sistema a favor de un
registro estructurado para facilitar el seguimiento del comportamiento de
la aplicacin y evitar posibles fugas de informacin del sistema a usuarios
potencialmente maliciosos.

3.4 Configuracin

3.4.1 Contraseas en ficheros de documentacin

Descripcin
Almacenar una contrasea en texto plano en un fichero de configuracin tiene como
consecuencia que cualquier usuario que tenga permisos de lectura sobre el fichero
tenga acceso al recurso protegido por dicha contrasea. A veces los programadores
creen que no hay forma de defender la aplicacin de alguien que tiene acceso al
fichero de configuracin; sin embargo, esta actitud lo nico que consigue es hacer ms
fcil el trabajo de un atacante. Las buenas prcticas de gestin de contraseas
dictaminan que una contrasea NUNCA debe ser almacenada en texto plano.

Recomendaciones
Una contrasea nunca debe ser almacenada en texto plano. En vez de eso, la
contrasea debe ser introducida por un administrador en el momento de arrancar la
aplicacin o el sistema. Si esta estrategia no es viable, una alternativa ms flexible pero
menos segura es cifrar u ofuscar la contrasea y desperdigar la clave de encriptacin a
lo largo del sistema.
De esta forma, un atacante tendr que obtener y combinar correctamente mltiples
elementos para descifrar la contrasea. Algunos productos hacen gala de gestionar las
contraseas de una forma ms segura; por ejemplo, un servidor de aplicaciones

Pgina | 21

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

comercial utiliza un simple XOR para ofuscar las contraseas; sea escptico respecto a
este tipo de tcnicas. Este y otros productos utilizan mecanismos de encriptacin
dbiles o desfasados que son insuficientes para contextos en los que la seguridad es
crtica. Para una solucin segura, la nica opcin viable es una propietaria.

3.4.2 Esquemas XML dbiles

Descripcin
Dejar un valor maxOccurs sin lmite puede conducir a un agotamiento de recursos y, en
ltima instancia, a una denegacin del servicio.
Procesar documentos XML puede resultar costoso en cuanto a consumo de recursos.
Los atacantes pueden beneficiarse de esquemas que permiten elementos que no
tienen ningn tipo de lmite. De esta forma, pueden proporcionar a la aplicacin un
gran nmero de elementos provocando, as, que la aplicacin agote los recursos del
sistema.
El siguiente es un ejemplo de esquema que permite un nmero ilimitado de elementos
bar.
<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema>
<xs:element name=foo>
<xs:complexType>
<xs:sequence>
<xs:element name=bar maxOccurs=unbounded/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

Recomendaciones
Se recomienda limitar maxOccurs a un nmero razonable.
El siguiente es un ejemplo de esquema que permite un nmero limitado de 50
elementos bar.

<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema>
<xs:element name=foo>
<xs:complexType>
<xs:sequence>
<xs:element name=bar maxOccurs=50/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>




Pgina | 22

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s



3.5 Generacin de contenido Web

3.5.1 Cross-Site Scripting (XSS)

Descripcin
Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:
La aplicacin web recibe datos que proceden de una fuente no
confiable. En el caso de XSS persistente (tambin conocido como XSS
almacenado), la fuente no confiable es tpicamente una base de datos u
otro repositorio similar, mientras que en el caso de XSS reflejado la fuente
no confiable suele ser la peticin HTTP.
Los datos son incluidos en el contenido dinmico que se devuelve al
navegador del usuario sin haber comprobado que no contienen cdigo
malicioso.
El posible contenido malicioso que puede ser enviado al navegador del usuario
generalmente toma la forma de un bloque de cdigo JavaScript, aunque tambin
puede incluir HTML, Flash o cualquier otro tipo de cdigo que pueda ser ejecutado por
el navegador. La variedad de ataques XSS es amplsima, pero comnmente incluyen la
transmisin de datos privados como cookies u otra informacin de sesin hacia el
atacante, la redireccin de la vctima hacia contenido web controlado por el atacante, o
la ejecucin de otras acciones maliciosas en la mquina del usuario cuando accede a
un sitio vulnerable.
Ejemplo 1:
El siguiente cdigo JSP lee un identificador de empleado (eid) desde la peticin HTTP y
se lo muestra al usuario:
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

El cdigo de este ejemplo funciona como es debido si el eid contiene nicamente
caracteres alfanumricos estndar. Si el valor del parmetro eid contiene meta-
caracteres o cdigo fuente, entonces el cdigo ser ejecutado por el navegador del
usuario al mostrar el contenido de la respuesta HTTP.
Inicialmente, esto puede no parecer una vulnerabilidad. Despus de todo por qu va a
querer alguien introducir una URL que provoque la ejecucin de cdigo malicioso en su
propia mquina? El verdadero peligro est en que el atacante puede crear la URL
maliciosa y despus, a travs de correos electrnicos o ingeniera social, embaucar a
las vctimas para que visiten un enlace a dicha URL. Cuando las vctimas pulsan el
enlace, sin querer estn reflejando el contenido malicioso a travs de la aplicacin web
vulnerable a sus propias mquinas. Este mecanismo para explotar aplicaciones web
vulnerables se conoce como XSS Reflejado.
Ejemplo 2:

Pgina | 23

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

El siguiente cdigo JSP consulta una base de datos para obtener un empleado a partir
de un identificador y mostrar el nombre del empleado.
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(
"select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
%>
Employee Name: <%= name %>


Como en el caso del ejemplo 1, este cdigo funciona como es debido cuando los
valores de name son adecuados, pero no se hace nada para prevenir exploits en el
caso de que no lo sean. De nuevo, este cdigo puede parecer poco peligroso porque el
valor de name se lee de la base de datos cuyos contenidos estn aparentemente
controlados por la aplicacin.
Sin embargo, si el valor de name se construye a partir de datos introducidos por el
usuario, entonces la base de datos puede convertirse en un canal de contenido
malicioso. Sin una validacin adecuada de todos los datos contenidos en la base de
datos, un atacante puede llegar a ejecutar cdigo malicioso en el navegador del usuario
que usa la aplicacin web.
Este tipo de exploit, conocido como XSS Persistente (o almacenado) es particularmente
insidioso, ya que el nivel de indireccin introducido por el repositorio de datos hace
ms complicado identificar la amenaza e incrementa la probabilidad de que el ataque
afecte a
mltiples usuarios. Esta forma de XSS tuvo sus comienzos con los sitios web que
ofrecan libros de visitas a los usuarios. Los atacantes pueden introducir cdigo
JavaScript en una entrada del libro de visitas con lo que todos los usuarios que visiten
el libro posteriormente, ejecutarn el cdigo malicioso.
Como demuestran los ejemplos anteriores, las vulnerabilidades XSS son provocadas
por cdigo que incluye datos no validados en una respuesta HTTP. Existen tres vectores
a travs de los cuales un ataque XSS puede alcanzar a una vctima:
Como en el ejemplo 1, datos que se leen directamente de la peticin
HTTP y son reflejados de nuevo en la respuesta HTTP. Los exploits de
vulnerabilidades XSS Reflejado se dan cuando un atacante provoca que un
usuario proporcione contenido malicioso a una aplicacin web vulnerable,
que es de nuevo reflejado hacia el usuario y ejecutado en su navegador. El
mecanismo ms comn para distribuir contenido malicioso es incluirlo
como parmetro en una URL que es publicada o enviada por correo
electrnico a las vctimas. Las URLs construidas de esta forma constituyen
la base de muchos esquemas de phising, en los que el atacante convence a
la vctima para visitar una URL que apunta a un sitio web vulnerable.
Despus de que el sitio web refleja el contenido malicioso hacia el

Pgina | 24

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

navegador del usuario, dicho contenido es ejecutado y puede, por ejemplo,
transferir datos privados como cookies que pueden contener informacin
de sesin desde la mquina de la vctima a la del atacante, o realizar otras
acciones maliciosas.
Como en el ejemplo 2, la aplicacin almacena datos peligrosos en una
base de datos o cualquier otro repositorio en el que se confa. Estos datos
peligrosos son posteriormente ledos de nuevo por la aplicacin e incluidos
en el contenido dinmico. Los exploits de las vulnerabilidades de tipo XSS
Persistente ocurren cuando un atacante es capaz de incluir contenido
malicioso en un repositorio de datos y despus este contenido es incluido
en contenido dinmico devuelto al navegador de la vctima. Desde el punto
de vista del atacante, el lugar ptimo para insertar contenido malicioso es
un rea que sea mostrada a muchos usuarios o a usuarios particularmente
interesantes. Los usuarios interesantes normalmente tienen privilegios
elevados en la aplicacin o interactan con datos sensibles que pueden ser
valiosos para el atacante. Si uno de estos usuarios ejecuta cdigo malicioso,
el atacante puede ser capaz de ejecutar una operacin privilegiada en
nombre del usuario o conseguir acceder a datos sensibles que pertenecen
al usuario.
Una fuente externa a la aplicacin almacena datos peligrosos en una
base de datos u otro repositorio; estos datos son posteriormente ledos por
la aplicacin como datos confiables e incluidos en contenido dinmico.

Recomendaciones
La solucin a las vulnerabilidades XSS consiste en asegurarse de que se realizan
validaciones en los puntos adecuados y que se comprueban las propiedades correctas.
Dado que las vulnerabilidades XSS se dan cuando una aplicacin incluye datos
maliciosos en la salida que genera, un enfoque habitual es validar los datos justo antes
de que abandonen la aplicacin. Sin embargo, puesto que las aplicaciones web generan
contenido dinmico a travs de cdigo de cierta complejidad este enfoque es propenso
a omitir ciertas validaciones. Una forma efectiva de mitigar este riesgo es realizar
tambin validaciones sobre los datos de entrada a la aplicacin.
Las aplicaciones web deben validar sus entradas para prevenir otro tipo de
vulnerabilidades, como las vulnerabilidades de inyeccin SQL, por lo que ampliar estos
mecanismos de validacin para incluir comprobaciones relativas a XSS es relativamente
fcil. A pesar de su valor, la validacin de datos de entrada no sustituye una validacin
rigurosa de los datos de salida. Una aplicacin puede aceptar datos a travs de un
repositorio de datos compartido u otra fuente confiable; sin embargo, esta fuente de
datos puede aceptar datos de entrada de otra fuente que no realiza una validacin
adecuada de los datos introducidos. Como consecuencia, la aplicacin no puede
confiar implcitamente en la seguridad de estos datos.
Esto significa que la mejor forma de prevenir las vulnerabilidades XSS es validar todo lo
que entre a la aplicacin y todo lo que salga de la aplicacin con destino al usuario.
La estrategia ms segura para incluir validaciones XSS es crear una lista blanca de
caracteres que estn permitidos que aparezcan en el contenido HTTP, y por lo tanto,

Pgina | 25

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

aceptar nicamente las entradas formadas por caracteres que se encuentran en dicha
lista.
Por ejemplo, un nombre de usuario debe estar formado nicamente por caracteres
alfanumricos, un nmero de telfono debe incluir slo los dgitos 0-9. Sin embargo,
este enfoque puede ser inviable en muchas aplicaciones web ya que muchos caracteres
que tienen un significado especial para el navegador deben ser considerados como
entradas vlidas una vez que son codificados, como por ejemplo, aplicaciones web en
las que se permite al usuario introducir cdigo HTML.
Un enfoque ms flexible, pero tambin menos seguro, es utilizar listas negras que
permitan rechazar de forma selectiva o aplicar secuencias de escape sobre caracteres
potencialmente peligrosos antes de aceptar una entrada. Para poder construir este tipo
de listas, primero es necesario conocer qu caracteres tienen un significado especial
para los navegadores. Aunque el estndar HTML define qu caracteres tienen un
significado especial para un navegador, muchos navegadores tratan de corregir
determinados problemas o limitaciones de HTML tratando determinados caracteres
como especiales en determinados contextos. El CERT Coordination Center del Software
Engineering Institute (ESI) de la Universidad Carnegie Mellon proporciona la siguiente
informacin sobre caracteres especiales en determinados contextos:
En el contexto de un elemento de nivel de bloque (en el medio de un
prrafo de texto):
"<" es especial porque comienza un tag.
"&" es especial porque introduce una entidad de carcter (character
entity).
">" es especial porque algunos navegadores lo tratan como tal,
asumiendo que el autor de la pgina pretenda incluir un carcter de
apertura de tag <, pero fue omitido por error.
Los siguientes principios se aplican a los valores de los atributos:
Si el valor de un atributo est encerrado entre dobles comillas, las
dobles comillas son especiales porque marcan el final del valor del
atributo.
Si el valor de un atributo est encerrado entre comillas simples, las
comillas simples son especiales porque marcan el final del valor del
atributo.
En valores de atributos sin comillas, los caracteres de tipo espacio en
blanco como espacios y tabuladores, son especiales.
& es especial cuando se usa en determinados atributos, porque
introduce una entidad carcter.
En URLs, por ejemplo, un motor de bsqueda puede proporcionar un
enlace dentro de la pgina de resultados que puede ser pulsado por el
usuario para relanzar la bsqueda. Esto puede ser implementado
codificando los parmetros de la bsqueda en la propia URL, lo cual
introduce caracteres especiales adicionales:
Los caracteres espacio, tabulador y nueva lnea son especiales porque
marcan el final de la URL.
& es especial porque introduce una entidad carcter o acta como

Pgina | 26

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

separador de parmetros.
Los caracteres no ASCII (es decir, todos los que estn por encima de 128
en la codificacin ISO-8859-1) no se permiten en las URLs, por lo que
son considerados especiales en este contexto.
El smbolo % debe ser filtrado de la entrada siempre que parmetros
codificados con secuencias de escape HTTP sean decodificados por
cdigo de servidor. Por ejemplo, el carcter % debe ser filtrado de una
entrada como "%68%65%6C%6C%6F" y debe aparecer como hello en
la pgina web en cuestin.

En el cuerpo de un bloque <SCRIPT></SCRIPT>:
El punto y coma, los parntesis, las llaves y el carcter de nueva lnea
deben ser filtrados en aquellas situaciones en las que el texto pueda ser
insertado en un tag <script> que ya exista.
En scripts de servidor:
Se requiere un filtrado adicional en los scripts de servidor que
convierten cualquier carcter de exclamacin (!) existente en una
entrada a carcter de comilla doble () en una salida.
Otras posibilidades:
Si un atacante enva una peticin codificada en UTF-7, el carcter
especial < aparece como +ADw- y puede saltarse el filtrado. Si la salida
se incluye en una pgina que no especifica explcitamente una
codificacin, algunos navegadores intentarn identificar la codificacin
basndose en el contenido (en este caso, UTF-7).
Una vez que se han identificado los puntos de una aplicacin donde se deben hacer las
validaciones XSS y se tienen claros qu caracteres deben ser considerados en estas
validaciones, el siguiente paso es considerar cmo las rutinas de validacin van a
manejar estos caracteres especiales. Si los caracteres especiales no se consideran como
una entrada vlida a la aplicacin, una opcin es rechazar cualquier peticin que
contenga estos caracteres. Una segunda opcin, es eliminar los caracteres especiales
de la entrada aplicando un filtro, aunque esto tiene el inconveniente de que se cambia
la representacin visual del contenido filtrado, lo que puede ser inaceptable en los
casos en los que se requiera mantener la integridad de la entrada para ser mostrada.
Si la entrada que contiene caracteres especiales debe ser aceptada y mostrada, la
rutina de validacin debe codificar cualquier carcter especial para suprimir su
significado. La especificacin oficial de HTML proporciona una lista completa de valores
ISO-8859-1 codificados.
Muchos servidores de aplicaciones intentan limitar la exposicin de una aplicacin a
vulnerabilidades XSS proporcionando para ello implementaciones especiales de las
funciones responsables de establecer los contenidos de una respuesta HTTP; estas
funciones realizan validaciones en busca de caracteres especiales que puedan suponer
un ataque XSS. Sin embargo, no se fe del servidor de aplicaciones para hacer su
aplicacin segura; cuando se desarrolla una aplicacin, no existe una garanta absoluta
sobre qu servidores de aplicaciones va a ejecutarse. A medida que los estndares y
exploits conocidos evolucionan, no hay garanta de que los servidores de aplicaciones

Pgina | 27

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

evolucionen de la misma forma.




3.5.2 Manipulacin de cabeceras

Descripcin
Incluir datos sin validar en la cabecera de respuesta HTTP puede permitir ataques de
envenenamiento de cach, Cross-Site Scripting, Cross-User Defacement, Page
Hijacking, manipulacin de cookies u Open redirect.
Las vulnerabilidades de manipulacin de cabeceras ocurren cuando:
1. Se introducen datos a una aplicacin web a travs de una fuente no
confiable, frecuentemente en una peticin HTTP.
2. Los datos se incluyen en una cabecera de respuesta HTTP y se envan a un
usuario de la web sin validar.
Al igual que con muchas vulnerabilidades de seguridad, la manipulacin de cabeceras
es un medio para un fin, no un fin en s mismo. En su raz, la vulnerabilidad es sencilla:
un atacante pasa los datos maliciosos a una aplicacin vulnerable, y la aplicacin
incluye los datos en la cabecera de respuesta HTTP.
Uno de los ataques ms comn de la manipulacin de cabeceras es HTTP Response
Splitting. Para explotar con xito un HTTP Response Splitting, la aplicacin debe
permitir entradas que contengan caracteres CR (retorno de carro: %0d o \r) y LF (salto
de lnea: %0a o \n) en la cabecera. Estos caracteres no slo dan el control a los
atacantes de las cabeceras restantes y del cuerpo de la respuesta que la aplicacin
intenta enviar, sino que tambin les permite crear respuestas adicionales
completamente bajo su control.
Ejemplo:
El siguiente fragmento de cdigo lee el nombre del autor de una entrada en un weblog
desde una peticin HTTP y lo almacena en la cabecera de una cookie de una respuesta
HTTP.
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie(author, author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);

Supongamos que una cadena formada por caracteres alfanumricos, tales como Jane
Smith, es enviada en la peticin. La respuesta HTTP que incluya esta cookie tendra la
siguiente forma:
HTTP/1.1 200 OK
...
Set-Cookie: author = Jane Smith
...

Sin embargo, debido a que el valor de la cookie est formado por la entrada de usuario

Pgina | 28

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

sin validar, la respuesta slo mantendr esta forma si el valor enviado para
AUTHOR_PARAM no contiene caracteres CR y LF. Si un atacante enva una cadena
maliciosa, como Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..., entonces la respuesta HTTP
se dividira en dos respuestas de la siguiente forma:
HTTP/1.1 200 OK
...
Set-Cookie: author = Wiley Hacker
HTTP/1.1 200 OK
...

Es evidente que la segunda respuesta est completamente controlada por el atacante y
se puede construir con cualquier cabecera y contenido del cuerpo deseado. La
habilidad del atacante para construir arbitrariamente las respuestas HTTP permite una
variedad de ataques, incluyendo: Cross-User Defacement, envenenamiento de cach,
Cross-Site Scripting, Page Hijacking, manipulacin de cookies y Open redirect Cross-
User Defacement: Un atacante puede hacer una peticin simple a un servidor
vulnerable que obligar al servidor a crear dos respuestas, la segunda ser mal
interpretada como una respuesta a una peticin diferente, posiblemente como una
hecha por otro usuario que comparta la misma conexin TCP con el servidor. Esto se
puede hacer convenciendo al usuario para que enven ellos mismos las peticiones
maliciosas o, de forma remota, en situaciones donde el atacante y el usuario
compartan una conexin TCP comn con el servidor, como un servidor proxy
compartido. En el mejor de los casos, un atacante puede aprovechar esta capacidad
para convencer a los usuarios de que la aplicacin ha sido hackeada, consiguiendo que
los usuarios pierdan la confianza en la seguridad de la aplicacin. En el peor de los
casos, un atacante puede proporcionar contenido malicioso especialmente diseado
para imitar el comportamiento de la peticin, pero redireccionando la informacin
privada, tales como nmeros de cuenta y contraseas, al atacante.
Envenenamiento de cach: El impacto de la respuesta construida maliciosamente se
puede ampliar si se almacena en cach, ya sea en una cach web que es utilizada por
varios usuarios, o incluso en la cach del navegador de un usuario nico. Si una
respuesta se almacena en una cach web compartida, como las que se encuentran en
los servidores proxy, entonces todos los usuarios de esa cach continuarn recibiendo
contenido malicioso hasta que la entrada de la cach sea eliminada. Del mismo modo,
si la respuesta est en la cach de un navegador de un usuario individual, entonces ese
usuario continuar recibiendo el contenido malicioso hasta que la entrada de la cach
sea eliminada, aunque slo el usuario de la instancia local del navegador se ver
afectado.
Page Hijacking: Adems de usar una aplicacin vulnerable para enviar contenido
malicioso al usuario, la misma vulnerabilidad puede tambin ser aprovechada para
redirigir contenido sensible generado por el servidor al atacante, en lugar de al usuario
al que va destinado. Mediante el envo de una peticin que da lugar a dos respuestas:
la respuesta desde el servidor y la respuesta generada por el atacante, un atacante
puede hacer que un nodo intermedio, como un servidor proxy compartido, desve al
atacante una respuesta generada por el servidor para el usuario. Debido a que la
peticin formulada por el atacante genera dos respuestas, la primera es interpretada

Pgina | 29

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

como una respuesta a la peticin del atacante, mientras que la segunda permanece en
el limbo. Cuando el usuario hace una peticin legtima por medio de la misma conexin
TCP, la peticin del atacante est esperando y es interpretada como una respuesta a la
peticin de la vctima. El atacante entonces enva una segunda peticin al servidor, a la
que el servidor proxy responde con la peticin generada por el servidor y destinada a la
vctima, poniendo as en peligro la informacin sensible en las cabeceras o en el cuerpo
de la respuesta destinada a la vctima.
Manipulacin de cookies: Cuando se combina con ataques como Cross-Site Request
Forgery, los atacantes pueden modificar, aadir o sobrescribir las cookies de un usuario
legtimo.
Open Redirect: Permitir entradas sin validar para controlar la URL utilizada en una
redireccin, puede ayudar a realizar ataques de phishing.
Muchos de los servidores de aplicaciones actuales previenen la inyeccin de caracteres
maliciosos en las cabeceras HTTP. Por ejemplo, versiones recientes de Apache Tomcat
lanzan una excepcin IllegalArgumentException si se intenta configurar una cabecera
con caracteres prohibidos. Si su servidor de aplicaciones impide configurar cabeceras
con caracteres de nueva lnea, entonces su aplicacin no es vulnerable a HTTP
Response Splitting. Sin embargo, nicamente el filtrado de caracteres de nueva lnea
puede dejar una aplicacin vulnerable a la manipulacin de cookies u Open Redirects,
as que debe tenerse cuidado al configurar las cabeceras HTTP con la entrada del
usuario.

Recomendaciones
La solucin a la manipulacin de cabeceras es asegurarse de que la validacin de la
entrada se produce en los lugares adecuados y que verifica las propiedades correctas.
Dado que las vulnerabilidades de manipulacin de cabeceras ocurren cuando una
aplicacin incluye informacin maliciosa en su salida, un enfoque lgico sera validar la
informacin inmediatamente antes de abandonar la aplicacin. Sin embargo, debido a
que las aplicaciones web a menudo tienen cdigo complejo para generar las respuestas
dinmicamente, este mtodo es propenso a errores de omisin. Una forma efectiva de
mitigar este riesgo es llevar a cabo validacin de entradas para la manipulacin de las
cabeceras.
Las aplicaciones web deben validar su entrada para evitar otras vulnerabilidades, como
inyeccin SQL, as que aumentar el mecanismo de validacin de entrada existente en
una aplicacin para que incluya comprobaciones sobre la manipulacin de las
cabeceras, en general, es relativamente fcil. A pesar de su valor, la validacin de
entrada para la manipulacin de cabeceras no sustituye a una rigurosa validacin de la
salida. Una aplicacin puede aceptar la entrada a travs de un almacn de datos
compartidos o de otra fuente confiable, y ese almacn de datos puede aceptar
entradas de una fuente que no valida adecuadamente la entrada. Por lo tanto, la
aplicacin no puede confiar, de forma implcita, en la seguridad de ste ni de cualquier
otro dato. Esto significa que la mejor forma de prevenir las vulnerabilidades de la
manipulacin de cabeceras es la de validar todo lo que entra o sale de la aplicacin
destinada al usuario.
El mtodo ms seguro para la validacin de la manipulacin de cabeceras es crear una
lista blanca de caracteres seguros que puedan aparecer en la cabecera de la respuesta

Pgina | 30

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

HTTP y aceptar la entrada compuesta exclusivamente de caracteres del conjunto
aprobado. Por ejemplo, un nombre vlido slo puede incluir caracteres alfanumricos
o un nmero de cuenta slo puede incluir dgitos en el rango 0-9.
Un enfoque ms flexible, pero menos seguro, es conocido como lista negra, que
rechaza de forma selectiva o evita caracteres potencialmente peligrosos antes de usar
la entrada. Para formar dicha lista, primero es necesario entender el conjunto de
caracteres que tienen significado especial en las cabeceras de respuestas HTTP. Aunque
los caracteres CR y LF son la esencia del ataque HTTP response splitting, otros
caracteres, como : (dos puntos) y = (igual), tienen especial significado tambin en
las cabeceras de las respuestas.
Una vez identificados los puntos correctos en una aplicacin para realizar la validacin
de los ataques de la manipulacin de la cabecera y qu caracteres especiales se deben
considerar en la validacin, el siguiente paso es identificar cmo la validacin maneja
los caracteres especiales. La aplicacin debera rechazar cualquier entrada destinada a
ser incluida en las cabeceras de la respuesta HTTP que contenga caracteres especiales,
particularmente CR y LF.
Muchos servidores de aplicaciones intentan limitar la exposicin de una aplicacin a las
vulnerabilidades HTTP response splitting proporcionando implementaciones para las
funciones responsables de configurar las cabeceras HTTP y las cookies que realizan la
validacin de los caracteres esenciales en un ataque HTTP response splitting. No confe
en que el servidor donde se ejecuta la aplicacin lo hace de forma segura. Cuando una
aplicacin es desarrollada, no hay garantas sobre en qu servidores de aplicaciones se
ejecutar a lo largo de toda su vida til. Como los estndares y las vulnerabilidades
conocidas evolucionan, no hay garantas de que los servidores de aplicaciones tambin
estn sincronizados.

3.5.3 Cross-Site Request Forgery

Descripcin
Los formularios enviados a una aplicacin web deben contener un secreto especfico
del usuario para prevenir que un atacante pueda realizar peticiones no autorizadas.
Una vulnerabilidad de tipo Cross-Site Request Forgery (CSRF) se da cuando:
1. Una aplicacin web utiliza cookies de sesin.
2. La aplicacin procesa una peticin HTTP sin verificar que sta fue hecha con el
consentimiento del usuario.
Si una peticin no contiene un nonce (valor de seguridad) que pruebe su procedencia,
el cdigo que gestiona la peticin es vulnerable a un ataque CSRF (a menos que la
peticin no cambie el estado de la aplicacin). Esto significa que una aplicacin web
que utilice cookies de sesin tiene que tomar precauciones especiales para evitar que
un atacante engae a los usuarios para realizar peticiones falsas.
Imagine una aplicacin web alojada en un dominio example.com que permite a los
administradores crear cuentas de usuario por medio del envo del siguiente formulario:
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password"
name="user_passwd">

Pgina | 31

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

<input type="submit" name="action" value="Create User">
</form>

Un atacante puede crear un sitio web con una pgina que contenga el siguiente cdigo:
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>

Si un administrador de example.com visita la pgina maliciosa mientras tiene una
sesin activa, estar creando una cuenta para el atacante si darse cuenta. Esto es un
ataque Cross-Site Request Forgery. Esto es posible porque la aplicacin no tiene forma
de determinar la procedencia de la peticin. Cualquier peticin puede ser una accin
procedente de un usuario legtimo o una accin maliciosa procedente de un atacante.
El atacante no puede ver la pgina que genera la peticin maliciosa, por lo que esta
tcnica de ataque slo tiene sentido para peticiones que modifican el estado de la
aplicacin.

Recomendaciones
Por lo tanto, para evitar las vulnerabilidades CSRF, las aplicaciones que usan cookies de
sesin deben incluir algn elemento distintivo en cada peticin para permitir al cdigo
de servidor validar la procedencia de la peticin. Una forma de implementar esto es
incluyendo identificadores de peticin aleatorios en los formularios.
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password"
name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<input type="hidden" name="req_id" value="87ae34d92ba7a1">

De esta forma, el cdigo de servidor puede validar el identificador de la peticin antes
de proceder con el procesamiento del resto de los datos. El identificador de peticin
puede ser nico para cada nuevo formulario o puede ser compartido por todos los
formularios para una sesin en particular. Al igual que ocurre con los identificadores de
sesin, cuanto ms difcil sea para un atacante averiguar el identificador de peticin,
ms difcil ser para l realizar con xito un ataque CSRF.
Por otro lado, la mayora de los navegadores web envan una cabecera HTTP llamada
referer con cada peticin. Se supone que esta cabecera contiene la URL de la pgina
que ha generado la peticin, pero un atacante puede fcilmente falsificar esta
informacin, por lo que la cabecera referer no es til para determinar la procedencia
de la peticin.
Las aplicaciones que pasan el identificador de sesin en la URL en vez de usar una

Pgina | 32

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

cookie, no son vulnerables a CSRF ya que no hay forma de que el atacante acceda a la
informacin de sesin y la incluya en una peticin.



3.6 Criptografa
3.6.1 Encriptacin dbil

Descripcin
El programa utiliza un algoritmo de encriptacin dbil que no puede garantizar la
confidencialidad de datos sensibles.
Algoritmos anticuados de encriptacin, como DES, ya no proporcionan suficiente
proteccin para ser usados con datos sensibles. Los algoritmos de encriptacin se
basan en el tamao de la clave como uno de los mecanismos principales para asegurar
la fortaleza criptogrfica.
La fortaleza criptogrfica se mide, a menudo, por el tiempo y potencia de clculo
necesarios para general una clave vlida. Los avances en potencia de clculo han hecho
que sea posible obtener claves de encriptacin pequeas en una cantidad de tiempo
razonable. Por ejemplo, las claves de 56-bit utilizadas en el algoritmo DES supusieron
un obstculo significativo para el clculo en los aos 70, cuando se desarroll el
algoritmo por primera vez, pero hoy DES puede ser descifrado en menos de un da
utilizando equipos disponibles comnmente.

Recomendaciones
Se recomienda utilizar algoritmos de encriptacin fuerte con claves de gran tamao
para proteger datos sensibles. Ejemplos de alternativas fuertes a DES son Rijndael
(Advanced Encryption Standard o AES) y Triple DES (3DES). Antes de seleccionar un
algoritmo, primero se debera determinar si la organizacin sigue algn estndar en
cuanto a algoritmos especficos y su implementacin.
En esta auditora se ha reportado una vulnerabilidad alta de seguridad al utilizar
algoritmos RC4 o DES y una vulnerabilidad baja al utilizar un algoritmo RC2.



3.7 Control de acceso
3.7.1 Fijacin de sesin

Descripcin
Las vulnerabilidades de fijacin de sesin se producen cuando:
1. Una aplicacin web autentica a un usuario sin validar previamente la sesin
existente, dando as continuidad a la utilizacin de la sesin asociada ya con el
usuario.

2. Un atacante es capaz de forzar un identificador de sesin conocido de un
usuario de forma que una vez que el usuario se autentica, el atacante tenga

Pgina | 33

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

acceso a la sesin autenticada.
En la imagen que se encuentra a continuacin, puede verse el proceso general de
ataque seguido para explotar este tipo de vulnerabilidades.
(1) El atacante puede establecer una conexin legtima con el servidor web, el cual (2)
establece un identificador de sesin, o bien crear una nueva sesin con el identificador
de sesin propuesto. Despus (3) el atacante enva un enlace a la vctima con el
identificador de la sesin establecida al que la vctima accede (4), el servidor Web
observa que la sesin ya estaba establecida y no necesita crear una nueva, (5) la
vctima proporciona sus credenciales al servidor, y por ltimo el atacante, que conoce
el identificador de sesin accede a la cuenta de la vctima.

Recomendaciones
Para prevenir la fijacin de sesin, una aplicacin web debe emitir un nuevo
identificador de sesin, al mismo tiempo que autentica a un usuario. Muchos
servidores de aplicacin dificultan esta tarea proporcionando funcionalidades
independientes de gestin de la autorizacin y de gestin de sesin. Por ejemplo, una
aplicacin que fija directamente en el post datos de autenticacin a la URL
j_security_check del contenedor de Servlet deTomcat provocar que el servidor realice
la autenticacin sin emitir un nuevo identificador de sesin.
Se recomienda implementar cdigo propio que realice la autenticacin asegurando que
se invalida la sesin existente antes de procesar las peticiones de login. Cualquier
informacin del usuario almacenada en la sesin puede ser migrada a la nueva sesin
de manera segura, siempre y cuando el identificador de sesin asociado cambie.


Pgina | 34

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s




3.8 Diseo
3.8.1 Condicin de carrera: Variable miembro Singleton

Descripcin
Las variables miembro de un servlet pueden permitir que un usuario vea los datos de
otro usuario.
Muchos programadores de servlets no entienden que, a menos que un servlet
implemente la interface SingleThreadModel, el servlet es un Singleton. Es decir, existe
una nica instancia del servlet, y esa instancia es reutilizada para gestionar mltiples
peticiones que son procesadas simultneamente por distintos hilos de ejecucin.
Un resultado comn de este desconocimiento, es que los desarrolladores usan las
variables miembro de un servlet de tal forma que un usuario puede ver los datos de
otro usuario. En otras palabras, almacenar datos de usuario en las variables miembro
de un servlet produce una condicin de carrera.
Ejemplo 1:
El siguiente servlet almacena el valor de un parmetro procedente de la peticin HTTP
en una variable miembro y, posteriormente, incluye ese valor en la respuesta.
public class GuestBook extends HttpServlet {
String name;
protected void doPost (HttpServletRequest req,
HttpServletResponse res) {
name = req.getParameter("name");
...
out.println(name + ", thanks for visiting!");
}
}



Este cdigo funciona perfectamente en un entorno con un nico usuario. Sin embargo,
si dos usuarios acceden al servlet prcticamente en el mismo instante, es posible que
los dos hilos de ejecucin que estn procesando las peticiones se entremezclen de la
siguiente forma:
Hilo 1: asigna "Dick" a la variable name.
Hilo 2: asigna "Jane" a la variable name.
Hilo 1: muestra Jane, thanks for visiting!"
Hilo 2: muestra Jane, thanks for visiting!"
Con lo que se muestra al primer usuario el mensaje conteniendo el nombre del
segundo usuario.

Recomendaciones
No utilice las variables miembro de un servlet para otra cosa que no sean constantes

Pgina | 35

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

(por ejemplo, hacer todas las variables miembro static final).
Los programadores tienden a utilizar las variables miembro de un servlet para contener
datos de usuario cuando necesitan trasladar datos desde una regin del cdigo a otra.
Si ste es el propsito, considere utilizar una clase separada y utilice el servlet
nicamente para envolver dicha clase.
Ejemplo 2:
El defecto en el ejemplo anterior puede ser corregido de la siguiente forma:

public class GuestBook extends HttpServlet {
protected void doPost (HttpServletRequest req,
HttpServletResponse res) {
GBRequestHandler handler = new GBRequestHandler();
handler.handle(req, res);
}
}
public class GBRequestHandler {
String name;
public void handle(HttpServletRequest req,
HttpServletResponse res) {
name = req.getParameter("name");
...
out.println(name + ", thanks for visiting!");
}
}

Alternativamente un servlet puede implementar la interface SingleThreadModel, lo
que hace que el contenedor de servlets mantenga un pool de objetos servlet los cuales
va utilizando para gestionar las peticiones entrantes. Dependiendo de cmo est
implementado el contenedor de servlets y de las necesidades de la aplicacin, el uso
de SingleThreadModel puede causar problemas de rendimiento.


3.8.2 Almacenar objetos no serializables en sesin

Descripcin
El almacenamiento de un objeto no serializable como un atributo de HttpSession
puede daar la fiabilidad de la aplicacin.
Ejemplo:
La siguiente clase se aade a la sesin, pero al no ser serializable, dicha sesin no
podr ser replicada:
public class DataGlob {
String globName;
String globValue;
public void addToSession(HttpSession session) {
session.setAttribute("glob", this);

Pgina | 36

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

}
}

Recomendaciones
Una aplicacin J2EE puede hacer uso de mltiples mquinas virtuales de java con el fin
de mejorar la fiabilidad y el rendimiento de la aplicacin. Para conseguir que las
distintas mquinas virtuales de java aparezcan como una sola aplicacin de cara al
usuario, el contenedor J2EE puede replicar un objeto HttpSession a travs de las
mltiples mquinas virtuales de forma que si una de las mquinas llega a estar no
disponible, otra puede sustituirla sin interrumpir el flujo de la aplicacin.
Los valores que la aplicacin almacena como atributos en la sesin deben implementar
el interfaz Serializable para poder trabajar con la sesin replicada.


3.9 Gestin de recursos
3.9.1 Recurso no liberado

Descripcin
La aplicacin puede no liberar un recurso del sistema. Las causas habituales de las
fugas de recursos son las siguientes:
Condiciones de error y otras circunstancias excepcionales.
Confusin acerca de qu parte del programa es responsable de
liberar un recurso.
La mayor parte de las incidencias relacionadas con recursos no liberados originan
problemas de fiabilidad en la aplicacin, pero si un atacante puede provocar
intencionadamente una fuga de recursos, podra llegar a realizar un ataque de
denegacin de servicio al agotar el pool de recursos.
Los tipos de recursos que el sistema puede no liberar son los siguientes:
Flujos
Bases de datos
Sockets
Ficheros
A continuacin se detallan ejemplos de cdigo en los que se podra producir una fuga
de recursos. Dichos ejemplos se encuentran divididos en funcin del tipo de recurso al
que afectan:
FLUJOS:
El siguiente mtodo nunca cierra el handle a fichero que abre
inicialmente. El mtodo finalize() de FileInputStream eventualmente llama
al mtodo close(), pero no existe garanta de cunto tiempo pasar antes
de que se llame a finalize(). En un entorno con carga elevada, puede darse
el caso de que la mquina virtual de Java llegue a agotar los handles a
fichero.

private void processFile(String fName) throws

Pgina | 37

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

FileNotFoundException, IOException
{
FileInputStream fis = new FileInputStream(fName);
int sz;
byte[] byteArray = new byte[BLOCK_SIZE];
while ((sz = fis.read(byteArray)) != -1) {
processBytes(byteArray, sz);
}
}

BASES DE DATOS:
En condiciones normales, el cdigo siguiente ejecuta una consulta contra la base de
datos, procesa los resultados devueltos y cierra el objeto Statement utilizado. Sin
embargo, si se produce una excepcin mientras se ejecuta la sentencia SQL o se
procesan los resultados, el objeto Statement no se cerrar nunca. Si esto se produce
con mucha frecuencia, la base de datos se quedar sin cursores que utilizar y no podr
ejecutar ms sentencias SQL.
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(CXN_SQL);
harvestResults(rs);
stmt.close();

SOCKETS:
El siguiente mtodo nunca cierra el socket que abre. En un entorno donde se
produzcan muchas peticiones esto puede derivar en el agotamiento de todos los
sockets.
private void echoSocket(String host, int port) throws
UnknownHostException, SocketException, IOException
{
Socket sock = new Socket(host, port);
BufferedReader reader = new BufferedReader(new
InputStreamReader(sock.getInputStream()));
while ((String socketData = reader.readLine()) != null) {
System.out.println(socketData);
}
}

En condiciones normales, el siguiente cdigo cerrar el socket y cualquier flujo
asociado. Pero si ocurre una excepcin mientras se est leyendo la entrada o
escribiendo datos en pantalla el socket no ser cerrado. Si esto ocurre con suficiente
frecuencia, el sistema se quedar sin sockets y no ser capaz de manejar nuevas
conexiones.
private void echoSocket(String host, int port) throws
UnknownHostException, SocketException, IOException

Pgina | 38

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

{
Socket sock = new Socket(host, port);
BufferedReader reader = new BufferedReader(new
InputStreamReader(sock.getInputStream()));
while ((String socketData = reader.readLine()) != null) {
System.out.println(socketData);
}
sock.close();
}

FICHEROS:
El siguiente mtodo nunca cierra el descriptor de fichero que abre. El mtodo
finalize() del objeto ZipFile finalmente llamar al mtodo close() pero no hay
garantas de cunto tiempo pasar antes de que el mtodo finalize() sea invocado. En
un entorno donde se produzcan muchas peticiones esto puede derivar en el
agotamiento de todos los descriptores de fichero.
public void printZipContents(String fName)
throws ZipException, IOException, SecurityException,
IllegalStateException, NoSuchElementException
{
ZipFile zf = new ZipFile(fName);
Enumeration<ZipEntry> e = zf.entries();
while (e.hasMoreElements()) {
printFileInfo(e.nextElement());
}
}

En condiciones normales, el cdigo siguiente cierra el handle de fichero despus de
imprimir todas las entradas del fichero zip. Sin embargo, si se produce una excepcin
durante las iteraciones, el handle de fichero no ser cerrado. Si esto se produce con
mucha frecuencia, la mquina virtual de java se quedar sin handles de archivo
disponibles.
public void printZipContents(String fName)
throws ZipException, IOException, SecurityException,
IllegalStateException, NoSuchElementException {
ZipFile zf = new ZipFile(fName);
Enumeration<ZipEntry> e = zf.entries();
while (e.hasMoreElements()) {
printFileInfo(e.nextElement());
}
}

Recomendaciones
Nunca confe en el mtodo finalize() para liberar recursos. Para que se invoque el

Pgina | 39

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

mtodo finalize() de un objeto, primero el recolector de basura (garbage collector)
debe determinar que dicho objeto puede ser reciclado. Puesto que el recolector de
basura slo se ejecuta cuando la mquina virtual de Java tiene poca memoria libre, no
hay garanta de que el mtodo finalize() sea invocado de manera oportuna. Una vez
que el recolector de basura se ejecuta, una gran cantidad de recursos son liberados en
un periodo corto de tiempo lo que puede provocar una disminucin temporal del
rendimiento global de la aplicacin. Este efecto es ms pronunciado cuanto mayor sea
la carga del sistema.
Por otro lado, si es posible que una operacin de liberacin de recursos quede colgada
(por ejemplo, si la finalizacin requiere comunicarse a travs de la red con una base de
datos), entonces el hilo que ejecuta el mtodo finalize() quedar tambin colgado. Se
recomienda liberar los recursos en un bloque finally. A continuacin se detallan varios
ejemplos divididos en funcin del tipo de recurso al que afectan. En cada uno de ellos,
se indica cmo debe llevarse a cabo la implementacin para garantizar que no se
produzca una fuga de recursos.

FLUJOS
private void processFile(String fName) throws
FileNotFoundException, IOException
{
FileInputStream fis;
int sz;
try {
fis = new FileInputStream(fName);
byte[] byteArray = new byte[BLOCK_SIZE];
while ((sz = fis.read(byteArray)) != -1) {
processBytes(byteArray, sz);
}
}
finally {
if (fis != null){
safeClose(fis);
}
}
}
public static void safeClose(FileInputStream f) {
if (f != null && !f.isClosed()) {
try {
f.close();
} catch (IOException e) {
log(e);
}
}
}


Pgina | 40

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

Esta solucin utiliza una funcin auxiliar para registrar las excepciones que pueden
originarse cuando se trata de cerrar el objeto FileInputStream. Esta funcin auxiliar
puede ser reutilizada siempre que se quiere cerrar un objeto FileInputStream de forma
segura.
Como puede verse, el mtodo processFile no inicializa el objeto fis a null. En vez de
ello, comprueba si el objeto fis no es null antes de llamar a safeClose(). Sin esta
comprobacin, el compilador de Java informa de que la variable fis puede no estar
inicializada. Esta opcin se aprovecha de la capacidad de Java para detectar variables
no inicializadas. Si la variable fis es inicializada a null en un mtodo ms complejo, los
casos en los en los que fis es usada sin ser inicializada no sern detectados por el
compilador.

BASE DE DATOS
public void execCxnSql(Connection conn) {
Statement stmt;
try {
stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(CXN_SQL);
...
}
finally {
if (stmt != null) {
safeClose(stmt);
}
}
}
public static void safeClose(Statement stmt) {
if (stmt != null) {
try {
stmt.close();
} catch (SQLException e) {
log(e);
}
}
}

Esta solucin utiliza una funcin auxiliar para registrar las excepciones que pueden
originarse cuando se trata de cerrar el objeto Statement. Esta funcin auxiliar puede
ser reutilizada siempre que se quiere cerrar un objeto Statement de forma segura.
Tambin hay que notar que el mtodo execCxnSql no inicializa el objeto stmt a null. En
vez de ello, comprueba si el objeto stmt no es null antes de llamar a safeClose(). Sin
esta comprobacin, el compilador de Java informa de que la variable stmt puede no
estar inicializada. Esta opcin se aprovecha de la capacidad de Java para detectar
variables no inicializadas. Si la variable stmt es inicializada a null en un mtodo ms
complejo, los casos en los que stmt se utiliza sin ser inicializada no sern detectados

Pgina | 41

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

por el compilador.
Sea consciente de que cerrar una conexin a una base de datos puede o no liberar
automticamente otros recursos asociados con esa conexin. Si la aplicacin utiliza un
pool de conexiones, es mejor liberar explcitamente los otros recursos despus de que
la conexin sea cerrada. Si la aplicacin no utiliza pool de conexiones, los otros
recursos asociados son liberados automticamente cuando se cierra la conexin a la
base de datos.
En este caso, esta vulnerabilidad no es vlida.

SOCKETS
private void echoSocket(String host, int port) throws
UnknownHostException, SocketException, IOException
{
Socket sock;
BufferedReader reader;
try {
sock = new Socket(host, port);
reader = new BufferedReader(new
InputStreamReader(sock.getInputStream()));
while ((String socketData = reader.readLine()) != null) {
System.out.println(socketData);
}
}
finally {
safeClose(sock);
}
}
public static void safeClose(Socket s) {
if (s != null && !s.isClosed()) {
try {
s.close();
} catch (IOException e) {
log(e);
}
}
}

Esta solucin utiliza una funcin auxiliar para registrar las excepciones que pueden
originarse cuando se trata de cerrar el objeto Socket. Esta funcin auxiliar puede ser
reutilizada siempre que se quiere cerrar un objeto Socket de forma segura.
Se debe tener en cuenta que el mtodo echoSocket no inicializa el Socket sock a null.
En vez de ello, comprueba que sock no es null antes de llamar a safeClose(). Sin esta
comprobacin, el compilador de Java informa de que la variable sock puede no estar
inicializada. Esta opcin se aprovecha de la capacidad de Java para detectar variables
no inicializadas. Si la variable sock es inicializada a null en un mtodo ms complejo, los

Pgina | 42

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

casos en los en los que sock es usada sin ser inicializada no sern detectados por el
compilador.
Al cerrar un socket se cierra tambin cualquier stream obtenido a travs de
getInputStream y getOutputStream. De manera inversa, cerrando cualquier stream de
socket se cierra el socket entero. En caso de que se tenga duda, siempre es ms seguro
cerrar ambos explcitamente.

FICHEROS
public void printZipContents(String fName)
throws ZipException, IOException, SecurityException,
IllegalStateException, NoSuchElementException
{
ZipFile zf;
try {
zf = new ZipFile(fName);
Enumeration<ZipEntry> e = zf.entries();
...
}
finally {
if (zf != null) {
safeClose(zf);
}
}
}
public static void safeClose(ZipFile zf) {
if (zf != null) {
try {
zf.close();
} catch (IOException e) {
log(e);
}
}
} ...

Esta solucin utiliza una funcin auxiliar para registrar las excepciones que pueden
originarse cuando se trata de cerrar el fichero. Dicha funcin puede ser reutilizada
siempre que se quiere cerrar un fichero de forma segura.
Tambin hay que notar que el mtodo printZipContents no inicializa el objeto zf a null.
En vez de ello, comprueba si el objeto zf no es null antes de llamar a safeClose(). Sin
esta comprobacin, el compilador de Java informa de que la variable zf puede no estar
inicializada. Esta opcin se aprovecha de la capacidad de Java para detectar variables
no inicializadas. Si la variable zf es inicializada a null en un mtodo ms complejo, los
casos en los en los que zf es usada sin ser inicializada no sern detectados por el
compilador.


Pgina | 43

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

3.9.2 Denegacin de servicio

Descripcin
Un atacante podra provocar que el programa se bloquee o no est disponible para los
usuarios, saturando la aplicacin con peticiones e incluso pudiendo especificar en estas
peticiones la cantidad de recursos del sistema que se van a consumir o durante cunto
tiempo se van a utilizar.
Los atacantes pueden denegar el servicio a usuarios legtimos mediante una avalancha
de peticiones, pero los ataques por desbordamiento, con frecuencia, pueden ser
desactivados a nivel de capa de red. Son ms problemticos los errores que permiten a
los atacantes sobrecargar la aplicacin usando un pequeo nmero de peticiones.
Estos defectos permiten a los atacantes especificar la cantidad de recursos del sistema
que sus peticiones consumirn o el tiempo durante el cual las usarn.
Ejemplo 1:
El siguiente cdigo permite a los usuarios especificar la cantidad de tiempo durante la
cual un hilo permanecer inactivo. Especificando un nmero elevado, el atacante
puede mantener activo el hilo indefinidamente. Por el contrario, con un nmero
pequeo de peticiones, el atacante puede agotar el pool de hilos de la aplicacin.
int usrSleepTime = Integer.parseInt(usrInput);
Thread.sleep(usrSleepTime);

Ejemplo 2:
El siguiente cdigo lee un String de un fichero zip. Debido a que usa el mtodo
readLine(), ste leer una cantidad ilimitada de entradas. Un atacante puede hacer uso
de este cdigo para provocar una excepcin, OutOfMemoryException o para consumir
una gran cantidad de memoria, de forma que el programa consuma ms tiempo con el
recolector de basura o se queda sin memoria durante alguna operacin subsecuente.

InputStream zipInput = zipFile.getInputStream(zipEntry);
Reader zipReader = new InputStreamReader(zipInput);
BufferedReader br = new BufferedReader(zipReader);
String line = br.readLine();

Recomendaciones
Validar la entrada del usuario para asegurarse de que no realizar una utilizacin
inapropiada de recursos.
Ejemplo 1:
El siguiente cdigo permite a los usuarios especificar la cantidad de tiempo durante la
cual un hilo permanecer inactivo, pero slo si el valor est entre lmites razonables.

int usrSleepTime = Integer.parseInt(usrInput);
if (usrSleepTime >= SLEEP_MIN && usrSleepTime <= SLEEP_MAX){
Thread.sleepTime(usrSleepTime);
} else {

Pgina | 44

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

Throw new Exception(Invalid sleep duration);
}

Ejemplo 2:
El siguiente cdigo lee un String de un fichero zip. La longitud mxima de la cadena que
leer es MAX_STR_LEN.

InputStream sipInput = zipFile.getInputStream(zipEntry);
Reader zipReader = new InputStreamReader(zipInput);
BufferedReader br = new BufferedReader(zipReader);
StringBuffer sb = new StringBuffer();
int intC;
while ((intC = br.read()) != -1){
char c = (char) intC;
if (c == \n){
break;
}
if (sb.length() >= MAX_STR_LEN){
throw new Exception(input too long);
}
sb.append(c);
}
String line = sb.toString();


3.10 Revelacin de informacin
3.10.1 Violacin de privacidad

Descripcin
El manejo inadecuado de informacin privada, como contraseas de usuario o
nmeros de la seguridad social, puede comprometer la privacidad del usuario y,
muchas veces, es ilegal.
La violacin de la privacidad se da cuando:
1. Informacin privada de los usuarios entra en la aplicacin.
2. Esta informacin es escrita en una localizacin externa, como la consola, el
sistema de ficheros o la red.
Ejemplo:
El siguiente cdigo contiene una sentencia de logging que realiza un registro en un
fichero de log del contenido de los elementos que se han ido aadiendo a la base de
datos. Entre otros valores, se almacena el valor devuelto por la funcin getPassword()
que es la contrasea en texto plano proporcionada por el usuario y asociada a su
cuenta.

pass = getPassword();

Pgina | 45

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

...
dbmsLog.println(id+":"+pass+":"+type+":"+tstamp);

El cdigo anterior registra una contrasea en texto plano en el sistema de ficheros.
Aunque muchos programadores consideran el sistema de ficheros como un repositorio
seguro de datos, no se debe confiar en l implcitamente, sobre todo cuando la
privacidad es un aspecto crtico.
Los datos privados pueden entrar en un programa de mltiples formas:
Directamente desde el usuario en forma de contraseas o datos
personales.
Al ser recogida por la aplicacin al acceder a bases de datos u otros
repositorios de datos.
Indirectamente a partir de terceras entidades.
En ocasiones, datos que no son considerados como privados, pueden tener cierto
impacto en la privacidad, en determinados contextos. Por ejemplo, el nmero de
identificacin de un empleado no es considerado como privado ya que no existe una
forma directa y pblica de mapear ese identificador con los datos personales del
empleado. Sin embargo, si una empresa genera el identificador de empleado a partir
de su nmero de la seguridad social, entonces dicho identificador debe ser
considerado como privado.
En ocasiones, los aspectos de seguridad y privacidad entran en conflicto. Por ejemplo,
desde la perspectiva de la seguridad, todas las operaciones importantes deben ser
registradas para poder posteriormente identificar cualquier actividad anmala. Sin
embargo, cuando se tiene en cuenta la privacidad, esta prctica puede conllevar un
riesgo.
Aunque existen muchas formas en las que se puede hacer un manejo indebido de
datos privados, en muchas ocasiones el riesgo aparece por poner nuestra confianza en
quien no se debe. Los programadores generalmente confan en el entorno operativo
donde se ejecuta la aplicacin y consideran que es seguro almacenar informacin
privada en el sistema de ficheros, en el registro, o en otros recursos controlados
localmente. Sin embargo, an si el acceso a determinados recursos est restringido,
esto no garantiza que se pueda confiar en las personas que tienen acceso a dichos
recursos. Por ejemplo, en 2004, un empleado sin escrpulos de AOL vendi 92 millones
de direcciones de correo electrnico de usuarios a un sitio web dedicado al spam.
En respuesta a este tipo de situaciones, la recopilacin y gestin de datos privados est
cada vez ms regulada. Dependiendo de la localizacin, tipo de negocio y naturaleza de
los datos gestionados, una empresa u organizacin puede estar obligada a cumplir con
diversas regulaciones (por ejemplo, en Espaa, la Ley Orgnica de Proteccin de Datos
o LOPD).
A pesar de estas regulaciones, las violaciones de privacidad se siguen produciendo con
una frecuencia alarmante.

Recomendaciones
Cuando la seguridad y la privacidad entran en conflicto, generalmente se debe dar
mayor prioridad a la privacidad. Para cumplir con los criterios de privacidad y an as

Pgina | 46

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

mantener un nivel adecuado de seguridad, asegrese de que cualquier dato privado es
filtrado antes de salir del programa.
Para asegurar una correcta gestin de la privacidad, el desarrollo de aplicaciones debe
seguir la poltica y guas de privacidad internas de la organizacin. Estas guas deben
especificar cmo una aplicacin debe gestionar los datos privados. Si su organizacin
est sometida a aspectos legales relativos a la privacidad, asegrese de que estas guas
son suficientemente restrictivas como para garantizar el cumplimiento legal. An
cuando su organizacin no est afectada por aspectos legales, debe proteger la
informacin privada o contemplar el riesgo de perder la confianza de los usuarios.
La mejor poltica respecto a los datos privados es minimizar su exposicin. Las
aplicaciones, los procesos y los empleados no deben tener acceso a la informacin
privada a no ser que sea necesario para la tarea que tienen que realizar. Al igual que el
principio de mnimo privilegio dice que ninguna operacin debe realizarse con ms
permisos de los estrictamente necesarios, el acceso a datos privados debe restringirse
al grupo de usuarios ms pequeo posible.

3.10.2 Fuga de informacin del sistema

Descripcin
Revelar datos del sistema o informacin de depuracin puede ayudar a un adversario a
conocer el sistema y conformar un plan de ataque.
Una fuga de informacin ocurre cuando los datos del sistema o la informacin de
depuracin salen del programa a travs de un flujo de salida o funcin de logging.
Ejemplo:
El siguiente cdigo imprime una excepcin en el flujo estndar de error:
try {
...
} catch(Exception e){
e.printStackTrace();
}

Dependiendo del sistema de configuracin, esta informacin puede ser volcada a
consola, escrita en un fichero log, o expuesta a un usuario remoto. En algunos casos, el
mensaje de error dice al atacante, precisamente, a qu clase de ataque es vulnerable el
sistema. Por ejemplo, un mensaje de error en base de datos puede revelar que la
aplicacin es vulnerable a un ataque de inyeccin SQL. Otros mensajes de error pueden
revelar otras pistas indirectas sobre el sistema. En el ejemplo anterior, la ruta de
bsqueda podra contener informacin sobre el tipo de sistema operativo, las
aplicaciones instaladas en el sistema, y el cuidado que han puesto los administradores
en configurar el programa.

Recomendaciones
Escriba los mensajes de error pensando en la seguridad. En entornos de produccin,
deshabilite informacin detallada de error a favor de mensajes breves. Restrinja la
generacin y almacenamiento de salidas detalladas que puedan ayudar a los

Pgina | 47

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

administradores y programadores a diagnosticar problemas. Tenga cuidado con las
trazas de depuracin, pueden aparecer en lugares no muy obvios (embebidas en
comentarios en el HTML de una pgina de error, por ejemplo).
Incluso mensajes breves de error que no revelan trazas de la pila o volcados de la base
de datos pueden ayudar potencialmente a un atacante. Por ejemplo, un mensaje de
Acceso Denegado puede revelar que existe un fichero o usuario en el sistema.
Debe escribir software que sea seguro por s mismo, independientemente de aspectos
externos como la poltica corporativa de IT o la audacia de los administradores de
sistemas para prevenir la fuga de informacin del sistema.

3.10.3 Contraseas escritas directamente en el cdigo

Descripcin
Las contraseas escritas directamente en el cdigo fuente pueden comprometer la
seguridad de un sistema de una manera que puede no ser fcilmente remediable.
Se suele utilizar el trmino hardcoded para hacer referencia a las contraseas que
estn directamente escritas en el cdigo.
Nunca es una buena idea escribir directamente una contrasea en el cdigo fuente.
Esta prctica no slo permite que la contrasea sea vista por todos los programadores
involucrados en el proyecto, sino que tambin hace muy difcil solucionar el problema
cuando es necesario. Una vez que el cdigo est en produccin, la contrasea no
puede ser modificada sin liberar un parche del software. Si la cuenta protegida por la
contrasea es comprometida, los responsables del sistema se vern obligados a elegir
entre seguridad y disponibilidad.
Ejemplo:
El siguiente cdigo utiliza una contrasea escrita directamente en el cdigo para
conectarse a una base de datos.

...
DriverManager.getConnection(url, "scott", "tiger");
...

Este cdigo funcionar perfectamente, pero cualquiera que tenga acceso al cdigo
tendr acceso a la contrasea. Una vez que la aplicacin est desplegada, no hay forma
de cambiar las credenciales para acceder a la base de datos a menos que se modifique
el cdigo del programa. Un empleado con malas intenciones y acceso a este cdigo,
puede utilizarlo para comprometer el sistema. Ni siquiera es necesario que se tenga
acceso al cdigo fuente, ya que si un atacante tiene acceso a los bytecodes de la
aplicacin, puede
utilizar el comando javap c para desensamblar el cdigo, que contendr el valor de la
contrasea utilizada. El resultado de esta operacin puede ser algo como lo siguiente
para el cdigo visto anteriormente:

javap -c ConnMngr.class
22: ldc #36; //String jdbc:mysql://ixne.com/rxsql

Pgina | 48

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

24: ldc #38; //String scott
26: ldc #17; //String tiger


Recomendaciones
Las contraseas nunca deben ser escritas directamente en el cdigo. Es preferible que
sean mantenidas en un recurso externo y ofuscadas de alguna manera. Almacenar
contraseas en texto plano en cualquier parte del sistema puede permitir a cualquier
usuario con permisos suficientes leer y utilizar maliciosamente dichas contraseas.
Algunos productos hacen gala de gestionar las contraseas de una forma ms segura;
por ejemplo, un servidor de aplicaciones comercial utiliza un simple XOR para ofuscar
las contraseas; sea escptico respecto a este tipo de tcnicas. Este y otros productos
utilizan mecanismos de encriptacin dbiles o desfasados que son insuficientes para
contextos en los que la seguridad es crtica. Para una solucin segura, la nica opcin
viable es una propietaria.































Pgina | 49

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s










4. verificacin

El proceso de verificacin de la seguridad de una aplicacin puede dividirse en tres
etapas principales:

Preparacin
A la hora de llevar a cabo una verificacin efectiva de la seguridad de una aplicacin es
crtico que el equipo encargado de realizar esta tarea:
Entienda el propsito de la aplicacin y qu puntos dentro de ella son
ms crticos.
Identifique las principales amenazas, su motivacin y cmo podran
atacar la aplicacin.
Para ello, antes de comenzar el proceso de verificacin, el equipo deber estar
familiarizado con los siguientes aspectos:
Cdigo fuente: El equipo deber tener conocimientos del lenguaje
utilizado en la codificacin y de las caractersticas de ese lenguaje desde la

Pgina | 50

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

perspectiva de seguridad.
Contexto: Se debe conocer el funcionamiento de la aplicacin que
est siendo revisada, el tipo de datos que se procesa y el dao que
supondra que estos datos fueran comprometidos.
Audiencia: Los usuarios a los que va destinada la aplicacin, son
usuarios externos o por el contrario, la aplicacin es utilizada por usuarios
internos confiables?. La aplicacin se comunica con otras mquinas o
servicios?
Importancia: Hasta qu punto es relevante para la aplicacin que
quede inactiva durante un periodo de tiempo significativo o no?

Adems, el equipo de verificacin necesitar informacin formal de la aplicacin. sta
puede obtenerse revisando documentos de especificacin de requisitos,
especificaciones funcionales, resultados de pruebas, etc. Sin embargo, en muchos
casos esta documentacin est obsoleta y no contiene la informacin de seguridad
apropiada. Por ello, es muy recomendable mantener alguna conversacin con el
equipo de desarrollo para compartir informacin bsica sobre las consideraciones y
controles clave de seguridad y adquirir una idea general sobre la estructura base del
cdigo y las libreras que se estn utilizando.

Priorizacin
Una vez que se haya recopilado esta informacin, el equipo de verificacin deber
desarrollar un modelo de amenazas a alto nivel con el objetivo de establecer la
prioridad a la hora de llevar a cabo el proceso de verificacin.
Descomponer la aplicacin: El objetivo de este paso es adquirir un
conocimiento ms profundo de la aplicacin. Se obtendr informacin
acerca de cmo interacta la aplicacin con entidades externas, cmo es
utilizada, qu puntos de entrada posee con los que un atacante podra
interactuar, en qu reas o elementos podra estar ms interesado un
atacante y qu nivel de privilegios poseen las entidades externas con las
que interacta la aplicacin.



Determinar y priorizar las amenazas: A la hora de identificar las

Pgina | 51

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

amenazas, se recomienda establecer una metodologa de categorizacin, ya
sea propia o existente. Es aconsejable que la metodologa que se adopte
tenga en cuenta:
El punto de vista del atacante, es decir, se valoren los distintos exploits
que puedan ser utilizados por un usuario malicioso.
La perspectiva defensiva de la aplicacin, es decir, se tendrn en cuenta
las posibles debilidades en los controles de seguridad implementados.
Despus de que las amenazas hayan sido identificadas, se debera determinar el riesgo
de cada una de ellas. De la misma manera que en el caso anterior, se recomienda el
uso de un modelo, ya sea propio o existente. Por ejemplo, podra utilizarse un modelo
basado en factores generales de riesgo como probabilidad impacto.
Establecer contramedidas y mitigacin: La falta de proteccin de una
amenaza indica una vulnerabilidad, cuya exposicin al riesgo podra ser
mitigada con la implementacin de una contramedida. A la hora de
identificar estas contramedidas pueden utilizarse listas de mapeo
amenaza-contramedida: despus de haber asignado el riesgo a cada una
de las amenazas, es posible ordenarlas de mayor a menor riesgo, y
priorizar el esfuerzo para mitigar cada una de ellas.

Ejecucin
Una vez que el equipo de verificacin ha obtenido el conocimiento suficiente sobre la
aplicacin y ha establecido la prioridad que debe establecerse en el proceso de
verificacin en base a las amenazas detectadas y el riesgo de cada una de ellas, es
recomendable que realice las siguientes tareas que garanticen que los controles de
seguridad establecidos son adecuados y que las recomendaciones de codificacin
anteriores han sido tenidas en cuenta:
Realizacin de pruebas de hacking tico peridicas sobre las
aplicaciones en ejecucin, mostrando evidencias de las vulnerabilidades
explotadas.
Estas pruebas se realizarn en entornos de pre-produccin. Si en algn caso esto no
fuera posible se llevarn a cabo en produccin de forma controlada, teniendo presente
que en este supuesto NUNCA debern explotarse las vulnerabilidades detectadas para
no afectar al funcionamiento normal de la aplicacin. Los resultados de las mismas se
reportarn en un informe (Ver estructura del documento de evaluacin de la seguridad
de las aplicaciones en el apartado Documentacin).
Ejecucin de pruebas estticas de cdigo fuente peridicas sobre las
distintas versiones del software, incluidas revisiones manuales del cdigo
siempre que se considere necesario para completar el anlisis.

Estas pruebas se realizarn en entornos de desarrollo y se reportarn los resultados de
las mismas en un informe (Ver estructura del documento de evaluacin de la seguridad
de las aplicaciones en el apartado Documentacin).

Para llevar a cabo los anlisis anteriores, tanto a nivel esttico como
de hacking tico, se recomienda:

Pgina | 52

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s

Establecer metodologas propias o existentes (por ejemplo: CEH-
Certified Ethical Hacker, para pruebas de hacking tico).
Hacer uso de herramientas automatizadas que faciliten la deteccin de
vulnerabilidades en las aplicaciones. Los resultados obtenidos por dichas
herramientas debern de ser comprobados de forma manual ya que en
general estas herramientas de anlisis tienden a proporcionar falsos-
positivos (vulnerabilidades que en realidad no lo son) que hay que
desechar y/o vulnerabilidades que pueden ser descartadas conociendo
el contexto de ejecucin de la aplicacin. Este anlisis se completar con
la posible deteccin de vulnerabilidades no detectadas con dichas
herramientas (falsos- negativos).
Se recomienda que el anlisis de seguridad de la aplicacin no se
limite al conjunto de las 10 vulnerabilidades de OWASP. Es preciso valorar
otras vulnerabilidades que se puedan dar en el contexto de ejecucin
especfico de la aplicacin a desarrollar/mantener.
Es aconsejable consultar las Cheat Sheets de OWASP, como guas de
referencia para garantizar la seguridad de las aplicaciones.

Los resultados de todas las actividades realizadas durante esta verificacin, sern
recogidos en un informe de resultados, dirigido al gestor de la comunidad de
desarrollo. Este informe debe contener al menos los siguientes apartados:
1. Objetivo
Descripcin general del documento.
2. Alcance
Descripcin del alcance del documento.
3. Caractersticas de la aplicacin evaluada
Descripcin de la versin de la aplicacin que se va a evaluar.
4. Metodologa
Descripcin de la metodologa utilizada para la deteccin de vulnerabilidades, que
incluir:
Clasificacin de las vulnerabilidades detectadas.
Criterio para determinar el estado general de seguridad de la aplicacin.
5. Resultados
Listado de vulnerabilidades detectadas en la aplicacin
Acciones correctivas
6. Conclusiones










Pgina | 53

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s












5. Valoracin de la seguridad de las aplicaciones

En base al informe de resultados, el gestor de la comunidad valorar si los controles de
seguridad implementados son correctos y cumplen las recomendaciones de seguridad
especificadas con el objetivo de establecer acciones correctivas si es necesario. Si fuera
as, una vez propuestas las acciones correctivas e implementadas, se deber volver a
ejecutar el proceso de verificacin para comprobar si se han corregido los defectos
detectados en la revisin anterior.


























Pgina | 54

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s












6. ENS (Esquema Nacional de Seguridad)

El Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de
Seguridad en el mbito de la Administracin Electrnica, prevista en el artculo 42 de la
Ley 11/2007, establece la poltica de seguridad en la utilizacin de medios electrnicos
por las Administraciones Pblicas y est constituido por principios bsicos y requisitos
mnimos que permiten una proteccin adecuada de la informacin.
El Esquema Nacional de Seguridad es aplicado por las Administraciones Pblicas para
asegurar el acceso, la integridad, la disponibilidad, la autenticidad, la confidencialidad,
la trazabilidad y la conservacin de los datos, informaciones y servicios utilizados en
medios electrnicos que gestionen en el ejercicio de sus competencias.
La adecuacin de los sistemas al Esquema Nacional de Seguridad debe realizarse a
medida para cada entidad u organismo pblico. Para la elaboracin del Plan de
Adecuacin al ENS se recomienda seguir las pautas de carcter general que establece la
Gua de seguridad CCN-STIC-806 elaborada por el Centro Criptolgico Nacional.

Anexo 3: Memoria de la Entidad.


Pgina | 55

B
u
e
n
a
s

p
r

c
t
i
c
a
s

d
e

c
a
l
i
d
a
d

e
n

e
l

d
e
s
a
r
r
o
l
l
o

d
e

a
p
l
i
c
a
c
i
o
n
e
s