2016 - 2022 - gobierno del estado de oaxaca

Lineamientos para el desarrollo de

Sistemas Web de la Administración

Pública Estatal

2016 - 2022


Sistemas Web de la APE 2016-2022

pág. 2

• PRESENTACIÓN ................................................................................................................. 4

• JUSTIFICACIÓN .................................................................................................................. 5

• GESTIÓN DE PROYECTOS ................................................................................................ 6

• LENGUAJES DE PROGRAMACIÓN ................................................................................... 6

• INFRAESTRUCTURA .......................................................................................................... 7

SERVIDORES DE APLICACIÓN .................................................................................................. 7

• SEGURIDAD ........................................................................................................................ 7

ARQUITECTURA, DISEÑO Y MODELADO DE AMENAZAS ............................................................... 8

REQUISITOS DE VERIFICACIÓN DE AUTENTICACIÓN ................................................................... 9

REQUISITOS DE VERIFICACIÓN DE GESTIÓN DE SESIONES ........................................................13

REQUISITOS DE VERIFICACIÓN DEL CONTROL DE ACCESOS ......................................................15

REQUISITOS DE VERIFICACIÓN PARA MANEJO DE ENTRADA DE DATOS MALICIOSOS ....................16

REQUISITOS DE VERIFICACIÓN DE GESTIÓN Y REGISTRO DE ERRORES ......................................19

REQUISITOS DE VERIFICACIÓN DE PROTECCIÓN DE DATOS ......................................................20

REQUISITOS DE VERIFICACIÓN DE CONFIGURACIÓN DE SEGURIDAD HTTP ................................22

REQUISITOS DE VERIFICACIÓN PARA CONTROLES MALICIOSOS .................................................23

REQUISITOS DE VERIFICACIÓN PARA LÓGICA DE NEGOCIOS .....................................................24

REQUISITOS DE VERIFICACIÓN DE ARCHIVOS Y RECURSOS ......................................................24

REQUISITOS DE VERIFICACIÓN MÓVIL .....................................................................................25

REQUISITOS DE VERIFICACIÓN DE SERVICIOS WEB ..................................................................26

REQUISITOS DE CONFIGURACIÓN ...........................................................................................28

• REQUISITOS DE LIBERACIÓN ..........................................................................................29

• NORMAS DE DESARROLLO .............................................................................................30

MVC ...................................................................................................................................30

NORMAS DE PROGRAMACIÓN ................................................................................................30

1. USO DE BIBLIOTECAS Y/O REPOSITORIOS ...............................................................................30



pág. 3

2. VARIABLES ...........................................................................................................................31

3. CONSTANTES .......................................................................................................................31

4. VARIABLES GLOBALES ...........................................................................................................31

5. CORCHETES E IDENTACIÓN ...................................................................................................31

6. CÓDIGO CLARO ....................................................................................................................32

7. HTML ..................................................................................................................................32

• VERSIONADO .....................................................................................................................33

• DOCUMENTACIÓN .............................................................................................................33

• NORMAS GENERALES DE MAQUETACIÓN ....................................................................34

LIBRERÍAS ............................................................................................................................34

LOGIN ..................................................................................................................................35

1. CONTENIDO .........................................................................................................................35

2. TAMAÑOS .............................................................................................................................35

SISTEMA ..............................................................................................................................36

BOTONES .............................................................................................................................38

• TIPOGRAFÍA .......................................................................................................................39

TÍTULOS Y MENÚ ...................................................................................................................39

CONTENIDO .........................................................................................................................39

ÍCONOS ................................................................................................................................40

• PALETA DE COLORES ......................................................................................................40

• TÍTULOS Y MENSAJES .....................................................................................................40

• FORMULARIOS ..................................................................................................................41



pág. 4

Presentación

Las aplicaciones web gubernamentales son la plataforma desde la cual interactúan

ciudadanía y gobierno, adicionalmente gracias a los datos estadísticos que permiten

calcular se convierten en una herramienta importante para la toma de decisiones en las

que el Gobierno rige sus líneas de acción; he ahí la importancia de la conectividad y

disponibilidad de la información o servicios que se ofrece en las diferentes Dependencias

y Entidades de la Administración Pública Estatal (APE).

Las aplicaciones web institucionales del APE deberán ser un medio por el cual los

ciudadanos accedan a los servicios, trámites, contenido y herramientas de participación,

que prestan y ofrecen las Dependencias y Entidades del Estado.

El objetivo del presente documento es presentar las especificaciones por las que se debe

regir su construcción con la finalidad de mantener un modelo homologado y alineado a

la imagen institucional del Gobierno del Estado.



pág. 5

Justificación

Los proyectos de desarrollo de sistemas y/o aplicaciones de la Administración Pública

Estatal (APE) deben garantizar su interoperabilidad con la finalidad de garantizar su

integración a los sistemas/aplicaciones que se requieran.

Todos los sistemas desarrollados para la APE ya sea un desarrollo hecho en casa o por

outsourcing deben apegarse a la metodología de desarrollo y estándares establecidos

por la Dirección General de Tecnologías. De igual forma deben mantener una misma

identidad apegada al Plan Estatal de Desarrollo y a lo establecido en el presente manual.



pág. 6

Gestión de proyectos Los proyectos a realizarse deben de tener un alcance definido y objetivos claros.

Durante su realización debe considerarse como indispensable elaborar la siguiente

documentación:

• Documento de Visión de Solución

Estable objetivos, alcance, situación actual, necesidades identificadas,

solicitante, usuarios involucrados en el Proyecto y normativas así como los

requerimientos funcionales y no funcionales del Sistema. Este documento

contará con una descripción a alto nivel.

• Documento de Arquitectura

Este documento tiene como finalidad establecer una vista detallada de los

elementos que conformarán el Sistema, así como los elementos que han sido

utilizados para su Desarrollo.

o Casos de Uso

o Diseño de pantallas

o Diagrama de componentes

o Diagrama relacional

o Diccionario de datos

o Herramientas de desarrollo

• Manual de usuario

Leguajes de programación El lenguaje de programación a utilizar para el desarrollo de sistemas de la APE debe de

ser seleccionado según las necesidades que se requiera cumplir, los lenguajes que por

defecto pueden ser utilizados son:

• PHP

• JAVA

El uso de cualquier otro lenguaje de programación debe ser analizado y queda restringido

a los requerimientos que necesite para su instalación y a la infraestructura con la que se

cuente.



pág. 7

Para todos los casos es importante que se utilice la versión estable más reciente. Queda

prohibido el uso de versiones beta, tanto en lenguajes como en librerías, bibliotecas,

extensiones, frameworks o cualquier otra herramienta que se utilice.

Infraestructura Los sistemas desarrollados para la APE, deberán utilizar algunas de las siguientes

tecnologías:

Servidores de aplicación

Versión PHP 5.4 PHP 7.0 PHP 7.2

Apache 2.4 X X X

Versión Java 6 Java 7 Java 8

Apache Tomcat

6 X X X

7 X X X

8 X X

Versión

Subversión 1.7

Seguridad

La seguridad en las aplicaciones a nivel mundial es un tema muy importante para las

TIC´s “ Estudios revelan que más del 70% de los ataques a una aplicación WEB se dirige

a la capa de aplicación, y no a la red o el sistema – Gartner Group”.

La DGTID toma como referencia el Estándar de Verificación de Seguridad en

Aplicaciones V. 3.0.1 (ASVS por sus siglas en inglés) del Open Web Application

Security Project (OWASP) para contar con las medidas de seguridad necesarias para las

aplicaciones institucionales.



