Nombre del documento Código Fecha versión

MANUAL DE ESTANDARES DE DISEÑO Y

14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Estándares de diseño y programación en

Java
Versión 1.0

Página.1 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

INDICE

1. INTRODUCCIÓN..........................................................................................................................................4

2. ESTANDARES DE PROGRAMACION......................................................................................................5
2.1. ESTÁNDARES DE NOMENCLATURA DE JAVA................................................................................................5
2.1.1. Notación de Paquetes..........................................................................................................................5
2.1.2. Notación de Clases.............................................................................................................................6
Notación General de Clases.............................................................................................................................6
Notación de Clases Java Beans........................................................................................................................7
Notación de las clases Action...........................................................................................................................7
Notación de las clases ActionForm..................................................................................................................8
Notación de las clases DAO..............................................................................................................................8
Notación de las clases Util................................................................................................................................8
2.1.3. Notación de Interfaces........................................................................................................................9
2.1.4. Notación de Atributos.........................................................................................................................9
2.1.5. Notación de Métodos..........................................................................................................................9
2.1.6. Notación de Variables.......................................................................................................................10
2.1.7. Notación de Constantes.....................................................................................................................10
3. ESTANDARES DE BASE DE DATOS......................................................................................................11
3.1. CONEXIÓN SQL........................................................................................................................................11
3.2. LIBERAR RECURSOS..................................................................................................................................11
3.3. LÓGICA DE PERSISTENCIA..........................................................................................................................11
3.4. MANEJO DE EXCEPCIONES.........................................................................................................................12
3.5. USO DE VALORES MONETARIOS.................................................................................................................12
3.6. CREAR LAS CLASES DAO..........................................................................................................................12
DAO TIPO IBATIS................................................................................................................................................13
4. PRACTICAS DE DESARROLLO..............................................................................................................16
4.1. DEFINICIÓN DE COMENTARIOS..................................................................................................................16
4.2. DOCUMENTACIÓN DE CLASES E INTERFACES.............................................................................................16
4.3. DOCUMENTANDO LOS CONSTRUCTORES....................................................................................................16
4.4. DOCUMENTACIÓN DE FUNCIONES MIEMBRO..............................................................................................16
4.5. DOCUMENTACIÓN DE CAMPOS MIEMBRO...................................................................................................17
4.6. DOCUMENTACIÓN DE CLASES IMPLEMENTADAS........................................................................................17
4.7. BLOQUE DE COMENTARIOS.......................................................................................................................17
4.8. COMENTARIOS DE UNA LÍNEA...................................................................................................................17
4.9. COMENTARIOS FINALES............................................................................................................................18
4.10. NOTACIÓN PARA LOS ARCHIVOS JSP Y HTML..........................................................................................18
4.11. RECOMENDACIONES GENERALES DE PROGRAMACIÓN...............................................................................19
4.11.1. Recomendaciones de optimización....................................................................................................19
4.11.2. JDBC...............................................................................................................................................19
4.11.3. Excepciones......................................................................................................................................20
4.11.4. JSP...................................................................................................................................................21
LIBRERÍAS DE ETIQUETAS (TAGLIBS) DE SOPORTE PARA LA CONSTRUCCIÓN DE JSPS......................................21
COMENTARIOS.....................................................................................................................................................21
SOPORTE PARA ACENTUACIÓN............................................................................................................................22

Página.2 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

NOMBRAMIENTO DE OBJETOS HTML.................................................................................................................22

5. ESTANDARES DE SEGURIDAD..............................................................................................................23
5.1. NAVEGACIÓN FORZADA 1: ACCESO DESDE PÁGINA PRINCIPAL...................................................................23
5.2. NAVEGACIÓN FORZADA 2: VER CÓDIGO FUENTE.......................................................................................24
5.3. NAVEGACIÓN FORZADA 3: ACCESO A ARCHIVOS OCULTOS........................................................................25
5.4. NAVEGACIÓN FORZADA 4: CONTROL DE ACCESO NO VALIDADO................................................................26
5.5. NAVEGACIÓN FORZADA 5: EVALUACIÓN DE PRIVILEGIOS EN SERVIDOR.....................................................27
5.6. NAVEGACIÓN FORZADA 6: TRES NIVELES DE VALIDACIÓN POR PERFIL.......................................................28
5.7. NAVEGACIÓN FORZADA 7: JSP FUERA DEL DIRECTORIO RAÍZ.....................................................................28
5.8. NAVEGACIÓN FORZADA 8: BLOQUEO DE TIPOS DE ARCHIVO......................................................................29
5.9. INSERCIÓN DE COMANDOS: SQL INJECTION..............................................................................................29
5.10. CROSS SITE SCRIPTING 1: INYECCIÓN DE CÓDIGO INCRUSTADO..................................................................32
5.11. CROSS SITE SCRIPTING 2: EJECUCIÓN DE CÓDIGO INYECTADO ALMACENADO.............................................32
5.12. CONTROL DE ACCESO INTERRUMPIDO.......................................................................................................33
5.13. ADMINISTRACIÓN DE AUTENTICACIÓN Y SESIÓN INTERRUMPIDA...............................................................35
5.14. MANEJO INADECUADO DE ERRORES..........................................................................................................38
5.15. ALMACENAMIENTO INSEGURO..................................................................................................................40
5.16. NEGACIÓN DE SERVICIO............................................................................................................................41
5.17. ADMINISTRACIÓN DE CONFIGURACIÓN INSEGURA.....................................................................................43
6. DEFINICION DE HERRAMIENTAS DE DESARROLLO....................................................................45

Página.3 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

1. INTRODUCCIÓN
Presentar la guía de los estándares a utilizarse en la Programación, a ser desarrollado en arquitectura
distribuida (entorno multicapa) para aplicaciones Web, utilizando Java 1 como lenguaje de programación.

En el documento se ha contemplado lo siguiente:

 Estándares de Programación, donde se indica la nomenclatura a ser utilizada para nombrar los
programas elaborados en lenguaje Java2.

 Definición Preliminar de Prácticas de Desarrollo, donde se indican aquellas practicas de desarrollos

incorporados a la aplicación.

1
Java: Lenguaje de programación orientado a objetos..
2
Se incluye en la presente guía la nomenclatura de paginas JSP.

Página.4 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

2. ESTANDARES DE PROGRAMACION

2.1. Estándares de Nomenclatura de Java

En esta sección se detallan los estándares de nomenclatura que se usan en los diferentes Objetos Java
durante el desarrollo de una aplicación. Estas notaciones se basan en las recomendaciones de los
creadores de Java y se aplican sobre los siguientes componentes:

1. Paquetes
2. Clases
3. Atributos
4. Interfaces
5. Atributos
6. Métodos
7. Variables
8. Constantes

2.1.1. Notación de Paquetes

Los paquetes es un conjunto de clases y paquetes relacionados, se debe de diseñar un sistema
dividiendo su funcionalidad entre varios paquetes. Los paquetes nos permiten definir una Clase única
por paquete.

La notación para definir un paquete es el siguiente:

- El nombre del paquete deberá estar escrito en minúsculas, no símbolos ni números.
- Entre cada nivel contenedor del sub paquete será especificado por el punto.
- Las aplicaciones Web deberán contener el nombre de dominio invertido. El dominio para Hermes se
usara como prefijo: pe.com.hermes.
- Seguido del nombre de aplicación web en desarrollo: pe.com.hermes.aplicacion
- Los sub paquetes del paquete anterior será la distribución de los tipos de objetos que participan en
la arquitectura del proyecto Web: bean, excepción, servicios, web.

Ejemplo:

Nombre del paquete Descripción de clases contenidas

Página.5 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

pe.com.hermes.hermetic.bean Clases de Tipo Bean

pe.com.hermes.hermetic.excepcion Clases de Tipo Excepción
pe.com.hermes.hermetic.servicios Clases de Tipo Servicios
pe.com.hermes.hermetic.web Clases de Tipo Web

2.1.2. Notación de Clases

Notación General de Clases

El Objeto Clase de Java en un proyecto web puede extender del Objeto tipo: Action, ActionForm,
Exception, Interface, Abstracta, Bean, DAO, Util.

La notación para definir una Clase es el siguiente:

- El nombre de la Clase deberá estar escrito en minúsculas, con la letra inicial en Mayúscula.
- Usar palabras completas y no usar abreviaturas.
- Si el nombre de clase está compuesto por más de una palabra, cada palabra debe empezar
con mayúscula.
- Los nombres de clase no pueden contener espacios ni caracteres especiales, sólo son
permitidas las letras de la “a” a la “z” y los números del 0 al 9.
- El nombre de las clases según el tipo de objeto se nombrará con el sufijo según la tabla.
Tipo de Clase. Nombre de Clase con sufijo.
Action NombreClaseAction
ActionForm NombreClaseForm
Exception NombreClaseException
Bean NombreClaseBean
DAO NombreClaseDAO
Util NombreClaseUtil

Luego del prefijo se añadirá el nombre que representa de la mejor manera la funcionalidad de la
clase.

En el Caso de que este nombre sea una composición de varias palabras se tomará las cuatro
primeras letras de estas excepto en el caso de la ultima palabra que compone el nombre que estará
en su totalidad de letras.
Ejemplo

Página.6 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Clase: Comprobante de Servicio

Notación: ComServicioDAO

Notación de Clases Java Beans