pág. 8

En ASVS se definen tres niveles de verificación de seguridad:

• ASVS nivel 1.- Mínimo requerido para todas las aplicaciones.

• ASVS nivel 2.- Para aplicaciones que manejan transacciones business-to-business, información de salud, implementan funciones sensibles o críticas para el negocio o incluyen el proceso de otros activos sensibles.

• ASVS nivel 3.- Para aplicaciones que realizan transacciones de alto valor, contienen datos médicos confidenciales, o cualquier aplicación que requiera el más alto nivel de confianza. Se encuentra reservado para aquellos casos en que se podría poner en peligro la seguridad humana o cuando una violación a la aplicación podría impactar seriamente y por completo a la organización.

Arquitectura, diseño y modelado de amenazas

La arquitectura, diseño y modelado de amenazas de sistemas/aplicaciones deben cubrir como mínimo las siguientes características:

1. Asegurarse que todos los componentes utilizados son identificados y

necesarios.

2. Verificar que todos los componentes de la aplicación incluyendo bibliotecas,

frameworks y módulos utilizados se encuentren libres de vulnerabilidades.

3. Ninguna clave secreta o lógica de negocio se encuentre expuesto del lado del

cliente.

Para sistemas que requieran un nivel mayor de seguridad por la naturaleza de

la información que maneje deberá aplicarse el N2 o N3 según corresponda

(tabla 1).

Descripción N1 N2 N3

1 Verificar que todos los componentes se encuentran identificados y asegurar que son necesarios.

✓ ✓ ✓

2 Verificar todos los componentes, tales como bibliotecas, módulos y sistemas externos, que no son parte de la aplicación pero que la misma los necesita para funcionar se han identificado.

✓ ✓



pág. 9

Requisitos de verificación de autenticación

Todas las aplicaciones que requieren autenticación deberán asegurar los siguientes puntos:

1. Verificar que todas las páginas y recursos que requieran autenticación

realicen esta validación a excepción de las que requieren ser públicas.

3 Verificar que se ha definido una arquitectura de alto nivel para la aplicación.

✓ ✓

4 Verificar que todos los componentes de la aplicación se definen de acuerdo a las funciones de negocio o de seguridad que proporcionan.

✓

5 Verificar que todos los componentes que no son parte de la aplicación pero que son necesarios para su funcionamiento, sean definidos de acuerdo a las funciones de negocio o de seguridad que proporcionan.

✓

6 Verificar que se ha realizado un modelo de amenazas para la aplicación en cuestión y que éste cubre riesgos asociados con la suplantación de identidad, manipulación, repudio, revelación de información y elevación de privilegios (STRIDE).

✓

7 Verificar que todos los controles de seguridad (incluyendo las bibliotecas que llaman a servicios de seguridad externos) tienen una implementación centralizada.

✓ ✓

8 Verificar que los componentes estén separados unos de otros mediante controles de seguridad, tales como segmentación de la red, reglas de firewall, o grupos de seguridad basados en la nube.

✓ ✓

9 Verificar que no hay ninguna lógica de negocio sensible, claves secretas u otra información propietaria en el código del lado del cliente.

✓ ✓

10 Verificar que todos los componentes de la aplicación, bibliotecas, módulos, frameworks, plataformas y sistemas operativos se encuentran libres de vulnerabilidades conocidas

✓ ✓

Tabla 1 Requisitos para arquitectura, diseño y modelado de amenazas



pág. 10

2. Se prohíbe explícitamente pre-cargar las credenciales de acceso.

3. Todas las autenticaciones deben ser realizadas del lado del servidor.

4. Verificar que los controles de autenticación fallan de manera segura,

autenticando solo a los usuarios autorizados.

5. El cambio de contraseña deberá solicitar la contraseña anterior, y

confirmación de la contraseña nueva.

6. Las contraseñas de los usuarios deberán ser cifradas, se prohíbe su

almacenamiento en texto plano.

7. Verificar que las credenciales son transportadas mediante un enlace cifrado

(https).

8. Verificar que la recuperación de contraseña y acceso no revelen la contraseña

actual.

9. Se prohíbe la utilización de contraseñas por defecto en la aplicación, en caso

que este sea un requerimiento explícito se debe garantizar que sea de un solo

uso.

10. Se prohíbe la verificación masiva de contraseñas.

11. Verificar que existen mecanismos para asegurar la creación de contraseñas

seguras, las cuales deben tener como mínimo:

a. Longitud mínima de 8 caracteres

b. Uso de mayúsculas

c. Uso de minúsculas

d. Uso de números

e. Uso de caracteres especiales

12. Verificar que información como llaves de API y contraseñas no se incluyen en

el código fuente o en los repositorios en línea.

Las aplicaciones que manejen datos sensibles y que por su naturaleza requieren un nivel mayor de seguridad, deben implementar de manera adicional a los puntos ya descritos, las características señaladas en la tabla 2 nivel 2 (N2) o nivel 3 (N3) según se requiera.

# Descripción N1 N2 N3

1 Verificar que todas las páginas y recursos requieran autenticación excepto aquellos que sean específicamente destinados a ser públicos

✓ ✓ ✓

2 Verificar que todos los campos de credenciales no reflejen las contraseñas del usuario. Cargar la credencial por parte de la aplicación implica que la

✓ ✓ ✓



pág. 11

misma fue almacenada de forma reversible o en texto plano, lo que se encuentra explícitamente prohibido.

3 Verificar que todos los controles de autenticación se realicen del lado del servidor.

✓ ✓ ✓

4 Verificar que los controles de autenticación fallan de forma segura para evitar que los atacantes no puedan iniciar sesión.

✓ ✓ ✓

5 Verificar que los campos de contraseñas permiten o fomentan el uso de frases como contraseñas (passphrases) y no impiden el uso de gestores de contraseñas, contraseñas largas o altamente complejas.

✓ ✓ ✓

6 Verificar que toda función relacionada con la autenticación (como registro, actualización del perfil, olvido de nombre de usuario, recuperación de la contraseña, token perdido / deshabilitado, funciones de help desk o IVR) que pueda ser utilizada de forma indirecta como mecanismo de autenticación, sea al menos tan resistente a ataques como el mecanismo primario.

✓ ✓ ✓

7 Verificar que la funcionalidad de cambio de contraseña solicite la contraseña anterior, la nueva contraseña y una confirmación de la contraseña.

✓ ✓ ✓

8 Verificar que todas las decisiones de autenticación son registradas en la bitácora sin almacenar información sobre la contraseña o el identificador de la sesión. Esto debería incluir los metadatos necesarios para investigaciones de seguridad.

✓ ✓

9 Verificar que las contraseñas de las cuentas se encuentren almacenadas utilizando una rutina de hashing con una sal, y que requiera un factor de trabajo lo suficientemente alto para evitar un ataque de fuerza bruta.

✓ ✓

10 Verificar que las credenciales son transportadas mediante un enlace cifrado adecuadamente y que todas las páginas/funciones que requieren que el usuario introduzca credenciales se realicen utilizando enlaces cifrados.

✓ ✓ ✓

11 Verificar que las funciones de recuperar contraseña y acceso no revelen la contraseña actual y que la nueva contraseña no se envíe en texto plano al usuario.

✓ ✓ ✓



pág. 12

12 Verificar que no es posible enumerar información mediante las funcionalidades de: inicio de sesión, reinicio o recuperación contraseñas.

✓ ✓ ✓

13 Verificar que no se utilizan contraseñas por defecto en la aplicación o cualquiera de los componentes utilizados por la misma (como "admin/password").

✓ ✓ ✓

14 Verificar que existen mecanismos de anti-automatización que previenen la verificación de credenciales obtenidas de forma masiva, ataques de fuerza bruta y ataques de bloqueos de cuentas.

✓ ✓ ✓

15 Verificar que todas las credenciales de autenticación para acceder a servicios externos a la aplicación se encuentran cifradas y almacenadas en un lugar protegido.

✓ ✓

16 Verificar que las funcionalidades de recuperar contraseña y otras formas de recuperar la cuenta utilizan mecanismos de TOTP (Time-Based One-Time Password) u otro tipo de soft token, push a dispositivo móvil u otro tipo de mecanismo de recuperación offline. El uso de un valor aleatorio en un correo electrónico o SMS debe ser la última opción ya que son conocidas sus debilidades.

✓ ✓

17 Verificar que el bloqueo de la cuenta se divida en estado de bloqueo suave y duro, y éstas no son mutuamente excluyentes. Si una cuenta está temporalmente bloqueada de forma suave debido a un ataque de fuerza bruta, esto no debe restablecer el bloqueo de estado duro.

✓ ✓

18 Verificar que, si la aplicación hace uso de conocimiento basado en preguntas secretas, las preguntas no violan leyes de privacidad y son lo suficientemente fuertes para proteger la cuenta de recuperaciones maliciosas

✓ ✓ ✓

19 Verificar que el sistema puede configurarse para no permitir el uso de un número de contraseñas utilizadas anteriormente.

✓ ✓

20 Verificar que la re-autenticación basada en riesgo, autenticación de dos factores o firma de transacciones se encuentra implementada en los lugares adecuados.

✓ ✓

21 Verificar que existen medidas para bloquear el uso de contraseñas comúnmente utilizadas y contraseñas débiles.

✓ ✓ ✓



pág. 13

Requisitos de verificación de gestión de sesiones

La gestión de sesiones es un elemento crítico en la seguridad de las aplicaciones debido a que permite controlar y mantener el estado de un usuario al interactuar con las aplicaciones por lo que se debe asegurar que las sesiones:

1. Son únicas para cada individuo y no conjeturadas o compartidas.

2. Su tiempo de vida no excede las 8 horas.

3. Deben ser consideradas inválidas cuando ya no sean necesarias.

4. Invalidarse después de 15 minutos de inactividad.

5. Verificar que la sesión se invalida al cerrar sesión.

6. Proporcionar fácil acceso al cierre de sesión.

7. No revelar el identificador de sesión

8. Limitar el número de sesiones concurrentes activas por usuario a uno.

Para el caso de aplicaciones que requieren un mayor grado de seguridad o que

requiera un número mayor de sesiones por usuario, deberán de implementarse

de manera adicional los puntos descritos en la tabla 3 en los niveles N1 (básico),

N2 o N3 según se requiera.

22 Verificar que todos los desafíos de autenticación, ya sea exitosa o fallida, responden en el mismo tiempo promedio.

✓

23 Verificar que información como llaves de API y contraseñas no se incluyen en el código fuente o en los repositorios en línea de código fuente.

✓

24 Verificar que, si una aplicación permite a los usuarios autenticarse, puedan hacerlo mediante autenticación de dos factores u otra autenticación fuerte, o cualquier esquema similar que proporcione protección contra la divulgación de nombres de usuario y contraseñas.

✓ ✓

25 Verificar que las interfaces administrativas de la aplicación no sean accesibles a intrusos.

✓ ✓ ✓

Tabla 2 Requisitos de verificación de autenticación



pág. 14


1 Verificar que no se utiliza un gestor de sesiones personalizado, o que, si el gestor de sesiones es personalizado, éste sea resistente contra los ataques más comunes.

✓ ✓ ✓

2 Verificar que las sesiones se invalidan cuando el usuario cierra la sesión.

✓ ✓ ✓

3 Verificar que las sesiones se invalidan luego de un período determinado de inactividad.

✓ ✓ ✓

4 Verificar que las sesiones se invalidan luego de un período determinado de tiempo, independientemente de que se esté registrando actividad (timeout absoluto).

✓

5 Verificar que todas las páginas que requieren autenticación poseen acceso fácil y visible a la funcionalidad de cierre de sesión.

✓ ✓ ✓

6 Verificar que el identificador de sesión nunca se revele en URLs, mensajes de error o registros de bitácora. Esto incluye verificar que la aplicación no es compatible con la re-escritura de URL incluyendo el identificador de sesión.

✓ ✓ ✓

7 Verificar que toda autenticación exitosa y reautenticaciones generen un nuevo identificador de sesión.

✓ ✓ ✓

8 Verificar que sólo los identificadores de sesión generados por la aplicación son reconocidos como activos por ésta.

✓ ✓

9 Verificar que los identificadores de sesión son suficientemente largos, aleatorios y únicos para las sesiones activas.

✓ ✓ ✓

10 Verificar que los identificadores de sesión almacenados en cookies poseen su atributo “path” establecido en un valor adecuadamente restrictivo y que además contenga los atributos "Secure" y "HttpOnly".

✓ ✓ ✓

11 Verificar que la aplicación limita el número de sesiones concurrentes activas.

✓ ✓ ✓

12 Verificar que una lista de sesiones activas esté disponible en el perfil de cuenta o similar para cada usuario. El usuario debe ser capaz de terminar cualquier sesión activa.

✓ ✓ ✓



pág. 15

Tabla 3 Requisitos de seguridad para el uso de sesiones

Requisitos de verificación del control de accesos

Se debe asegurar que la aplicación satisface las siguientes características:

1. Todos los usuarios deben estar asociados a un conjunto definido de roles y

permisos establecidos en las reglas de negocio.

2. Garantizar el acceso a los recursos únicamente de aquellos que cuenten con

permisos necesarios para hacerlo.

3. Verificar que los accesos a registros sensibles este protegido.

4. Bloquear el listado de los directorios, a menos que sea solicitado de manera

explícita.

5. Garantizar que la validación de permisos se realice del lado del servidor para

evitar que las url sean alteradas mediante sus parámetros o que sean

consultadas sin autorización.


1 Verificar que existe el principio de privilegio mínimo - los usuarios sólo deben ser capaces de acceder a las funciones, archivos de datos, URL, controladores, servicios y otros recursos, para los cuales poseen una autorización específica. Esto implica protección contra suplantación de identidad y elevación de privilegios.

✓ ✓ ✓

2 Verificar que el acceso a registros sensibles esté protegido, tal que sólo objetos autorizados o datos sean accesibles por cada usuario.

✓ ✓ ✓

3 Verificar que la navegación del directorio esté deshabilitada a menos que esto sea deliberadamente deseado.

✓ ✓ ✓

4 Las aplicaciones no deben permitir el descubrimiento o divulgación de metadatos de archivos o directorios, como carpetas que contengan Thumbs.db, DS_Store, o directorios .git o SVN.

✓ ✓ ✓

5 Verificar que los controles de acceso fallen de forma segura.

✓ ✓ ✓

13 Verificar que al usuario se le sugiera la opción de terminar todas las otras sesiones activas después de un proceso de cambio de contraseña exitoso.

✓ ✓ ✓



pág. 16


6 Verificar que las mismas reglas de control de acceso implícitas en la capa de presentación son aplicadas en el servidor.

✓ ✓ ✓

7 Verificar que todos los atributos de usuario, datos e información de las políticas utilizadas por los controles de acceso no puedan ser manipulados por usuarios finales a menos que sean específicamente autorizados.

✓ ✓

8 Verificar que existe un mecanismo centralizado para proteger el acceso a cada tipo de recursos protegidos.