Los Java Beans, son las clases que representan alguna identidad, tabla o vista de base de datos y
estas deben contener los atributos correspondientes a los datos con el modificador private y los
métodos setters y getters (públicos) para acceder a dichos atributos.

En cuanto al nombre de las clases este debe ser iniciado con el prefijo del identificador del tipo de
clase en mayúsculas: Bean para Java Beans.

<nombreJavaBean>Bean
Ejemplo
ComprobanteServicioBean (Representa el objeto bean con los atributos del comprobante de
servicio).

Notación de las clases Action

Las clases que extienden del objeto Action, son las clases encargadas de la comunicación de los
JSP y DAO. El nombre de esta clase comienza con la letra mayúscula y el sufijo Action.

El prefijo de la clase Action puede ser Listar o Mostrar, dependerá del comportamiento de la clase.
Listar se usa al realizar acciones de Buscar, Eliminar, Grabar, Actualizar y el prefijo Mostrar se
utiliza al ingresar a la opción de la aplicación, relacionado a la accion: Listar

Luego del prefijo se coloca el nombre más representativo relacionado con el nombre de Opción de
la aplicación.
Notación:
<prefijo><nombreClase>Action
Ejemplo
ListarHMF2006Action (Búsqueda del formulario de Abonos).

Notación de las clases ActionForm

Las clases que extienden del objeto ActionForm son las clases encargadas de encapsular los
valores del formulario, tiene un comportamiento similar a JavaBean.

El nombre de esta clase no tiene prefijo, el nombre de esta clase comienza en mayúscula.

El nombre será el más representativo que encapsula la información del formulario y el sufijo Form.
Notación:
<nombreClaseActionForm>Form
Ejemplo

Página.7 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Mostrar2006Form (Clase que tiene los tipos de datos del formulario Abonos).

Notación de las clases DAO

Las clases tipo DAO son las clases encargadas de la comunicación con la base de datos.

Se crea una clase de tipo Interface y se extiende de ella para sobrescribir los métodos.

El nombre de la clase DAO no tiene prefijo, el nombre comienza con la primera letra en mayúscula.

Deberá de ingresar el nombre será el más representativo seguido del sufijo DAOImpl.

Notación:
<nombreClaseDAO>DAOImpl
Ejemplo
Mostrar2006DAOImpl (Clase Implementada de Abonos).

Notación de las clases Util

Las clases tipo Util son las clases personalizadas que contienen métodos que servirán en la
ejecución de un proceso independiente del framework, generalmente se utiliza para procesos de
texto, lectura de archivos, formato de fecha, conversiones numéricas, etc.

El nombre de la clase Util no tiene prefijo, el nombre comienza con la primera letra en mayúscula.

Deberá de ingresar el nombre será el más representativo seguido del sufijo Util.
Notación:
<nombreClaseUtil>Util
Ejemplo
CadenaUtil (Clase que contiene método de operación de cadenas de texto).

2.1.3. Notación de Interfaces

Los nombres de interfaces tienen el mismo tratado que los nombres de clases.
Notación:
<nombreInterface>
Notación de Interface implementada:
<nombreInterface>Impl
Ejemplos:
CuentaDAO (Interface que contiene la estructura de métodos de la Clase DAO)
CuentaDAOImpl (Interface implementada que contiene Clase DAO con los métodos
sobrescritos)

2.1.4. Notación de Atributos

Los atributos de las clases y métodos tienen el mismo comportamiento y notación.

Página.8 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

- El nombre del atributo debe empezar con la primera letra minúscula.

- El nombre del atributo no puede ser verbos.
- El nombre del atributo no debe contener espacios ni caracteres especiales, solo se permite
usar letras de la “a” a la “z” y los números del 0 al 9
- Si el nombre de atributo está compuesto por más de una palabra, cada palabra debe
empezar con mayúscula.

Ejemplo:
String tipoUnidMonetaria (Cadena que representa el tipo de unidad monetaria).

2.1.5. Notación de Métodos

Los métodos seguirán la notación siguiente:
- El nombre del método debe empezar con un verbo como prefijo.
- El nombre del método deberá comenzar con la primera letra del nombre en minúscula
- Si el nombre del método está compuesto por más de una palabra, cada palabra debe
empezar con mayúscula.
- El nombre del método no pueden contener espacios ni caracteres especiales, sólo son
permitidas las letras de la “a” a la “z” y los números del 0 al 9.

Ejemplos:
validaNumero().
cargarLista().

2.1.6. Notación de Variables

Las variables incluidas en los métodos seguirán la notación siguiente:
- El nombre de la variable debe empezar con la primera letra en minúscula.
- Si el nombre de la variable está compuesta por más de una palabra, cada palabra debe
empezar con mayúscula.
- El nombre de la variable debe ser corto y alto valor significativo.
- Evitar el nombre de variable de un solo carácter.
- Algunos valores comunes de variables para enteros son: idx, idy, idz, etc.

Ejemplo:
int idx = 0 (variable entera para realizar bucles).

Página.9 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

2.1.7. Notación de Constantes

El nombre de las constantes seguirá la notación siguiente:
- El nombre de constante deberá escribirse en mayúsculas separada con el carácter (“_”).
- El nombre de constante deberá de contener especificar la descripción de la constante.

El tipo de constante debe ser definido como un atributo publico, estático (pueda ser leído desde
cualquier clase) y final (no permite la modificación del valor asignado).

La clase que contiene las constantes debe ser nombrada como: Constante<aplicación o modulo>.

Ejemplos:
//Tipo de operación
public static final String TIPO_OPERACION_DEPOSITO="DEPO";
public static final String TIPO_OPERACION_FALTANTE="FALT";
public static final String TIPO_OPERACION_SOBRANTE="SOBR";

Página.10 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

3. ESTANDARES DE BASE DE DATOS

Se definen los estándares a utilizar en conexiones a Base de Datos desde la aplicación.

3.1. Conexión SQL

El Framework proveerá la conexión a través de dos métodos que pueden ser llamados dentro de la
Expedientes
clase DAO. Estos son los siguientes:

this.getConnection()Opcion 2Método a usar por defecto. Obtiene una conexión

estándar SQL.
this.getNativeConnection() Este método debe ser llamado solamente cuando se
desean utilizar objetos propios (nativos) de la base
de datos SQL, por ejemplo ORACLE STRUCT
ARRAY.

Importante: Estos métodos serán usados solamente si se implementa DAO con JDBC; pero si se
implementan con Ibatis, será el framework el que se encargue de crear la conexión SQL sin requerir
la intervención del programador.

3.2. Liberar recursos

 El desarrollador es responsable de cerrar los objetos que ha abierto para trabajar con JDBC o
SQL. Para esto llamará al método con.close() por cada objeto abierto.
 El framework se encargará de cerrar las conexiones.

3.3. Lógica de persistencia

Maneja el almacenamiento de la información, en medios persistentes (Base de datos). Componentes

principales de esta capa:

 Clases con el patrón DAO (Data Access Object): Son interfaces que esconden la lógica de
manejo de acceso a fuentes de datos (Por ejemplo Bases de datos) sirviendo así de puente
entre un sistema orientado a objetos hecho en lenguaje java y otro que habla en lenguaje de
persistencia y recuperación de datos, como es el SQL. Esta separación favorece la
mantenibilidad del código.
 Clases que utilizan JDBC para acceder a Bases de datos relacionales.

Página.11 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

 Los DAO, al ser interfaces, se pueden implementar utilizando diferentes tecnologías de

persistencia y acceso a datos (Ibatis, Hibernate, JDBC, Cayenne, .etc) permitiendo así elegir la
mejor tecnología para el caso a desarrollar, los DAO permiten incluso utilizar más de una
tecnología de persistencia en un mismo proyecto.

3.4. Manejo de excepciones

Toda excepción debe ser lanzada al programa superior, mediante la cláusula "throws Exception".
La excepción a esto es si la excepción debe ser controlada específicamente dentro del programa
por condición requerida. Las excepciones lanzadas de esta manera serán finalmente capturadas
en la clase Action, bloque cacth, que será la encargada de grabar el error en log y derivar a la
pantalla genérica de error.

3.5. Uso de valores monetarios

Se debe usar Bigdecimal para guardar valores monetarios. Evitar el uso del tipo de dato Float y
Double para almacenar valores monetarios, esto es debido a que no guardan correctamente los
decimales.

3.6. Crear las clases DAO

 Un DAO es una interfaz, con una representación lógica de una tabla, objeto, store procedure, join,
vista o cualquier otro objeto de la base de datos. La interfaz tendrá las operaciones que se pueden
realizar sobre dicho objeto, las cuales pueden ser: insert, update, select, .etc.
 Un DAO puede ser implementado de dos maneras: usando JDBC o Ibatis. La manera recomendad
y a ser considerada como default es usando Ibatis. Pero, existen ocasiones en las cuales no se
puede usar Ibatis, y es necesario implementar el DAO en JDBC, estas ocasiones son:
1. Cuando se necesita llamar a un store procedure
2. Cuando se necesita utilizar DBLinks
3. Cuando se necesita utilizar objetos nativos de base de datos (ArrayStruct de Oracle, .etc)

DAO tipo Ibatis

 Los DAO tipo Ibatis extienden de SqlMapClientDaoSupport, que es el conector que ofrece
Spring para trabajar con Ibatis.

Página.12 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

 Los DAO tipo JDBC extienden de JDBCDAOAbstract, que es el conector que ofrece Spring