✓

9 Verificar que todas las acciones de control de acceso pueden ser registradas y que todas las acciones fallidas son registradas.

✓ ✓

10 Verificar que la aplicación o su infraestructura emite tokens anti-CSFR aleatorios existe otro mecanismo de protección de la transacción.

✓ ✓ ✓

11 Verificar que el sistema se pueda proteger contra el acceso permanente a funciones aseguradas, recursos o datos.

✓ ✓

12 Verificar que la aplicación disponga de autorización adicional (como autenticación aumentada o adaptación de autenticación) para sistemas de valores bajos, y/o segregación de funciones para aplicaciones de alto valor para cumplir con los controles anti fraude según el análisis de riesgo de la aplicación y fraudes cometidos en el pasado.

✓ ✓

13 Verificar que la aplicación aplique correctamente la autorización contextual para no permitir la manipulación de parámetros de la URL.

✓ ✓ ✓

Tabla 4 Requisitos de seguridad para accesos

Requisitos de verificación para manejo de entrada de datos

maliciosos

La debilidad más común de seguridad de las aplicaciones web es la falla en

validar apropiadamente el ingreso de datos que provienen del cliente o del

ambiente antes de ser utilizada, por lo que es indispensable cumplir con los

siguientes requerimientos:

1. Realizar validaciones del lado del cliente y del lado de servidor para reducir

la posibilidad de fallos o acciones no deseadas.



pág. 17

2. Verificar que todas las consultas realizadas a las BD estén protegidas por la

utilización de declaraciones preparadas o parametrizadas, para no ser

susceptibles a inyecciones SQL.

3. En caso de usar asignación automática de parámetros en masa desde la

petición entrante a un modelo, verificar que campos sensibles de seguridad

como "accountBalance", "role" o "password" sean protegidos de enlaces

automáticos maliciosos.


1 Verificar que el entorno de ejecución no es susceptible a desbordamientos de búfer, o que los controles de seguridad previenen desbordamientos de búfer

✓ ✓ ✓

2 Verificar que las fallas de validación de entradas de datos del lado del servidor sean rechazadas y registradas.

✓ ✓ ✓

3 Verificar que se aplican las rutinas de validación de entradas de datos del lado del servidor.

✓ ✓ ✓

4 Verificar que un único control de validación de entrada es utilizado por la aplicación para cada tipo de datos que es aceptado.

✓

5 Verificar que todas las consultas de SQL, HQL, OSQL, NOSQL y procedimientos almacenados, llamadas de procedimientos almacenados están protegidos por la utilización de declaraciones preparadas o parametrización de consultas, y por lo tanto no sean susceptibles a la inyección de SQL

✓ ✓ ✓

6 Verificar que la aplicación no es susceptible a la inyección LDAP, o que los controles de seguridad previenen inyección LDAP.

✓ ✓ ✓

7 Verificar que la aplicación no es susceptible a la inyección de comandos del sistema operativo, o que los controles de seguridad previenen la inyección de comandos del sistema operativo.

✓ ✓ ✓

8 Verificar que la aplicación no es susceptible a la inclusión de archivo remoto (RFI) o inclusión de archivo Local (LFI) cuando el contenido es utilizado como una ruta a un archivo.

✓ ✓ ✓

9 Verificar que la aplicación no es susceptible a ataques comunes de XML.

✓ ✓ ✓

10 Asegurar que todas las variables string utilizadas dentro de HTML u otro lenguaje web interpretado en cliente se encuentra apropiadamente codificada manualmente o se

✓ ✓ ✓



pág. 18

# Descripción N1 N2 N3 utiliza plantillas que automáticamente codifican contextualmente para asegurar que la aplicación no sea susceptible a ataques DOM Cross-Site Scripting (XSS)

11 Si el framework de la aplicación permite asignación automática de parámetros en masa desde la petición entrante a un modelo, verificar que campos sensibles de seguridad como "accountBalance", "role" o "password" sean protegidos de enlaces automáticos maliciosos.

✓ ✓

12 Verificar que la aplicación contenga defensas contra los ataques de contaminación de parámetros HTTP, particularmente si el framework de la aplicación no hace distinción sobre el origen de los parámetros de la petición

✓ ✓

13 Verificar que las validaciones del lado del cliente se utilizan como una segunda línea de defensa, en adición a la validación del lado del servidor.

✓ ✓

14 Verificar que todos los datos de entrada sean validados, no solamente los campos de formularios HTML sino también todos los orígenes de entrada como las llamadas REST, parámetros de consulta, encabezados HTTP, cookies, archivos por lotes, fuentes RSS, etc.; mediante validación positiva (lista blanca), o utilizando otras formas de validación menos eficaces tales como listas de rechazo transitorio (eliminando símbolos defectuosos), o rechazando malas entradas (listas negras).

✓ ✓

15 Verificar que datos estructurados fuertemente tipados son validados un esquema definido incluyendo; caracteres permitidos, longitud y patrones.

✓ ✓

16 Verificar que los datos no estructurados sean sanitizados cumpliendo medidas genéricas de seguridad tales como caracteres permitidos, longitud y que caracteres potencialmente dañinos en cierto contexto sean anulados

✓ ✓

17 Verificar que HTML no confiable proveniente de editores WYSIWYG o similares sean debidamente sanitizados con un sanitizador de HTML y se manejen apropiadamente según la validación de entrada y codificación.

✓ ✓ ✓

18 Para tecnologías de plantilla de codificación automática, si ésta se ha deshabilitado, asegurar que la sanitización de HTML esté habilitada en su lugar.

✓ ✓



pág. 19


19 Verificar que los datos transferidos desde un contexto DOM a otro, utilice métodos de JavaScript seguro, como pueden ser .innerText y .val.

✓ ✓

20 Verificar que cuando se interprete JSON en navegadores, que JSON.parse sea el utilizado para interpretarlo y no eval().

✓ ✓

21 Verificar que los datos de autenticación se eliminen del almacenamiento del cliente, tales como el DOM del navegador, después de terminada la sesión.

✓ ✓

Tabla 5 Requisitos de seguridad para entrada de datos

Requisitos de verificación de gestión y registro de errores

El registro de errores permite proporcionar información útil a los usuarios y administradores que permitan mejorar o en su caso identificar lo que está pasando en el sistema. Los sistemas de la APE deberán:

1. No registrar información confidencial a menos que se sumamente requerido.

2. Garantizar que toda la información registrada sea gestionada de manera

segura y sea protegida.

3. Verificar que los registros de bitácora sean almacenados en un tiempo de vida

corto.

4. Verificar que la aplicación no emita información sensible en el despliegue de

errores.

Si la aplicación o sistema requiere de un nivel alto o medio de seguridad deberá

cubrir los niveles N2 y N3 de la siguiente tabla respectivamente.

Descripción N1 N2 N3

1 Verificar que la aplicación no emita mensajes de error o rastros de pilas que contengan datos sensibles que podrían ayudar a un atacante, incluyendo el identificador de sesión, versiones de software/entorno y datos personales.

✓ ✓ ✓

2 Verificar que la lógica de manejo de errores en controles de seguridad niegue el acceso por defecto.

✓ ✓



pág. 20

Tabla 6 Requisitos para gestión y registro de errores

Requisitos de verificación de protección de datos

Los sistemas/aplicaciones de la APE deben cumplir tres aspectos:

1. Confidencialidad. - La información debe protegerse de acceso no autorizado.

2. Integridad. - Debe garantizarse que los datos no sean alterados de manera

no autorizada.

3 Verificar que los controles del registro de seguridad proporcionen la capacidad para registrar los eventos de éxito y sobre todo los eventos de falla que son identificados como relevantes para la seguridad.

✓ ✓

4 Verificar que cada registro de evento incluya la información necesaria para permitir una eventual investigación y correlación con otros eventos.

✓ ✓

5 Verificar que todos los eventos que incluyen datos no confiables no se ejecuten como código en el software destinado a la visualización del registro.

✓

6 Verificar que los registros de seguridad estén protegidos contra modificación y acceso no autorizado.

✓ ✓

7 Verificar que la aplicación no registre datos sensibles que podrían ayudar a un atacante, incluyendo identificadores de sesión del usuario, contraseñas, hashes o tokens de APIs.

✓ ✓

8 Verificar que todos los símbolos no imprimibles y separadores de campos estén codificados correctamente en las entradas del registro, para evitar la inyección del registro que no permita seguir las pistas de un acto malicioso.

✓

9 Verificar que los campos del registro de fuentes confiables y no confiables sean identificables en las entradas del registro.

✓

10 Verificar que un registro de auditoría o similar permita la no repudiación de transacciones claves.

✓ ✓

11 Verificar que los registros de seguridad poseen alguna forma de verificación o control de integridad para prevenir modificaciones no autorizadas.

✓

12 Verificar que los registros estén almacenados en una partición diferente a donde ejecuta la aplicación con una rotación de registros adecuada.

✓



pág. 21

3. Disponibilidad. - El sistema/aplicación debe ser accesible en cualquier

momento que se requiera.

Aunado a esos tres aspectos, deberán cumplirse los siguientes datos:

1. Desactivar el almacenamiento de caché y funciones de autocompletado en

formularios con información sensible.

2. La información sensible no debe ser enviada mediante parámetros de la URL.

Para todas las aplicaciones/sistemas que requieran un mayor grado de seguridad

medio o alto N2 o N3 respectivamente, según el siguiente listado.


1 Verificar que todos los formularios que contengan información sensible se les haya desactivado el almacenamiento de caché en el cliente, incluyendo funciones de autocompletar.

✓ ✓ ✓

2 Verificar que la lista de datos sensibles procesados por la aplicación se encuentra identificada, y que existe una política explícita de cómo debe controlarse el acceso a estos datos, cifrarse y reforzarse bajo las directivas de protección de datos pertinentes.

✓

3 Verificar que toda información sensible es enviada al servidor en el cuerpo o cabeceras del mensaje HTTP.

✓ ✓ ✓

4 Verificar que, en el servidor, todas las copias almacenadas en caché o temporales de datos sensibles estén protegidos de accesos no autorizados o son purgados/invalidados después del acceso por parte del usuario autorizado.

✓ ✓

5 Verificar que existe un mecanismo para eliminar de la aplicación todo tipo de dato sensible luego de transcurrido el tiempo definido por la política de retención.

✓

6 Verificar que la aplicación reduce al mínimo el número de parámetros en una solicitud, como campos ocultos, variables de Ajax, cookies y valores en encabezados.

✓ ✓

7 Verificar que la aplicación tenga la capacidad para detectar y alertar sobre un número anormal de solicitudes para la recolección de datos por medio de extracción de pantalla.

✓

8 Verificar que datos almacenados en el no contengan información sensible o información personal identificable.

✓ ✓ ✓



pág. 22


9 Verificar que el acceso a datos sensibles es registrado en bitácora, los datos son registrados acorde a las directivas de protección de datos o cuando el registro de los accesos es requerido.

✓ ✓

10 Verificar que la información sensible mantenida en memoria es sobre escrita con ceros tan pronto como no es requerida, para mitigar ataques de volcado de memoria.

✓ ✓

Tabla 7 Requisitos de verificación de protección de datos

Requisitos de verificación de configuración de seguridad HTTP

Por regla las aplicaciones/sistemas deben correr sobre HTTPS; sin embargo, para casos específicos se hará uso de HTTP, en ambos casos deberán cubrirse los siguientes requisitos: 1. Verificar que las aplicaciones acepten solo los métodos de solicitud HTTP que

son necesarios.

2. Cada respuesta HTTP debe contener una cabecera content-type en la que se

especifique un conjunto utilizando un conjunto de caracteres seguros (UTF-8,

ISO 8859-1).

3. Verificar que los encabezados HTTP o cualquier parte de la respuesta HTTP

no expongan información detallada de la versión de los componentes del

sistema.

4. Verificar que las respuestas de las API’s contengan opciones X-Content-

Type: nosniff y Content-Disposition: attachment; filename="api.json" (u otro

nombre de archivo apropiado para el tipo de contenido).

Adicionalmente se listan otros puntos a considerar para cuando se requiera un

protocolo de mayor seguridad.


1 Verificar que la aplicación acepte solo un conjunto definido de métodos de solicitud HTTP y que son necesarios, como GET y POST, y métodos no utilizados se encuentran explícitamente bloqueados.

✓ ✓ ✓

2 Verificar que cada respuesta HTTP contenga una cabecera content-type en la que se especifique un conjunto utilizando un conjunto de caracteres seguros (Ejemplo: UTF-8, ISO 8859-1).

✓ ✓ ✓



pág. 23


3 Verificar que los encabezados HTTP agregados por un proxy confiable o dispositivos SSO, tales como un token de portador (bearer), son autenticados por la aplicación.

✓ ✓

4 Verificar que el cabezal X-FRAME-OPTIONS se encuentra especificado para los sitios que no deben ser embebidos en X-Frame en sitios de terceros.

✓ ✓

5 Verificar que los encabezados HTTP o cualquier parte de la respuesta HTTP no expongan información detallada de la versión de los componentes del sistema.

✓ ✓ ✓

6 Verificar que la política de seguridad de contenido (CSPv2) está en uso de tal manera que ayude a mitigar vulnerabilidades de inyección comunes de DOM, XSS, JSON y Javascript.

✓ ✓ ✓

7 Verificar que el encabezado "X-XSS-Protection: 1; mode=block" esté presente para habilitar a los navegadores a filtrar XSS reflejados.

✓ ✓ ✓

Tabla 8 Requisitos para configuración de seguridad HTTP

Requisitos de verificación para controles maliciosos

El código malicioso es difícil de detectar, por lo que se debe verificar que toda aplicación o sistema cumpla en medida de lo posible lo siguiente: 1. Que no posee bombas de tiempo ni otros ataques basados en tiempo.

2. La aplicación no posee puestas traseras o fallos de lógica que pueden ser

controlados por un atacante.


1 Verificar que toda actividad maliciosa sea adecuadamente aislada o encajonada para retrasar y disuadir a los atacantes de atacar a otras aplicaciones.

✓

2 Verificar que el código fuente de la aplicación y tantas bibliotecas de terceros como sean posibles, no poseen puertas traseras, huevos de pascua, o fallas de lógica en la autenticación, control de acceso, validaciones de entrada y lógica de negocio en transacciones de alto valor.

✓

Tabla 9 Requisitos de verificación para controles maliciosos



pág. 24

Requisitos de verificación para lógica de negocios

Se debe asegurar que las aplicaciones realicen lo siguiente:

1. El flujo de la lógica de negocio debe ser secuencial y ordenado.

2. Verificar que la aplicación tiene límites de negocio y los aplique correctamente

por cada usuario.

Requisitos de verificación de archivos y recursos

Para el registro y uso de archivos deben seguirse las siguientes normas:

1. Verificar que los redireccionamientos se realicen a destino conocidos, los