para trabajar con JDBC y además tiene los métodos getConnection() y
getNativeConnection().
 Observar que el DAO Ibatis depende del archivo “sqlMapSecurity.xml”, este es el archivo
que contiene los queries a ser usados para acceder al objeto de base de datos (Tabla
IntentoUsuario en este caso).
 Todo DAO debe ser inscrito en el archivo “propiedadesDAO.xml”, como muestra el ejemplo:
<!—DAO-->
<bean id="seguridadDAO" class="pe.com.hermes.dao.jdbc.SeguridadJDBC">
<property name="dataSource"><ref bean="hermeticDS"/></property>
</bean>
<bean id="intentoUsuarioDAO"
class="pe.com.hermes.dao.ibatis.IntentoUsuarioIbatis">
<property name="dataSource"><ref bean="dataSource"/></property>
<property name="sqlMapClient"><ref local="ibatisSqlConfig"/></property>

</bean>

 Notar que los DAO, al momento de ser inscritos en el XML, pueden acceder a diferentes
bases de datos.

 Además, observar que los DAO tipo Ibatis requieren el atributo “sqlMapClient”, este atributo
apunta al archivo de configuración de Ibatis. Este archivo es el “ibatisSqlConfig.xml” y es
como sigue:
<!-- colocar aqui los sqlMapXXXX.xml de los modulos -->
<sqlMap resource="pe/com/hermes//dao/ibatis/sqlMapAbono.xml"/>
<sqlMap resource=" pe/com/hermes//dao/ibatis/sqlMapGCO.xml"/>
<sqlMap resource=" pe/com/hermes//dao/ibatis /sqlMapEmpresa.xml"/>

 Es en este archivo en donde se inscriben los archivos “sqlMap” por cada módulo.
 Regla: Un módulo puede tener más de un archivo sqlMap.
 Regla: El (los) archivo(s) sqlMap del módulo DEBEN estar ubicados en la carpeta
pe/com/hermes//dao/ibatis para su fácil acceso.
 El archivo “sqlMapSecurity” es el que contiene las operaciones a las tablas de ese módulo.
Este archivo es como sigue:
<sqlMap namespace="security">
<typeAlias alias="intento" type=" pe.com.hermes.bean.IntentoUsuarioBean"/>

<select id="getIntentoUsuarioByPK" resultClass="intento">

SELECT
NOMB as userId,
NRO_CAN_TOT as cantidadIntentos
FROM
CSMC_USUA_WEB

Página.13 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

WHERE
NOM_USR = #llave#
</select>

<insert id="insertIntentoUsuario" parameterClass="intento">