cuales estén en la lista blanca, en caso contrario mostrar mensajes de

advertencia.

2. No utilizar archivos no confiables como comandos de I/O (entrada/.

3. Limitar el tipo de archivos por su extensión.

4. El peso máximo de archivos debe ser 4MB.

Para los sistemas que requieran mayor grado de seguridad, deben contemplarse los

requisitos de nivel N2 y N3.


1 Verificar que las URL de redireccionen y reenvíen sólo a destinos clasificados en la lista blanca, o mostrar una advertencia cuando se redirija a contenido potencialmente no confiable.

✓ ✓ ✓

2 Verificar que archivos no confiables enviados a la aplicación no sean utilizados directamente por comandos de I/O (Entrada/Salida) de archivos.

✓ ✓ ✓

3 Verificar que los archivos procedentes de fuentes no confiables sean validados para ser del tipo del cual se espera y sean analizados por escáneres antivirus para evitar la carga de contenido malicioso conocido.

✓ ✓ ✓

4 Verificar que datos no confiables no se utilicen en funcionalidades de reflexión, cargado de clases o inserción para prevenir vulnerabilidades de inclusión de archivos remotos/locales.

✓ ✓ ✓



pág. 25


5 Verificar que datos no confiables no se utilicen en recursos de dominios compartidos (CORS) para proteger contra el contenido remoto arbitrario.

✓ ✓ ✓

6 Verificar que los archivos obtenidos de fuentes no confiables se almacenen fuera del webroot, con permisos limitados, preferiblemente con una fuerte validación.

✓ ✓

7 Verificar que el servidor web o de aplicación se encuentra configurado por defecto para negar el acceso a recursos remotos o sistemas fuera del servidor web o de aplicación.

✓ ✓

8 Verificar que el código de la aplicación no ejecuta datos cargados obtenidos de fuentes no confiables.

✓ ✓ ✓

9 Verificar que no utiliza Flash, Active-X, Silverlight, NACL, Java del lado del cliente u otras tecnologías del lado del cliente que no sean soportadas de forma nativa a través de los estándares de navegador W3C.

✓ ✓ ✓

Tabla 10 Requisitos de verificación de archivos y recursos

Requisitos de verificación móvil

Las aplicaciones móviles deben:

1. Deben tener el mismo nivel de controles de seguridad tanto en el cliente móvil

como en el servidor, mediante la aplicación de controles de seguridad en un

entorno de confianza.

2. Todos los datos sensibles transmitidos desde el dispositivo deben ser hechos

teniendo en mente la seguridad en la capa de transporte.

3. Verificar que los valores de identificadores almacenados en el dispositivo y

recuperables por otras aplicaciones, como el número de UDID o IMEI no se

utilicen como tokens de autenticación.

4. Verificar que la aplicación móvil no almacene datos sensibles en recursos

compartidos potencialmente no cifrados en el dispositivo.

5. Verificar que los datos sensibles no se almacenen sin protección en el

dispositivo, incluso en áreas protegidas del sistema como llaveros.



pág. 26


1 Verificar que los valores de identificadores almacenados en el dispositivo y recuperables por otras aplicaciones, como el número de UDID o IMEI no se utilicen como tokens de autenticación.

✓ ✓ ✓

2 Verificar que la aplicación móvil no almacene datos sensibles en recursos compartidos potencialmente no cifrados en el dispositivo.

✓ ✓ ✓

3 Verificar que los datos sensibles no se almacenen sin protección en el dispositivo, incluso en áreas protegidas del sistema como llaveros.

✓ ✓ ✓

4 Verificar que las contraseñas, claves secretas y tokens de APIs se generan dinámicamente en la aplicación móvil.

✓ ✓

5 Verificar que la aplicación móvil evite fugas de información sensible.

✓ ✓

6 Verificar que la aplicación solicite permisos mínimos para la funcionalidad y recursos requeridos.

✓ ✓

7 Verificar que el código sensible de la aplicación sea cargado de forma no predecible en memoria.

✓ ✓ ✓

8 Verificar que se encuentren presentes técnicas anti depuración suficientes para impedir o retrasar a posibles atacantes de inyectar depuradores en la aplicación móvil.

✓

9 Verificar que la aplicación no exporte actividades intents, o proveedores de contenido con información sensible a otras aplicaciones móviles posibles de ser explotados por otras aplicaciones en el mismo dispositivo.

✓ ✓ ✓

10 Verificar que la información sensible almacenada en memoria sea sobreescrita con ceros tan pronto como no deje de ser requerida, con el fin de mitigar ataques de volcado de memoria.

✓

11 Verificar que las actividades expuestas, intents, proveedores de contenido realicen validaciones de los datos de entrada.

✓ ✓ ✓

Tabla 11 Requisitos de verificación móvil

Requisitos de verificación de servicios web

En caso de utilizar servicios web REST o SOAP será necesario que posean:

1. Autenticación adecuada, gestión de sesión y autorización de todos los servicios

web.



pág. 27

2. Validación de entrada de datos de todos los parámetros que transiten de

zonas de menor a mayor confianza.

3. Interoperabilidad básica de la capa de servicios web SOAP para promover el

uso de la API.


1 Verificar que el mismo estilo de codificación se utilice tanto en el cliente como el servidor.

✓ ✓ ✓

2 Verificar que el acceso a las funciones de administración y gestión de la aplicación proveedora de servicios web sea limitado a los administradores.

✓ ✓ ✓

3 Verificar que existen esquemas XML o JSON y que éstos son verificados por la aplicación antes de aceptar datos de entrada.

✓ ✓ ✓

4 Verificar que todos los datos de entrada se encuentren limitados a un tamaño adecuado.

✓ ✓ ✓

5 Verificar que los servicios web basados en SOAP son compatibles con el perfil básico de interoperabilidad de servicios Web (WS-I) como mínimo. Esencialmente, eso implica compatibilidad con cifrado TLS.

✓ ✓ ✓

6 Verificar el uso de autenticación y autorización basada en sesiones. Por favor refiérase a las secciones 2, 3 y 4 para mayor orientación. Evite el uso de "claves de API" estáticas y enfoques similares.

✓ ✓ ✓

7 Verificar que los servicios REST se encuentren protegidos de Falsificación de Peticiones en Sitos Cruzados (CSRF), mediante el uso de al menos uno o más de los siguientes mecanismos: Verificaciones de ORIGIN, CSRF nonces, verificaciones de referrer o el envío doble de valores en cookie y en el servicio (double submit cookie pattern)

✓ ✓ ✓

8 Verificar que los servicios REST comprueben explícitamente que el Content-Type entrante sea el que se espera, como aplicación/xml o aplicación/json.

✓ ✓

9 Verificar que el contenido de los mensajes se encuentra firmado para asegurar el transporte confiable entre el cliente y el servicio, utilizando JSON Web Signing o WS-Security para servicios SOAP.

✓ ✓

10 Verificar que no existen rutas de acceso alternativas y menos seguras.

✓ ✓

Tabla 12 Requisitos de verificación de servicios web



pág. 28

Requisitos de configuración

Asegúrese de que la aplicación verificada: 1. Deben tener el mismo nivel de controles de seguridad tanto en el cliente móvil

como en el servidor, mediante la aplicación de controles de seguridad en un

entorno de confianza.

2. Utilice bibliotecas y una plataforma actualizada, evitando el uso de versiones

beta.

4. Una configuración segura por defecto.

5. Un Hardening suficiente de tal forma que se reduzcan las vulnerabilidades o

agujeros de seguridad.

6. Verificar que todos los recursos de la aplicación se encuentran alojados en la

aplicación en vez de confiar en un CDN o proveedores externos, tales como

bibliotecas JavaScript, estilos CSS o web fonts.

Adicionalmente se deben contemplar los siguientes requisitos para niveles de

seguridad N2 y N3.


1 Todos los componentes deben estar actualizados a las configuraciones y versiones de seguridad adecuadas. Esto debería incluir la eliminación de configuraciones y carpetas innecesarias como aplicaciones de ejemplo, documentación de plataforma y usuarios pre-establecidos o de ejemplo.

✓ ✓ ✓

2 Las comunicaciones entre componentes, tales como entre el servidor de aplicaciones y el servidor de base de datos, deberían ser cifradas, particularmente cuando los componentes están en diferentes contenedores o en sistemas diferentes.

✓ ✓

3 Las comunicaciones entre componentes, tales como entre el servidor de aplicaciones y el servidor de base de datos deberían autenticarse utilizando una cuenta con los mínimos privilegios necesarios.

✓ ✓

4 Verificar que los despliegues de la aplicación se encuentren dentro de Sandboxes, en contenedores o aislados para retrasar y disuadir a los atacantes de atacar a otras aplicaciones.

✓ ✓



pág. 29


5 Verificar que los procesos de compilación y despliegue de la aplicación se realizan de forma segura.

✓ ✓

6 Verificar que los administradores autorizados posean la capacidad de verificar la integridad de todas las configuraciones de seguridad pertinentes para garantizar que no hayan sido manipuladas.

✓

7 Verificar que todos los componentes de aplicación se encuentren firmados.

✓

8 Verificar que los componentes de terceros proceden de repositorios de confianza.

✓

9 Verificar que los procesos de compilación para los lenguajes de nivel de sistema operativo tengan todas las banderas de seguridad activas, tales como controles de seguridad, DEP y ASLR.

✓

10 Verificar que todos los recursos de la aplicación se encuentran alojados en la aplicación en vez de confiar en un CDN o proveedores externos, tales como bibliotecas JavaScript, estilos CSS o web fonts.

✓

Tabla 13 Requisitos de configuración

Requisitos de liberación Todo sistema por desarrollar debe ser alojado en tres ambientes:

• Desarrollo.- Orientado para la etapa de desarrollo, este ambiente puede contener sistemas con errores, o bugs. En caso de no contar con un espacio designado para este ambiente, debe de hacerse uso de los ambientes locales (localhost) de cada desarrollador.

• Calidad.- Para que un sistema se encuentre en este ambiente debe pasar previamente por una serie de testeos del área de desarrollo, está orientado para que el negocio y los involucrados en el uso del sistema puedan realizar pruebas y validaciones.

• Producción.- Un sistema llega a este ambiente únicamente si el dueño del negocio lo valida, antes de poner un sistema en este ambiente debe pasar exitosamente el análisis de vulnerabilidades.



pág. 30

Normas de desarrollo

MVC

Para mejorar la calidad de los sistemas/aplicaciones web desarrollados para la

APE, su desarrollo debe tener una arquitectura basada en el Modelo Vista

Controlador (MVC).

• Modelo Capa en la que se trabaja con los datos, deberá hacerse uso de alguna librería como PDO que abstraiga los datos y permita emplear las mismas funciones independientemente de la BD que se esté utilizando.

Para nombrar e identificar fácilmente archivos de este tipo deben ser nombrados por el singular de la tabla a la que haga referencia, preferentemente deberán estar dentro de una carpeta denominada “Model”.

• Vista Como su nombre lo indica contiene archivos de las interfaces de usuario. Deben agruparse por carpetas, las cuales tomen por nombre el controlador que hace uso de ellas. Su nombre debe hacer alusión al método o función que lo origina, de esta manera una vista que guarda el formulario de registro de un usuario se debe denominar create, y deberá guardarse dentro de una carpeta denominada usuario.

• Controlador Contienen la secuencia lógica necesaria para que el sistema funcione.

Enlaza las capas anteriores. Cada controlador debe tener un nombre en

singular que generalice la función que realiza seguida de la palabra

‘Controller’, de esta manera un controlador que lleva el registro de usuarios

se denominara UsuarioController. Preferentemente estos archivos deben

encontrarse en una carpeta denominada ‘Controllers’.

Todos los nombres de los archivos deben iniciar con mayúscula.

Normas de programación

Para facilitar la lectura del código generador en los sistemas de la APE, se requiere que todo

código a realizar cumpla con las siguientes normas:

1. Uso de bibliotecas y/o repositorios

Las bibliotecas a utilizar deberán ser en su versión estable más reciente, adicionalmente

deberá guardarse una copia dentro del proyecto y con ello evitar el uso de recursos fuera

del mismo.



pág. 31

2. Variables

• Los nombres a utilizar deben ser significativos; es decir que den una idea clara

de lo que representan.

• Deben escribirse en minúsculas, excepto la primera letra de cada variable.

3. Constantes

• Deben ser escritas en mayúsculas para su fácil identificación.

• En caso de ser compuestas por más de una palabra se deberá utilizar como

separador “_”.

4. Variables globales

• Deben ser escritas en mayúsculas.

5. Corchetes e identación

La identación de un programa es clave e indispensable por lo que debe hacerse con “tabs”

y no con espacios en blanco.

Los corchetes de un bloque de código con sentencias como if, swich, case o bucles debe

ser identado como se muestra a continuación:

$nombreEmpleado $Nrb_empleado

define("EDAD_VOTACION”, "18");

...

if (EDAD_VOTACION <= $edad)

$BD

function verificarCondicion() { if (condicion1) { if (condicion2) { while (condicion3) { instruccion1; }; }; instruccion2; }else{ instruccion3; }; };



pág. 32

6. Código claro

Antes de cada programa o función se debe especificar de manera concreta y clara que acción

o acciones realiza ese fragmento de código. Esta indicación se hace extensa a aquellas partes

de las funciones en las que por sí solas no brindan información, ejemplo:

7. HTML

Para la generación de HTML se deben considerar los siguientes puntos:

• Los Tags deben ser escritos en minúsculas.

• El código debe ser correctamente identado con tabs.

• Debe de evitarse agregar css de manera directa en los elementos html,

cualquier estilo deberá ser a través de archivos css, los cuales deben manejar

una línea por atributo.

.tabla {

background: white;

border-width: 1px;

margin-left:5%;

margin-right:5%;

}

<table style=”backgroud:White; border-

width: 1px;”>

<table class=”tabla”></table>

if ($ext[AR5Enlace4]==0) // No es proyecto, es empresa

table {background: white; border-width:

1px;margin-left:5%;margin-right:5%;}



pág. 33

Versionado Todo proyecto dentro de la APE debe implementar control de versiones. Es importante que todo

control de versiones que se utilice sea alojado en servidores pertenecientes al Gobierno del

Estado para garantizar su disponibilidad y seguridad.

Los controladores de versiones preferentes son:

• GIT

• SVN

Cualquier otro software para control de versiones requerirá una previa autorización de la DGTID

para su implementación.

Para realizar un correcto versionado es importante considerar los siguientes aspectos:

1. Mantener la rama principal incorrupta. - Esta rama debe tener cambios que

no contenga errores, en ella se alojarán el código que tenemos en

producción o en calidad en caso de ser un proyecto en desarrollo.

2. Aislar cambios en ramas. - Cada cambio o característica nuevo debe tener

su propia rama.

3. Guardar cambios con frecuencia. - Se recomienda hacer guardados en las

ramas NO principales cada hora aproximadamente; estos cambios serán

vertidos a la rama principal una vez que ya hayan sido testeados y

validados.

4. Comentarios descriptivos. - Es importante agregar a cada commit un

mensaje que ayude a identificar en que consiste el cambio, esta descripción

toma mayor peso en los commits de la rama principal.

Documentación Cada proyecto desarrollado para la APE, debe contener un documento de arquitectura con el

siguiente contenido:

• Vista funcional

Esta sección debe contener la información que se recolecto y analizó para la definición del

proyecto como pueden ser casos de uso, diagramas de secuencia, diagramas de actividad,

entre algunos otros diagramas que hayan servido para definir todo lo necesario para crear el

proyecto.

• Vista lógica



pág. 34

Sección en la que se debe almacenar información importante para el mantenimiento del

proyecto, esta sección es indispensable en la documentación, contiene:

o Diccionario de datos

o Diagrama de clases

o Diagrama de componentes

o Requisitos de software

o Herramientas de desarrollo

Normas generales de maquetación Para la maquetación de sistemas de la APE, debe hacerse uso de Bootstrap, ya que nos provee

de todas las reglas CSS para que el sitio web se adapte de manera dinámica a la mayoría de las

pantallas.

Tabla 14 Tamaños de pantallas a considerar

Librerías

La DGTID plantea las siguientes librerías para uso en la creación del frontend de sistemas:

⚫ Formularios

▪ Bootstrap DatePicker

▪ Bootstrap Select

▪ Icheck

⚫ Íconos

▪ Font Awesome

⚫ Tablas

▪ DataTables

Pantallas grandes 1200 px Pantallas medianas 992 px Tabletas 768 px Pantallas móviles 576 px



pág. 35

Es indispensable almacenar las librerías dentro del proyecto, evitar el uso de versiones beta

y priorizar el uso de la versión más reciente y estable.

Login

1. Contenido

El login deberá ir al centro de la página con fondo gris de no más de 20% de opacidad relacionado con el sistema o con la imagen institucional del estado.

Contiene 5 elementos principales:

1. Logo del sistema, logo de Oaxaca o escudo del gobierno del estado 2. Usuario; 3. Contraseña; 4. Captcha (recomendado) y 5. Botón de entrada.

Dichos elementos deben ser mostrados en el mismo orden en que fueron listados como se muestra en la siguiente imagen.

Imagen 1 Login de sistema de la APE

2. Tamaños

Los tamaños que se deben respetar son los siguientes:



pág. 36

LOGIN

Logo de Sistema

Tabla 15 Tamaños de elementos de Login.

Sistema

El Sistema deberá contar con el mismo tipo de fondo que el del login de no más de 15% de opacidad.

El logo del sistema se colocará en la parte superior derecha; seguido del menú principal; el usuario y herramientas se colocará en la parte superior izquierda.

Logo del

sistema

Menú Principal

Usuario / Herramientas

460px

Max 150px

Max 220 px

usuario

Max 220 px

contraseña

Min 100 px

Botón de entrada

50px



pág. 37

Contenido del sistema Mínimo 1200px de ancho

Imagen 2 Medidas pantalla general de sistema

Imagen 3 Ejemplo de fondo y menú de sistema de la APE

Opcionalmente puede colocar el menú principal en la parte izquierda

de la página con un ancho de 220px como máximo.

50px

50px



pág. 38

Logo del sistema

Usuario / Herramientas

Menú Principal

Contenido del sistema

Tabla 16 Menú lateral

Botones

Los estilos de los botones deben ser consistentes en todo el sistema y apegarse a la paleta

de colores establecida en este documento.

Botones Primarios Botones Secundarios

Tipo de Botón

Código textos, Fondos y bordes

Código

botón Principal #622779 botón #D8C9DD botón

botón Principal #8D3B88 botón #E3CEE1 botón

botón Alerta #C4131B botón #F0C4C6 botón

botón Secundario #D60071 botón #F5BFDB botón

botón Alerta #E8550D botón #F9D5C3 botón

botón Alerta #E6AD2F botón #F9EACB botón

botón Secundario #8CC026 botón #E2EFC9 botón

botón Secundario #1F934C botón #C7E4D2 botón

botón Principal #00A097 botón #BFE7E5 botón

botón Principal #545454 botón

Secundario #828282 botón Imagen 4 Paleta de colores para botones

220px



pág. 39

Tipografía

Títulos y menú

La fuente tipográfica oficial para los títulos y menú principal es “UNIVIA PRO” en todas sus

versiones Regular Bold.

Univia Pro Regular

ABCDEFGHIJKLMNÑOPQRSTUVWXYZ

abcdefghijklmnñopqrstuvwxyz

1234567890

Univia Pro Bold



1234567890

Imagen 5 Fuente para títulos y menú

Contenido

La fuente tipográfica oficial para el contenido de los sistemas de la APE es “OPERA SANS”.

Imagen 6 Fuente para contenido de sistema

Open Sans Regular



1234567890

Open Sans Bold



1234567890



pág. 40

íconos

Los sistemas de la APE deberán utilizar la fuente Font Awesome para íconos y tipografías

personalizadas.

Paleta de colores

La paleta de colores diseñada para los sistemas de la APE es una variante de la paleta cromática

del manual institucional del Gobierno del Estado de Oaxaca para su aplicación en la WEB.

Títulos y mensajes Los sistemas por crear deben proporcionar una idea clara de lo que se está

realizando mediante interacción con el usuario con mensajes que contengan

textos breves y claros. Este tipo de interacción es de vital importancia en procesos

con tiempos de ejecución largos.

Adicional al texto puede hacerse uso de colores que permitan identificar el tipo de

mensaje que se está mostrando:

HEXADECIMAL RGB

#622779 98, 39, 121

#8D3B88 141, 59, 136

#C4131B 196, 19, 27

#D60071 214, 0, 113

#E8550D 232, 85, 13

#E6AD2F 230, 173, 47

#8CC026 140, 192, 38

#1F934C 31, 147, 76

#00A097 0, 160, 151

#545454 84, 84, 84

#828282 130,130, 130

Imagen 7 Paleta de colores para Web



pág. 41

Tipo de mensaje Color

éxito #d4edda

Informativo #d1ecf1

Error #f8d7da

Imagen 8 Colores para mensajes

Ejemplo:

Formularios

• Los formularios deben expresar de manera clara mediante el uso del símbolo de asterisco (*) los

campos obligatorios.

• Cualquier error que se detecte como resultado de las validaciones ya sea del lado del cliente o

del servidor deberá ser expresado de manera clara mediante que indiquen al usuario porqué su

captura es incorrecta (imagen 11).

Usuario registrado Usuario registrado

Imagen 10 Uso incorrecto de mensaje Imagen 9 Uso correcto de mensaje



pág. 42

Imagen 11 Ejemplo de formulario

BIBLIOGRAFÍA

Open Web Application Security, (2017). Estándar de Verificación de Seguridad en

Aplicaciones 3.0.1. Recuperado de https://owasp.org/www-pdf-

archive/Est%C3%A1ndar_de_Verificaci%C3%B3n_de_Seguridad_en_Aplicaciones_3.0

.1.pdf.

Web Interactive Builder 5.0 (s.f). Recuperado de

http://www.net2client.net/manual/nuevomanual/Normas_generales_de_desarrollo_de_s

istemas.htm.

http://www.net2client.net/manual/nuevomanual/Normas_generales_de_desarrollo_de_sistemas.htm

http://www.net2client.net/manual/nuevomanual/Normas_generales_de_desarrollo_de_sistemas.htm

2016 - 2022 - gobierno del estado de oaxaca

Documents