insert into CSMC_USUA_WEB
(NOMB , NRO_CAN_TOT, FEC_USR_MODI)
values
(#userId#, #cantidadIntentos#, SYSDATE)
</insert>

<update id="updateIntentoUsuario" parameterClass="intento">

update CSMC_USUA_WEB
set NRO_CAN_TOT = #cantidadIntentos#,
FEC_USR_MODI = SYSDATE
where NOM_USR = #userId#
</update>

</sqlMap>

 El atributo “namespace” al inicio del archivo es importante porque se utiliza en la codificación

java identificar rápidamente las operaciones del archivos sqlMap.
 Regla: el archivo sqlMapXXX.xml debe llamarse fisicamente de una manera igual al atributo
namespace que tiene adentro, más el prefijo sqlMap. Es por eso que el archivo anterior se
llama “sqlMapSecurity.xml” y su atributo interior se llama “security”
 En el archivo sqlMapxxx.xml se colocan las sentencias SQL necesarias para trabajar con la
entidad. Se utilizan variables encerradas en ## para recibir parámetros.
 La forma de acceder a los métodos de Ibatis desde java es como sigue:
public class IntentoUsuarioIbatis extends SqlMapClientDaoSupport implements
IntentoUsuarioDAO
{
private static Logger flog = Logger.getLogger(IntentoUsuarioIbatis.class);
public IntentoUsuarioBean getByPK(String llave) throws DataAccessException
{
if (flog.isDebugEnabled())
flog.debug("calling ibatis getbyPK intento usuario");
IntentoUsuarioBean iub = (IntentoUsuarioBean)
getSqlMapClientTemplate().queryForObject("security.getIntentoUsuarioByPK", llave);
return iub;
}
public void insert(IntentoUsuarioBean iub) throws DataAccessException
{
getSqlMapClientTemplate().insert("security.insertIntentoUsuario",iub);
}
public void update(IntentoUsuarioBean iub) throws DataAccessException
{
getSqlMapClientTemplate().update("security.updateIntentoUsuario",iub);
}
}

Página.14 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

 Cuando se use sentencias de ibatis se recomienda el uso de la sentencia “CDATA” en las

secciones donde los parámetros podrían traer problemas, así el parser no identificara esta
sección como error. ejemplo:
<![DATA(T.FECHA<=#propiedad#)]>

Página.15 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

4. PRACTICAS DE DESARROLLO

4.1. Definición de Comentarios

Java tiene tres tipos de comentarios en Clases:

 comentarios de documentación (/** ... */).

 comentarios de estilo-C (/* .. */).
 comentarios de línea única (//)
Java tiene dos tipos de comentarios en JSP:
 comentarios Java en JSP(<¡-- ……..-->).
 comentarios de html (<¡-- ………….--> ).

4.2. Documentación de Clases e interfaces

 Utilizar el siguiente bloque de comentario como plantilla para cada clase e Interface declarada:

/**
* Resumen.
* Descripción detallada
*
* @author Juan Torres
* @version 1.00, 20/12/2009
*
*/

4.3. Documentando los constructores

Utilizar el siguiente bloque de comentario como plantilla para cada constructor declarado:
/**
* Resumen.
* Descripción detallada
* @param nombre Explicación y tipo de parámetro
* @param nombre Explicación y tipo de parámetros
*
* @throws nombre Explicación
*/

4.4. Documentación de Funciones Miembro

Utilizar el siguiente bloque de comentario como plantilla para cada función miembro declarada:
/**
* Resumen.
* Descripción detallada
*

Página.16 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

* @param nombre Explicación y tipo de parámetro

* @param nombre Explicación y tipo de parámetros
*
* @return Explicación del valor de retorno del método
*
* @throws nombre Explicación
*
*/
4.5. Documentación de campos miembro

Las variables de clase o de Instancia deben ser comentadas utilizando la siguiente plantilla.

/** Apellido paterno y materno */

4.6. Documentación de Clases implementadas

Los comentarios de implementación no serán tomados en cuenta por el javadoc, se utilizarán para comentar
código referente a la implementación. Tendremos tres formas para comentar de bloque, línea, de fin de
línea:

4.7. Bloque de Comentarios

Los bloques de comentarios se usan para proporcionar descripciones de ficheros, métodos, estructuras de
datos y algoritmos. Los bloques de comentarios podrían usarse al principio de cada Clase y antes de cada
método. También pueden usarse en otros lugares, como dentro de los métodos. Los bloques de
comentarios dentro de una función o métodos deberían estar identados al mismo nivel que el código que
describen. Un bloque de comentario debería ir precedido por una línea en blanco para configurar un
apartado del resto del código

/*
* Aquí un bloque de comentarios
*/
4.8. Comentarios de una Línea
Los comentarios cortos pueden aparecer como una sola línea identada al nivel del código que la sigue. Si
un comentario no se puede escribir en una sola línea, debería seguir el formato de los bloques de
comentario. Un comentario de una sola línea debería ir precedido de una línea en blanco. Aquí tenemos un
ejemplo:

int i = 0;

/* Manejando la Condición. */
if (condition) {
...
}

Página.17 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

4.9. Comentarios Finales

El delimitador de comentario // puede comentar una línea completa o una línea parcial. No debería usarse
en líneas consecutivas para comentar texto; sin embargo, si puede usarse en líneas consecutivas para
comentar secciones de código. Abajo tenemos ejemplos de los tres estilos:

if (cliente.equals(empleado)) {
...
} else{
return false; //no es un cliente.
}

4.10. Notación para los archivos JSP Y HTML

Para los archivos *.html (jsp) se colocará el prefijo de la opción principal a la que pertenece:
Seguido de la descripción de la acción que realiza.

Opción Prefijo
Administración ad
Mantenimiento Mn
Transacción Tr
Consulta cs
Reportes rp

<PrefijoOcion>accion.jsp

Ejemplo
rpListarPedidos.jsp

Nota: Los jsp que son de uso general no llevarán el prefijo de opción.
ejemplo : Login.jsp , Error.jsp.

Página.18 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

4.11. Recomendaciones Generales de Programación

4.11.1.Recomendaciones de optimización

 Se recomienda usar el patrón singleton (solo una instancia para toda la aplicación) para clases utilitarias
comunes.(Es una buena opción para disminuir el número de variables de contexto).
 Minimizar el Uso de System.out.println ya que involucran procesos de I/O, utilizar log4j.
 Usar StringBuffer (Para concatenaciones grandes).
 Usar líneas de código de menos de 80 caracteres.

4.11.2. JDBC

La Estructura a emplearse en el caso se realicen las conexiones a Base de Datos será siempre la siguiente:

Connection conn = null;

PreparedStatement pst = null;
ResultSet rs = null;

Try
{
//Uso de JDBC
}
catch(Exception ex)
{
//Manejar excepción y hacer rollback
}
finally
{
//cerrar conexiones clase utilitaria
}

 Usar los conceptos de Datasource por JNDI y Pool de Conexiones usando las clases proporcionadas
por Oracle ya que están adaptadas a los productos del proveedor e implementan una mejor forma
(comprobada) de administrar las conexiones.

Página.19 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

 Como regla se deben liberar o cerrar siempre las conexiones u objetos de jdbc, para esto se utilizará
una clase utilitaria dedicada al cierre de conexiones y a la liberación de las conexiones para la
administración del Pool de Conexiones, Statements, PreparedStatements y Resultset etc.

 Las conexiones a base de datos deben ser hechas en las clases de control (servlets) y esta debe ser la
responsable de asignarla a las clases que necesiten hacer operaciones a base de datos así como de
cerrar o liberar dicha conexión.

4.11.3. Excepciones
 Toda excepción debe ser controlada inclusive si se advierten excepciones del tipo Runtime.

 Las Excepciones se deben manejar generalmente en las clases de control (Ejemplo Servlets), ya que
estas son las clases que manejan el flujo de la aplicación.

 Se debe enviar a consola un mensaje de la excepción () además de controlar siempre que el flujo de la
aplicación continúe (redirección a páginas de error).

 No se debe usar la impresión del Stack Trace (esta se usa solo para el momento del debug)

 Toda página jsp debe tener una página de error.

Página.20 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

4.11.4.JSP

 Usar nombres estándar para objetos frecuentemente usados en jsp (session,request,response).

 Minimizar el Uso de objetos de sesión (si se usarán, removerlos al final de la operación con estos).

 En cuanto al uso de Forward y Redirect (Se recomienda el uso de Forward ya que este no crea un
nuevo objeto request).

 Usar paginas de Error (Se contará con al menos una pagina de error por funcionalidad)

 Usar Tags Personalizados para tareas comunes y repetitivas (ejem: para mostrar listas).

Librerías de etiquetas (TagLibs) de soporte para la construcción de JSPs

El Framework Struts proporciona librerías de etiquetas (TagLibs) que contiene lógica reutilizable que
facilita la construcción de páginas JSPs, además el uso de tagLibs reduce la inclusión de código
java dentro de las páginas JSP.

El desarrollador puede aplicar estos taglibs en los JSPs; pero también puede aplicar código java en
aquellos casos en los que usar un tagLib sea insuficiente o represente una complicación mayor a la
inclusión de código java. En la construcción de páginas JSP se pretende minimizar la inclusión de
código java, no eliminarlo por completo.

Comentarios
Dentro de los archivos JSP, los comentarios deben ser agregados usando la sintaxis JSP "<%--" y
no la sintanxis HTML"<%--".

Ejemplo de comentario correcto:

<%-- Este es un comentario correcto y que no se verá en el lado del cliente--%>

Ejemplo de comentario incorrecto:

<!-- Este es un comentario incorrecto y que se verá en el lado del cliente -->

Página.21 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Soporte para acentuación

Toda página web JSP debe empezar con la siguiente línea, para evitar la necesidad de colocar
acentos con el tag "accute":

<%@ page contentType="text/html;charset=ISO-8859-1"%>

Nombramiento de objetos HTML

La siguiente tabla indica los prefijos a utilizar para nombrar objetos HTML a utilizar dentro de las
páginas JSP

Objeto Prefijo Ejemplos

Formulario frm frmAbono
Caja texto y TEXT txt txtFecha
AREA txtNombre
Caja texto oculta hid hidCadena
Combo box cmb cmbDia
cmbMes
cmbAno
Lista list listSecciones
Check Box chk chkSiNo
Botón btn btnAceptar
Radio Button rad radEstado

Página.22 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

5. ESTANDARES DE SEGURIDAD

A continuación se define los estándares de seguridad a emplearse:

5.1. Navegación Forzada 1: Acceso desde página principal

Definición
Consiste en saltar la verificación del Control de Acceso. Muchos sitios requieren que los usuarios pasen por
ciertas verificaciones antes de que se les garantice el acceso a ciertos URLs que están típicamente
colocados ‘más profundamente’ en el sitio. Estas verificaciones no deben ser evitadas por un usuario que
simplemente se salta la página que contiene la verificación de seguridad.

Vulnerabilidad
URL “ocultas” o “especiales”, suministradas sólo a administradores o usuarios con privilegios, pero
accesibles a todos los usuarios si ellos saben que existen, tales como
/administrar/agregarusuario.php/aprobarTransferencia.do.

Estándar
Todas las aplicaciones Web, deben ser accedidas desde una pagina principal y enmascarar el URL, y el
Browser donde se cargara el sistema debe ser estar maximizado y no contar con menús, ni botones de
navegación. Para tal efecto se debe utilizar la siguiente función Java Script:
// función para abrir ventana maximizada
function abreventanaMax( aURL, aWinName )
{
var wOpen;
var sOptions;

sOptions = 'directories=no,status=yes,toolbar=no,menubar=no,scrollbars=yes';
sOptions = sOptions + ',resizable=yes,location=no,maximize=yes';
sOptions = sOptions + ',width=' + (screen.availWidth - 12).toString();
sOptions = sOptions + ',height=' + (screen.availHeight - 122).toString();
sOptions = sOptions + ',screenX=0,screenY=0,left=0,top=0';

wOpen = window.open( '', aWinName, sOptions );

wOpen.location = aURL;
wOpen.focus();
wOpen.moveTo( 0, 0 );
wOpen.resizeTo( screen.availWidth, screen.availHeight );
return wOpen;
}

aURL: Dirección electrónica de la pagina que se desea abrir

aWinName: Nombre de la ventana

5.2. Navegación Forzada 2: Ver código fuente

Definición

Página.23 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Consiste en saltar la verificación del Control de Acceso. Muchos sitios requieren que los usuarios pasen por
ciertas verificaciones antes de que se les garantice el acceso a ciertos URLs que están típicamente
colocados ‘más profundamente’ en el sitio. Estas verificaciones no deben ser evitadas por un usuario que
simplemente se salta la página que contiene la verificación de seguridad.

Vulnerabilidad
URL “ocultas” o “especiales”, suministradas sólo a administradores o usuarios con privilegios, pero
accesibles a todos los usuarios si ellos saben que existen, tales como
/administrar/agregarusuario.php/aprobarTransferencia.do.

Estándar

Evitar el acceso a poder ver el código fuente de las pagina html del sistema. Para ello, se debe bloquear el
botón secundario de Mouse, para tal efecto se debe utilizar la siguiente funcion Java Script, dentro del
cuerpo de la pagina html (body):

<html>
<head>
<title>Pagina Web</title>
<body>
<SCRIPT language=JavaScript>
function click()
{
if(event.button==2){
alert(' HERMES TRANSPORTES BLINDADOS);
}
}
document.onmousedown=click
</SCRIPT>
</body>
</html>
aMessage: mensaje que se mostrara cuando se presione el botón derecho del Mouse sobre la
pagina html.

Se debe bloquear las teclas de shortcut que vienen por defecto en la mayoría de los browser, dado que
estas permiten abrir el sistema en un nuevo browser que cuenta con los menús y botones de navegación:
ctrl + U, el uso de la combinación Shif + “Clic izquierdo” , el uso de la tecla F11. Considerar que los
shortcut, varían dependiendo del navegador y del idioma del mismo:

Abrir una nueva ventana

Mozilla Firebird: Ctrl+N
Internet Explorer: Ctrl+U
Opera: Ctrl+N
Pantalla completa
Mozilla Firebird: F11
Internet Explorer: F11
Opera: F11
Código Fuente
Mozilla Firebird: Ctrl+U
Internet Explorer: Clic derecho
Opera: Ctrl+F3

Página.24 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Para suprimir las teclas Control, para tal efecto utilizar el siguiente java script:
<html>
<head>
<script language="JavaScript">
function salir(evt)
{
if(evt.keyCode == 17 || evt.keyCode == 122)
{
alert("HERMES TRANSPORTES BLINDADOS");
if (evt.keyCode == 122) {
document.location='ruta de la pagina de acceso restringido';
}
return 0; //false;
}
}
</script>
</head>
<body onKeyDown="salir(event)" onKeyUp="salir(event);">
Pulsa el boton control.
</body>
</html>

Suprimir la combinación Shif + “Clic izquierdo”.

Reemplazar el uso del link html (<A href=''direccionWeb'' > Enlace </A>) por Java Script que redirecciones las paginas, tales
como:

<A href='#' onClick="document.location='direccionWeb'"> Enlace </A>

Observación: Los Java script de validación y restricción de usos de teclas deben estar incorporadas en un archivo tipo
liberaría para ser reutilizados por todas las paginas del sistema: por ejemplo “LibreriasJS.js”

5.3. Navegación Forzada 3: Acceso a archivos ocultos

Definición
La Navegación Forzada consiste en saltar la verificación del Control de Acceso. Muchos sitios requieren que
los usuarios pasen por ciertas verificaciones antes de que se les garantice el acceso a ciertos URLs que
están típicamente colocados ‘más profundamente’ en el sitio. Estas verificaciones no deben ser evitadas por
un usuario que simplemente se salta la página que contiene la verificación de seguridad.

Vulnerabilidad
Las aplicaciones a menudo permiten el acceso a archivos “ocultos”, tales como XML estáticos o reportes
generados por el sistema, confiando en la seguridad por oscuridad para ocultarlos.

Estándar
o Configuración del lado del servidor OAS

JESUS CAÑARI LO DEBE DEFINIR

PUBLICAR SOLO
HTM,

Página.25 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

HTML
GRAFICOS (GIFTS, JPGS)
DOCUM,ENTOS PDF, DOC, XLS, TXT
JSP

5.4. Navegación Forzada 4: Control de Acceso no validado

Definición
La Navegación Forzada consiste en saltar la verificación del Control de Acceso. Muchos sitios requieren que
los usuarios pasen por ciertas verificaciones antes de que se les garantice el acceso a ciertos URLs que
están típicamente colocados ‘más profundamente’ en el sitio. Estas verificaciones no deben ser evitadas por
un usuario que simplemente se salta la página que contiene la verificación de seguridad.

Vulnerabilidad
Código que implementa una política de control de acceso no actualizado o insuficiente. Por ejemplo,
imagine /aprobarTransferencia.do que alguna vez estuvo disponible para todos los usuarios, pero ahora se
solo está disponible a los ‘aprobadores’.

Estándar
o Implementar la validación del acceso por perfil de usuario, para cada acción que se realice en el
aplicativo.
Esta validación debe estar incluida como parte de las librerías de seguridad (actualmente está
incorporado en la clase “Util”) que se utilizara para todos los aplicativos Web, y debe ser llamado desde
todos los archivos que gestionan el flujo de la aplicación(Action), se describe un ejemplo del uso de la
librería :

if (request.getSession().getAttribute("usuario") == null)
response.sendRedirect("../hermetic/sessionFinish.jsp");

HttpSession session = request.getSession(false);

//valido si el perfil logeado tiene acceso a la opcion
List listaTransacciones = (List)session.getAttribute("listaMenu1");
if (!Util.validaAccesoOpcion(listaTransacciones,
ConstantesHermetic.TRANS_REGISTRO_DE_PEDIDOS)
){
return mapping.findForward("noAutorizado");

5.5. Navegación Forzada 5: Evaluación de privilegios en servidor

Definición

Página.26 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

La Navegación Forzada consiste en saltar la verificación del Control de Acceso. Muchos sitios requieren que
los usuarios pasen por ciertas verificaciones antes de que se les garantice el acceso a ciertos URLs que
están típicamente colocados ‘más profundamente’ en el sitio. Estas verificaciones no deben ser evitadas por
un usuario que simplemente se salta la página que contiene la verificación de seguridad.

Vulnerabilidad
Código que evalúa privilegios en el cliente pero no en el servidor.

Estándar
o Las aplicaciones deben considerar dos niveles de validación.

Validación a nivel de cliente(JavaScript)

Se debe incorporar en todas las aplicaciones Web validaciones JavaScript , para aquellos casos en que
no sea necesario llegar hasta el servidor de aplicaciones(OAS).

 Autenticación de usuario
Verificación del tamaño y/o formato ingresado para la cuenta de usuario
Verificación del tamaño y/o formato ingresado para el la contraseña de usuario(Evaluar si aplica
por medidas de seguridad)

 En toda la aplicación:
Las validaciones que se realicen, deben utilizar en la medida que se pueda LÓGICA DE
PREDICADO (REVISAR y DOCUMENTAR) para los JavaEscript.
Se debe minimizar la incorporación de lógica de procesos o transaccional en los JavaScript.

Validación a nivel del servidor(Java)

En este apartado se debe incorporar todas las validaciones que no se pueden realizar sin interactuar con la
base de datos o algún proceso complejo que no se pueda ejecutar del lado del cliente (En java script), por
seguridad o funcionalidad.

5.6. Navegación Forzada 6: Tres niveles de validación por perfil

Definición
La Navegación Forzada consiste en saltar la verificación del Control de Acceso. Muchos sitios requieren que
los usuarios pasen por ciertas verificaciones antes de que se les garantice el acceso a ciertos URLs que
están típicamente colocados ‘más profundamente’ en el sitio. Estas verificaciones no deben ser evitadas por
un usuario que simplemente se salta la página que contiene la verificación de seguridad.

Página.27 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Vulnerabilidad
creando una matriz para definir los roles y las funciones de la aplicación es un paso clave en el logro de la
protección contra las fallas de restricción de acceso a URL.

Estándar
Utilizar el componente de seguridad para aplicaciones Web Java.

NUEVO SISTEMA DE SEGURIDAD DEBE CONTEMPLAR TRES NIVELES DE VALIDACION POR

PERFIL

5.7. Navegación Forzada 7: JSP fuera del directorio raíz

Definición
La Navegación Forzada consiste en saltar la verificación del Control de Acceso. Muchos sitios requieren que
los usuarios pasen por ciertas verificaciones antes de que se les garantice el acceso a ciertos URLs que
están típicamente colocados ‘más profundamente’ en el sitio. Estas verificaciones no deben ser evitadas por
un usuario que simplemente se salta la página que contiene la verificación de seguridad.

Vulnerabilidad
Los archivos de librerías, especialmente si tienen una extensión ejecutable tal como .jsp, cuando sea
posible, deben mantenerse fuera del directorio raíz de la Web. Se debe verificar que no están siendo
accedidas directamente, por ejemplo, revisando una constante que solo puede ser creada por el llamante de
la biblioteca.

Estándar
Mantener las librerías ejecutables (TRANSACCIONALES) fuera del directorio raíz web, por ende fuera del
archivo War de despliegue. En la medida que se pueda no debe publicarse (validar factibilidad).

- DIVIDIR CONTENIDO ESTATICO (SERVIDOR WEB) DE PAGINAS DINAMICAS (OAS). JESUS CAÑARI
(VALIDAR)

5.8. Navegación Forzada 8: Bloqueo de Tipos de archivo

Definición
La Navegación Forzada consiste en saltar la verificación del Control de Acceso. Muchos sitios requieren que
los usuarios pasen por ciertas verificaciones antes de que se les garantice el acceso a ciertos URLs que
están típicamente colocados ‘más profundamente’ en el sitio. Estas verificaciones no deben ser evitadas por
un usuario que simplemente se salta la página que contiene la verificación de seguridad.

Página.28 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Vulnerabilidad
Bloquear el acceso a todos los tipos de archivo que su aplicación no deberá servir nunca. Lo ideal sería que
este filtro siga el método “aceptar buenos conocidos” y sólo permita tipos de archivos que usted tiene la
intención de servir, por ejemplo .html, .pdf, .php. Esto bloqueara cualquier intento de acceder archivos de
bitácora, archivo XML, etc., que nunca tuvo la intención de servir directamente.

Estándar
Configurar en el servidor de aplicaciones (OAS), que los documentos publicados, solo contemple aquellos
archivos que deben ser accedidos por los usuarios.

5.9. Inserción de Comandos: SQL Injection

Definición
Las fallas de inyección permiten a los atacantes transmitir código malicioso a otro sistema a través de una
aplicación Web. Estos ataques incluyen:
- Llamadas al sistema operativo mediante llamadas al sistema,
- El uso de programas externos vía interfaces de comando
- Y también llamadas a servidores de soporte de bases de datos mediante SQL

La finalidad del ataque es realizar tareas sobre la base de datos y de ser posible sobre host mismo,
teniendo resultados que van desde la alteración de un dato hasta apoderarse del servidor.

Vulnerabilidad
Mandar instrucciones SQL adicionales a partir de un campo o un parámetro de entrada.

Estándar
o La aplicación debe llamar al procedimiento que se encuentra en el motor de bases de datos
(STORE PROCEDURES). No se debe armar la consulta en la aplicación. La utilización de
Prepared Statements hace referencia a un tipo de consultas SQL que no se ejecutan concatenando
cadenas de caracteres.
o Manejo de variables por parámetros.
o Ejecutar las sentencias SQL o invocar Procedimientos Almacenados con una cuenta con privilegios
mínimos. Nunca emplear una cuenta con privilegios de administrador, a menos que sea inevitable.
o Conceder permisos de ejecución únicamente a Objetos de base de datos (ej: Procedimientos
Almacenados) propios desde los cuales, a manera de "wraper", se realicen las consultas a las
tablas de Usuario y llamados a los Procedimientos Almacenados del Sistema que se requieran en
las aplicaciones, y negar el acceso directo a éstos últimos y a las Tablas de Usuario.

Página.29 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

VALIDAR CONTRA EL FRAMEWORK ELEGIDO

OracleCallableStatement stmt = (OracleCallableStatement)
connection.prepareCall("{ call miProcedimientoAlmacenado
(?,?,?,?) }");
stmt.registerOutParameter(4,OracleTypes.ARRAY,"
miProcedimientoAlmacenado ");
stmt.setString(1,valorParametro1);
stmt.setString(2, valorParametro2);
stmt.setString(3, valorParametro3);
stmt.execute();

o No proporcionar mayor información de la necesaria. No exponer al usuario final los mensajes de

error devueltos por el gestor de la base de datos, para no brindar mayor información que sea útil al
atacante.
Utilizar el estándar de manejo inadecuado de errores, de este mismo documento SECCION XXXX.
Evaluar la creación CATALOGO DE ERRORES
Adicionalmente al manejo de errores, debe incorporase un Catálogo de mensajes de error
personalizados. Se describe el procedimiento para su creación:
1. Si sustituye las entradas del catálogo predeterminado, sitúe las claves de los mensajes de error
adecuadas en el archivo WPMessages.properties. Estas claves se deben especificar en el catálogo
de mensajes personalizados.
Si crea mensajes nuevos, asegúrese de que las claves no aparezcan en el archivo
WPMessages.properties.

2. Cree un archivo o bloque XML con la estructura siguiente:

<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE Configuration PUBLIC 'waveset.dtd' 'waveset.dtd'>

<Configuration name='CatalogName'>
<Extension>
<CustomCatalog id='CatalogName' enabled='true'>
<MessageSet language='en' country='US'>
<Msg id='KeyName'>MessageText</Msg>
<Msg id='KeyName'>MessageText</Msg>
...
</MessageSet>
</CustomCatalog>
</Extension>
</Configuration>

Página.30 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

donde:
CatalogName corresponde al nombre del catálogo de mensajes de error. Este valor también sirve para
definir el catálogo en el objeto SystemConfiguration.
KeyName es el nombre de la clave de mensaje.
MessageText es una cadena que se muestra en la interfaz gráfica de usuario. Este texto puede
contener etiquetas HTML y variables.
Las entradas del nuevo catálogo de mensajes debe configurarse para estar disponibles en el sistema.

5.10. Cross Site Scripting 1: Inyección de código incrustado

Definición
Trata sobre las entradas que contiene pequeños programas para ser ejecutados en el navegador de otros
usuarios, es decir el ataque está basado en la explotación de vulnerabilidades del sistema de validación de
HTML incrustado. Esta vulnerabilidad puede estar presente de forma directa (foros, mensajes de error) o
indirecta (redirecciones, framesets).
Ejemplo:
<%
out.println( "Hay " + cantidad + "de resultados encontrados con su búsqueda " + request.getParameter ("parametro") );
%>
cuando se realice la búsqueda del termino <script>alert(“xss”)</script>", una vez haya cargado la página nos aparecerá una
ventana de alerta diciendo “xss” en vez de mostrarnos el texto tal cual lo escribimos. Esto se debe a que no filtramos los datos
introducidos por el usuario.

Vulnerabilidad
El atacante desea inyectar código de Java Script incrustado.

Estándar
Se debe aplicar la siguiente función a fin de validar el ingreso de caracteres especiales, en aquellos lugares
donde no se espera ningún carácter especial, tales como: < > ( ) # &. Para tal efecto se debe utilizar la
función:
AFINAR FUNCIONES
limpiarSQLInjectionBusqueda que se encuentra en la clase com.pe.hermes.hermetic.web.util

5.11. Cross Site Scripting 2: Ejecución de código inyectado almacenado

Definición
Trata sobre las entradas que contiene pequeños programas para ser ejecutados en el navegador de otros
usuarios, es decir el ataque está basado en la explotación de vulnerabilidades del sistema de validación de

Página.31 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

HTML incrustado. Esta vulnerabilidad puede estar presente de forma directa (foros, mensajes de error) o
indirecta (redirecciones, framesets).
Ejemplo:
<%
out.println( "Hay " + cantidad + "de resultados encontrados con su búsqueda " + request.getParameter ("parametro") );
%>
cuando se realice la búsqueda del termino <script>alert(“xss”)</script>", una vez haya cargado la página nos aparecerá una
ventana de alerta diciendo “xss” en vez de mostrarnos el texto tal cual lo escribimos. Esto se debe a que no filtramos los datos
introducidos por el usuario.

Vulnerabilidad
El código inyectado es permanentemente almacenado en el servidor objetivo.

Estándar
Para evitar la ejecución del código JavaScript que ya se encuentra en la base de datos, se debe manejar la
salida codificada para MITIGAR las vulnerabilidades XSS evitando que scripts insertados sean transmitidos
a los usuarios en una forma ejecutable. En todas las salidas generadas, se debe convertir los caracteres
especiales a su codificación HTML apropiada. Para tal efecto se debe utilizar la función:

AFINAR DESCRIPCION DE ESTÁNDAR CREAR FUNCION

LimpiarXSS que se encuentra en la clase com.pe.hermes.hermetic.web.util.

5.12. Control de Acceso Interrumpido

Definición
Esto ocurre cuando una aplicación Web permite el acceso a contenido y funciones a algunos usuarios y a
otros no, debido a que estas verificaciones son desarrolladas después de la autenticación, y aplica sobre las
acciones que pueden realizar los usuarios “autorizados”

Vulnerabilidad
Las características por validar que se presentan en las aplicaciones web son las siguientes:
o El usuario puede visualizar el contenido no autorizado, puede crear, alterar o borrar contenido de
otro perfil.
o El usuario puede realizar funciones no autorizadas, como acceder a la administración del aplicativo
web.
o Las interfases a las cuales solamente los administradores autorizados tienen el acceso permitido.

Estándar

Página.32 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Implementar la validación del acceso de la acción por perfil del usuario logeado al aplicativo Web.

o Crear una matriz de Perfil vs Opciones (Acción) usado como entrada para realizar la validación de
las acciones por opción correspondiente a la opción por perfil del usuario (ver Tabla).
o El código que implementa la política de control de acceso debe estar bien estructurado, ser modular
y centralizado, la validación de acceso se debe implementar en los objetos Action y JSPs del
aplicativo web) (ver código).
o Incluir cabeceras HTTP y meta etiquetas (“meta tags”), para asegurar que las páginas que
contienen información sensitiva no sean capturadas en caché por el navegador del usuario.

Matriz Perfil vs Opción (Acción):

Código Opciones Acción Perfil 01 Perfil 02
(Consulta) (Transacción) … Perfil N

01 Opcion01 Consultar X X X
01 Opcion01 Eliminar X X
01 Opcion01 Crear X
01 Opcion01 Modificar X
02 Opcion02 Consultar X X X
02 Opcion02 Eliminar X
02 Opcion02 Crear X
02 Opcion02 Modificar X X
03 Opcion03 Consultar X X
03 Opcion03 Eliminar X
03 Opcion03 Crear X
03 Opcion03 Modificar X

Modo de empleo:

En la sesión del proyecto Web se almacena en el momento de logeo el listado “listadoAcceso”, el cual
posee el total de acciones por opciones asignado al perfil del usuario:

Por ejemplo aquí se muestra la carga de acciones de las opciones para el Perfil N, puede “consultar”,
“eliminar” sobre la opcion01 y “Consultar” y “Modificar” sobre la opción02.
//acciones de la opcion01
List listadoAcceso = new ArrayList();
ModuloUsuarioBean moduloUsuarioBean = new ModuloUsuarioBean();
moduloUsuarioBean.setCodigo(“01”);
moduloUsuarioBean.setAccion(“Consultar”,”Eliminar”);
listadoAcceso.add(moduloUsuarioBean);

//acciones de la opcion02
moduloUsuarioBean = new ModuloUsuarioBean();
moduloUsuarioBean.setCodigo(“02”);
moduloUsuarioBean.setAccion(“Consultar”,”Modificar”);
listadoAcceso.add(moduloUsuarioBean);

session.setAttribute(“listadoAcceso”, listadoAcceso);

El código de validación de la acción por opción, se debe incluir en cada Clase tipo Action (Usar la librería hermesUtil, usar el método
validaAccesoTercerNivel).

HttpSession session = request.getSession(false);

//valido si el perfil logeado tiene acceso a la opcion y accion

Página.33 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

List listadoAcceso = (List)session.getAttribute("listadoAcceso");

if (!Util.validaAccesoOpcion(listadoAcceso, ConstantesApp.OPCION01, ConstantesApp. ACCION_CONSULTAR)){
return mapping.findForward("noAutorizado");
}

Código de la Clase ConstantesApp, donde se define el nombre o código de la opción.

public class ConstantesHermetic {
//Constantes de Opcion
public static final String OPCION01 = "01";
//Constantes de Accion
public static final String ACCION_CONSULTAR = "Consultar";
public static final String ACCION_ELIMINAR = "Eliminar";
public static final String ACCION_CREAR = "Crear";
public static final String ACCION_MODIFCAR = "Modificar";
}

Usar la librería hermesUtil.jar, el cual posee la Clase HermesValidaAcceso con el método que realiza la validación de tercer Nivel
(accion por opcion del perfil).

public static boolean validaAccesoOpcion(List listadoMenu, String codOpcion, String accion){

boolean resultado = false;
int total = listadoMenu.size();

if (total > 0){

ModuloUsuarioBean modulo = null;// new ModuloUsuarioBean();
for (int idx=0; idx<total ;idx++){
modulo = (ModuloUsuarioBean)listadoMenu.get(idx);
if (modulo.getCod().equals(codOpcion) && modulo.getAccion().equals(accion)){
resultado = true;
}
}
}
return resultado;
}

Incluir en el JSP el metatag, para no almacenar la página el área de cache del explorador.
<meta http-equiv="expires" content="-1" >
Incluir el metatag Pragma con el valor “no-cache”, este no utiliza la caché del explorador para guardar la
página.
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

5.13. Administración de Autenticación y Sesión Interrumpida

Definición
La administración de autenticación y sesión incluye todos los aspectos del manejo de la autenticación de
usuario y la administración de sesiones activas. La autenticación es un aspecto crítico de este proceso,
pero inclusive mecanismos de autenticación sólidos pueden ser minados por funciones de administración de
credenciales defectuosas, incluyendo el cambio de contraseña, olvidé mi contraseña, recordar mi
contraseña, actualización de cuenta y otras funciones relacionadas. Porque los ataques de paso (“walk by”)
son probablemente dirigidos a muchas aplicaciones Web, todas las funciones de administración de cuentas
deben requerir re-autenticación aun si el usuario tiene un id de sesión válido.

Página.34 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Vulnerabilidad
Las características por validar en las aplicaciones web son las siguientes:

o Verifique los mecanismos de autenticación para asegurar que las credenciales de usuario están
protegidas en todo momento (almacenadas, en transito, durante el login).

Estándar
Implementar la validación del la administración de forma segura las credenciales de los usuarios (Se usara
como estándar para el desarrollo del proyecto de Seguridad).

- Contraseñas Resistentes: las contraseñas deben tener restricciones que impongan un tamaño y
complejidad mínima. La complejidad típicamente requiere el uso de combinaciones mínimas de
caracteres alfabéticos, numéricos, y/o no-alfanuméricos en la contraseña de usuario. A los usuarios
se les debe requerir cambiar su contraseña periódicamente. A los usuarios se les debe impedir re-
utilizar contraseñas anteriores.

- Uso de contraseñas: se debe restringir a los usuarios a un número definido de intentos de

conexión por unidad de tiempo y los repetidos intentos de conexión fallidos deben ser registrados.
Las contraseñas provistas durante los intentos fallidos de conexión no deben ser almacenados ya
que esto puede exponer una contraseña de usuario a cualquiera que logre acceder a este registro.
El sistema no debe indicar si fue el nombre de usuario o la contraseña lo que estaba equivocado si
falla un intento de conexión. Los usuarios deben ser informados de la fecha/hora de su última
conexión exitosa y el número de intentos de acceso fallidos a su cuenta desde esa hora.

- Control de Cambios de Contraseña: un solo mecanismo de cambio de contraseña debe ser

usado donde sea que se permita cambiar a los usuarios su contraseña, independientemente de la
situación. A los usuarios siempre se les debe solicitar el ingresar ambas contraseñas, la anterior y la
actual, cuando cambian su contraseña (como todas las cuentas informáticas). Si las contraseñas
olvidadas son enviadas por correo electrónico a los usuarios, el sistema debe requerir del usuario
que se re-autentifique cuantas veces el usuario cambie su dirección de correo electrónico, de lo
contrario un atacante que ha tenido acceso temporalmente a su sesión (Ej., acercándose a su
computadora mientras está conectado) puede simplemente cambiar su dirección de correo
electrónico y solicitar que una contraseña ‘olvidada’ les sea enviada vía correo electrónico

- Almacenamiento de Contraseña: todas las contraseñas deben ser almacenadas ya sea de forma
encriptada o como hashes para protegerlas de ser expuestas, independientemente de donde son
almacenados. La forma de hash es preferible ya que no es reversible. La encriptación debe ser
usada cuando se necesita la contraseña en texto llano, tal como cuando se utiliza la contraseña
para conectarse a otro sistema. Las contraseñas nunca deben ser insertadas directamente en el
código fuente. Las llaves de descifrado deben ser protegidas fuertemente para asegurar que no
puedan ser arrebatadas y usadas para descifrar el archivo de contraseñas

- Protegiendo Credenciales en Tránsito: la única técnica efectiva es encriptar completamente la

transacción de acceso al sistema es usando algo como SSL. Las transformaciones sencillas de las
contraseñas tales como aplicar un hash en el cliente antes de la transmisión provee poca protección
ya que la versión cifrada puede simplemente ser interceptada y retransmitida aunque la contraseña
en texto llano no pueda ser conocida

Página.35 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

- Protección del Id de Sesión: idealmente, toda la sesión de usuario debe ser protegida mediante
SSL. Si esto es hecho, entonces el id de sesión (Ej., cookie de sesión) no puede ser tomado de la
red, lo cual es el mayor riesgo de exposición de un id de sesión. Si no es viable el uso de SSL por el
desempeño u otras razones, entonces los id’s de sesión deben ser protegidos de alguna otra forma.
En primera instancia, éstos nunca deben ser incluidos en el URL ya que pueden ser capturados en
memoria rápida (“cached”) por el navegador, mandados en la cabecera referenciada o
accidentalmente re-enviados a un ‘amigo’. Los id’s de sesión deben ser números largos,
complicados y aleatorios que no puedan ser fácilmente adivinados. Los id’s de sesión pueden
también ser cambiados frecuentemente durante una sesión para reducir el tiempo en que es válido
un id de sesión. Los id’s de sesión deben ser cambiados cuando se cambia a SSL, se autentifica u
ocurre otra transacción importante. Los id’s de sesión escogidos por un usuario nunca deben ser
aceptados

- Listas de cuentas: los sistemas deben ser diseñados para evitar que los usuarios logren acceso a
una lista de los nombres de cuentas del sitio. Si las listas de usuarios deben ser mostradas, es
recomendable que alguna forma de pseudónimo (“screen name”) que corresponda a la cuenta
actual sea listada en su lugar. De esa forma el pseudónimo no puede ser usado durante un intento
de conexión o algún otro intento de obtener la cuenta de usuario

- Memoria Rápida (“Cache”) del Navegador: los datos de autenticación y sesión nunca deben ser
suministrados como parte de un GET, en su lugar siempre debe ser utilizado POST. Las páginas de
autenticación deben ser marcadas con todas las diversidades de etiquetas de no uso de memoria
rápida para prevenir que alguien use el botón de retorno en el navegador del usuario para copiar la
página de conexión y re-transmitir las credenciales previamente tecleadas. Muchos navegadores de
hoy soportan la bandera (“flag”) de ‘autocomplete=false’ para prevenir el almacenamiento de
credenciales en la memoria rápida (“cache”) de auto completar

- Relación de Confianza: la arquitectura de su sitio debe evitar la confianza implícita entre

componentes siempre que sea posible. Cada componente debe autentificarse por sí mismo con
cualquier otro componente con el que esté interactuando, a menos que exista una fuerte razón para
no hacerlo (tal como el desempeño o la falta de un mecanismo utilizable). Si las relaciones de
confianza son requeridas, procedimientos sólidos y mecanismos arquitectónicos deben ser usados
para asegurar que no se puede abusar de tal confianza al evolucionar la arquitectura del sitio con el
tiempo

5.14. Manejo Inadecuado de Errores

Definición
El manejo inadecuado de errores puede introducir variados problemas de seguridad a un sitio Web. El error
mas común es cuando información detallada de mensajes error, como rastreos de pila, volcados de BD y
códigos de error son mostrados al usuario (un pirata informático). Estos mensajes revelan detalles de la
implementación que nunca deberían ser revelados.
Tales detalles pueden proveer a los piratas informáticos de pistas importantes sobre potenciales fallas en el
sitio y tales mensajes de error son también perturbadores para los usuarios normales.
Las aplicaciones Web frecuentemente generan condiciones de error durante su operación normal. Falta de
memoria, excepciones por punteros nulos, llamadas fallidas a sistema, BD no disponible, tiempo de espera
de red agotado y cientos de otras condiciones comunes pueden causar que los errores sean generados.

Página.36 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Estos errores deben ser manejados de acuerdo a un esquema bien pensado que provea al usuario de un
mensaje de error con sentido, información de diagnostico
para quienes mantienen el sitio, y ninguna información útil para un atacante.

Vulnerabilidad
Las características por validar en el Manejo Inadecuado de Errores en las aplicaciones web son las
siguientes:

o Generar los errores comunes como ingreso de información que este asociado a la entrada esperada
por ejm: monto, fecha, valores en blanco, rutas de archivos que no existen, etc
o Crear escenarios que no ocurren generalmente como: desconexión de la red, apagado de la base
de datos, usuarios incorrectos, deshabilitar permisos, etc.
o Los mensajes no deberán de revelar detalles de la implementación.

Estándar
La solución es implementar una Clase Java la cual especifica las Excepciones posbiles causadas por la
aplicación.

o La clase control de Excepciones, crear una estructura para el control de excepciones, se debe
implementar en las clases Action (Controladores).
o Los mensajes devueltos al usuario enmascaran los mensajes de Error, para no revelar la
información, BD, rutas, servidor, etc.

Clase de la cual heredan todas las demás excepciones.

package pe.com.hermes.exception
/* Clase de la cual heredan todas las demás excepciones*/
public class HTBException extends Exception {
static final long serialVersionUID = 1L;
private String msg="";
public HTBException(){
}
public HTBException(Exception e, String m){
super(m,e);
msg = m;
}
public HTBException(Exception e){
super(e);
}
public HTBException(String m){
super(m);
msg =m;
}
public String getMensaje(){
return msg;
}
}

Página.37 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Maneja las excepciones de la BDHTB

package pe.com.hermes.exception
/* Maneja las excepciones de la BDHTB*/
public class BDHTBException extends HTBException {
static final long serialVersionUID = 1L;
public BDHTBException(){
}
public BDHTBException(Exception e){
super(e);
}
public BDHTBException(String msg){
super(msg);
}
public BDHTBException(Exception e, String msg){
super(e,msg);
}

Definir en un archivo de propiedades los mensajes de excepción capturados y los que serán mostrados al
usuario.

Nr Acción de Error Mensaje

o
1 Error Genérico Problemas con el sistema. Comuníquese con TI-
Hermes.
2 Error de Base de Problemas de conectividad del sistema.
Datos Comuníquese con TI-Hermes.
3 Error de Credenciales Las credenciales ingresadas inválidas.
4 Error en el proceso Problemas en el proceso del Sistema.
Comuníquese con TI-Hermes.
5 Error de accion Problemas en el proceso (ACCION) del Sistema.
(Crear, Modificar, Comuníquese con TI-Hermes.
Eliminar)

5.15. Almacenamiento Inseguro

Definición
Muchas de las aplicaciones Web necesitan guardar información sensible, ya sea en una base de datos, en
un sistema de archivos o en algún lugar. La información podría ser contraseñas, números de tarjetas de
crédito, registros contables o información propietaria. Frecuentemente las técnicas de encriptación
(“encryption”) son usadas para proteger esta información sensible. Mientras que la encriptación se ha vuelto
relativamente fácil de implementar y usar, los desarrolladores frecuentemente comenten errores aun cuando

Página.38 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

la integran dentro de una aplicación Web. Los desarrolladores pueden sobreestimar la protección ganada
por el uso de la encriptación y no ser cuidadosos en asegurar otros aspectos del sitio.

Vulnerabilidad
Las características por validar en las aplicaciones web son las siguientes:

3. Almacenamiento inseguro de llaves, certificados y contraseñas en base de datos o archivos de texto.

4. Verificar los algoritmos de encriptación estándar elegido para los aplicativos web (incluido en este
documento).
5. Examinar, id’s de sesión, cookies y otras credenciales para ver si obviamente no son aleatorias.
6. Revisar el código para ver cómo están implementadas las funciones de encriptación.

Estándar
La solución es incluir en una la librería (JAR) la clase que especifica los métodos encriptación y
desencriptación de la aplicación web.

o La llave de encriptación debe encontrarse de forma divida y concatenarse en tiempo de ejecución.

o La librería usa el algoritmo de encriptación tripleDES.

La implementación de la librería de encriptación usando el algoritmo TripleDES.

Usar la Clase EncriptaTripleDES, método: encrypt

Se ingresará el key de encriptación por el responsable del Área de Seguridad de TI-Hermes antes de
compilar la librería.

5.16. Negación de Servicio

Definición
Muchas de las aplicaciones Web necesitan guardar información sensible, ya sea en una base de datos, en
un sistema de archivos o en algún lugar. La información podría ser contraseñas, números de tarjetas de
crédito, registros contables o información propietaria. Frecuentemente las técnicas de encriptación
(“encryption”) son usadas para proteger esta información sensible. Mientras que la encriptación se ha vuelto
relativamente fácil de implementar y usar, los desarrolladores frecuentemente comenten errores aun cuando
la integran dentro de una aplicación Web. Los desarrolladores pueden sobreestimar la protección ganada
por el uso de la encriptación y no ser cuidadosos en asegurar otros aspectos del sitio.

Página.39 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Vulnerabilidad
I1: Usuario inicia varios request sin concluir el anterior
Las características que presentan las aplicaciones web son las siguientes:

o Un atacante puede ser capaz de bloquear a un usuario legítimo enviando credenciales inválidas
hasta que el sistema bloquee la cuenta.
o El sistema bloquea alguno de los recursos de un usuario, entonces el atacante podría
potencialmente interrumpir el acceso a éstos de manera que otros no pudieran usarlo.
o Se presenta cuando el servidor Web se encuentra abajo por causa de un ataque
o Usar Herramientas de pruebas de carga como JMeter pueden generar tráfico Web de manera.
o Probar desde una sola dirección IP es útil pues le da una idea de cuántas peticiones puede un
atacante generar para dañar el aplicativo web.

Estándar
La solución es validar el flujo de ejecución en cada pantalla de la aplicación web.

o Considerar las configuración en OAS para deshabilitar la múltiple petición repetida para un usuario
desde un mismo IP Cliente, evitando así que pueda causar problemas en el servidor.
o Considerar la suspensión cualquier petición de un usuario que se esté procesando cuando llegue
otra petición de ese mismo usuario, restringir los botones mientras se encuentre un proceso en el
servidor.

Se debe realizar la validación de la variable en el formulario HTML

public class ContenidoForm extends ActionForm {
private String operacion = null;
}
En la clase Action enviar con valor Cero el parámetro operación
contenidoForm.setOperacion(“0”);

Al realizar una primera acción en la pantalla se debe marcar el parámetro operación con el valor Uno
(usando la funciont Javascript ejecutaAccion), al realizar una segunda acción y aun no termina la primera se
debe validar la operación usando la función validaOperacion, evitando así multiples llamadas a procesos por
un solo usuario.

function ejecutaAccion(){

Página.40 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

document.forms[0]. operacion.value= ‘1’

}
function validaOperacion(){
if (document.forms[0]. operacion.value== ‘1’){
alert(‘La ultima acción solicitada esta en proceso, espere un momento por favor..’);
}
}
<html:hidden property="operacion"/>

5.17. Administración de Configuración Insegura

Definición
El Servidor Web y el servidor de aplicación juegan un papel clave en la seguridad de una aplicación Web.
Estos servidores son responsables de servir el contenido y ejecutar aplicaciones que generan contenido.
Además, muchos servidores de aplicación proveen un número de servicios que los servidores Web pueden
usar, incluyendo almacenamiento de información, servicios de directorio, correo, mensajería y más. Fallar al
manejar la configuración apropiada de sus servidores puede llevar a una amplia variedad de problemas de
seguridad.

Vulnerabilidad
Las características por validar que presentan las aplicaciones web son las siguientes:

o Fallas de seguridad en el servidor o malas configuraciones que permiten ataques de listado de

directorio o atravesamiento de directorio.
o Innecesarios archivos por defecto, de respaldo o de ejemplo, incluyendo Scripts, aplicaciones,
archivos de configuración y páginas Web.
o Cuentas por defecto con contraseñas por defecto.
o Funciones administrativas o de depuración que son habilitadas o accesibles.
o Autenticación inadecuada con aplicaciones externas.

Estándar
La solución es seguir la política de depuración de los elementos innecesarios en el aplicativo web.

o Eliminar las Clases, JSPs, imágenes, scripts, estilos, librerías (jar), archivos de configuración que
no son usados.

Página.41 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

o Registro de todos los eventos y alertas que realizan los usuarios, implementar el Log por aplicativo
que sirve para depurar y encontrar los errores en tiempo de ejecución en producción. Usar la librería
de Apache (org.apache.log4j) el jar usado es: log4j.jar y el archivo de configuración log4j.xml

Ej. Uso del log org.apache.log4j

private Logger logger = Logger.getLogger(this.getClass());

logger.info("mensaje de Información");
logger.warn("mensaje de advertencia");
logger.error("mensaje de Error");

Archivo de configuración log4j.xml

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">

<!-- Parametros de Salida Log -->

<appender name="fileLog" class="org.apache.log4j.RollingFileAppender">
<param name="File" value="/oracle/soa/soa1/j2ee/home/application-deployments/hermetic/home_default_group_1/
aplication.log" />
<param name="Append" value="true" />
<param name="MaxFileSize" value="5000KB" />
<param name="MaxBackupIndex" value="1" />

<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%c] %m%n" />
</layout>
</appender>

<!-- ruta paquete a loggear-->

<logger name="pe.com.hermes ">
<level value="info"/>
<appender-ref ref="fileLog"/>
</logger>

<!-- nivel del log TRACE / DEBUG / INFO / WARN / ERROR / FATAL-->
<root>
<level value="debug" />
<appender-ref ref="fileLog" />
</root>

</log4j:configuration>

Página.42 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

6. DEFINICION DE HERRAMIENTAS DE DESARROLLO

El ambiente de trabajo del desarrollador debe contemplar el software siguiente

Jdeveloper Studio Edition 10g versión 10.1.0.3.4

Las características del computador recomendado para el ambiente de desarrollo es el siguiente:

- Requisitos de Hardware.
1. PC Pentium Dual Core 2.0GHz o Superior.
2. Memoria RAM 2GB como mínimo, se recomienda 4GB.
3. Lector CD, DVD ROM
4. Tarjeta de Red.

- Requisitos de Software.
1. Windows XP Professional Service Pack 2.
2. Internet Explorer 6 o superior.
3. Java jdk 1.5.0

Configuración de DataSource en Jdeveloper 10g.

Página.43 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Página.44 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Configuración del Pool de conexiones para la aplicación web.

Los datos necesarios para la configuración del pool de conexiones son los siguientes:

Clase: oracle.jdbc.pool.OracleDataSource
Usuario: usuario de base de datos
Clave: clave del usuario de base de datos
Login Timeout: tiempo de espera en el login
URL: La cadena de conexión esta compuesto por el IP del servidor de base de datos y nombre de la
base de datos.
jdbc:oracle:thin:@89.135.1.64:1521:htbp.

Página.45 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Configuración del DataSource de la aplicación web.

Crear una nueva conexión de datasource, el nombre usa el sufijo DS.

Página.46 de 47
Estándares de Diseño y Programación en Java
Nombre del documento Código Fecha versión
MANUAL DE ESTANDARES DE DISEÑO Y
14/12/2009 2.0
PROGRAMACION EN JAVA
Revisado por: Aprobado por:

CONSULTOR DE CALIDAD GERENTE DE TECNOLOGIA DE INFORMACION

Completamos la configuración agregando el nombre del pool de conexiones, el JNDI es el nombre de

publicación, el cual será usado en la aplicación.

Página.47 de 47
Estándares de Diseño y Programación en Java