Entorno LAMP 2016 del Gobierno de Aragón · No usar funciones dentro de bucles de conteo ..... 32...

Entorno LAMP 2016 del Gobierno de Aragón

Referencia: AST-ESPEC-EspecificacionesTecnicasLAMP2016.doc

Autor: Aragonesa de Servicios Telemáticos

Fecha de creación: 08/08/2016

Última actualización: 09/11/2016

Versión: v1.0

Clasificación: Uso Público

Especificaciones técnicas para el alojamiento de aplicaciones



Ref.: AST-ESPEC-EspecificacionesTecnicasLAMP2016.doc Fecha: 09.11.2016 Versión: v1.0 Pág. 2 de 53

Entidad Pública Aragonesa de Servicios Telemáticos Av. Ranillas, 3 A, 3ª Oficina J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145 www.aragon.es

Contenido

1. INTRODUCCIÓN ................................................................................................................................. 5

2. ARQUITECTURA DE PLATAFORMA TECNOLÓGICA ......... ........................................................... 6

3. ESTRUCTURA DE UN PROYECTO................................................................................................... 8

3.1. DIRECTORIOS GENERALES COMUNES A TODOS LOS TIPOS DE PROYECTO .................. 8

3.1.1. Directorio docs/ .......................................................................................................................... 8

3.1.2. Directorio src/ ............................................................................................................................ 8

3.1.2.1. Directorio php/ ....................................................................................................................... 9

3.1.2.2. Directorio conf/ ...................................................................................................................... 9

3.1.3. Directorio setup/ ........................................................................................................................ 9

3.1.3.1. Manual de instalación ............................................................................................................ 9

3.1.3.2. Scripts de BBDD ................................................................................................................. 10

3.1.4. Ficheros estáticos y temporales .............................................................................................. 11

4. ESPECIFICACIONES DEL ENTORNO ................... ......................................................................... 12

4.1. CAPA FRONTAL ......................................................................................................................... 12

4.2. CAPA MEDIA............................................................................................................................... 12

4.3. CAPA BACK O DE BASE DE DATOS ........................................................................................ 13

4.3.1. Configuración de BBDD .......................................................................................................... 13

5. ESPECIFICACIONES DE DESARROLLO ................. ...................................................................... 15

5.1. VERSIÓN DE PHP ...................................................................................................................... 15

5.2. CÓDIGO DE APLICACIÓN ......................................................................................................... 15

5.3. VERSIÓN DE LA APLICACIÓN .................................................................................................. 15

5.4. CARPETAS DE LA APLICACIÓN EN EL SERVIDOR WEB ...................................................... 16

5.5. USO DE NUEVOS FRAMEWORKS ........................................................................................... 17

5.6. INTEROPERABILIDAD ............................................................................................................... 17

5.7. LOGS ........................................................................................................................................... 17

5.8. GESTIÓN DE USUARIOS ........................................................................................................... 17

5.8.1. Usuarios de aplicación ............................................................................................................ 17

5.8.2. Usuarios de Base de Datos ..................................................................................................... 18

5.9. DEFINICIÓN/CREACIÓN DE BASE DE DATOS ........................................................................ 18

6. OBLIGACIONES Y RECOMENDACIONES ................. .................................................................... 19

6.1. CODIFICACIÓN .......................................................................................................................... 19

6.1.1. Guía de estilo de código .......................................................................................................... 19

6.1.2. Estilo ........................................................................................................................................ 20

6.1.2.1. Indentación .......................................................................................................................... 20






6.1.2.2. Longitud de la línea ............................................................................................................. 20

6.1.2.3. Terminación final ................................................................................................................. 20

6.1.2.4. Demarcación de código en PHP ......................................................................................... 20

6.1.2.5. Manejo de cadenas ............................................................................................................. 20

6.1.2.6. Manejo del Array ................................................................................................................. 21

6.1.2.7. Llamadas a función ............................................................................................................. 21

6.1.2.8. Estructuras de control ......................................................................................................... 21

6.1.3. Nomenclatura .......................................................................................................................... 22

6.1.3.1. Clases.................................................................................................................................. 22

6.1.3.2. Clases Abstractas ............................................................................................................... 22

6.1.3.3. Interfaces ............................................................................................................................. 22

6.1.3.4. Nombre de ficheros ............................................................................................................. 22

6.1.3.5. Funciones y Métodos .......................................................................................................... 22

6.1.3.6. Variables.............................................................................................................................. 23

6.1.3.7. Constantes .......................................................................................................................... 23

6.1.4. Ficheros ................................................................................................................................... 23

6.1.4.1. Nomenclatura de ficheros ................................................................................................... 23

6.1.4.2. Subida de ficheros ............................................................................................................... 24

6.1.4.3. Bibliotecas ........................................................................................................................... 24

6.1.5. Gestión de dependencias ........................................................................................................ 24

6.1.5.1. Composer y Packagist ........................................................................................................ 24

6.1.5.2. PEAR ................................................................................................................................... 25

6.1.6. Verificaciones SonarQube ....................................................................................................... 25

6.1.6.1. Crítica .................................................................................................................................. 25

6.1.6.2. Mayor................................................................................................................................... 27

6.1.6.3. Menor .................................................................................................................................. 31

6.1.6.4. Info ....................................................................................................................................... 32

6.1.7. Buenas prácticas ..................................................................................................................... 32

6.1.7.1. No sobrecargar métodos ..................................................................................................... 32

6.1.7.2. No usar funciones dentro de bucles de conteo ................................................................... 32

6.1.7.3. Declarar los métodos estáticos ........................................................................................... 32

6.1.7.4. Utilizar la variable $_SERVER [ ’REQUEST_TIME’ ] ......................................................... 33

6.1.7.5. Utilizar foreach() en los bucles de colecciones y arrays ..................................................... 33

6.1.7.6. Utilizar strpos() para las búsquedas de subcadenas .......................................................... 33

6.1.7.7. Realizar preincremento de las variables ............................................................................. 33

6.1.7.8. Realizar depuraciones de código ........................................................................................ 33

6.1.7.9. Variables globales ............................................................................................................... 33

6.2. DOCUMENTACIÓN .................................................................................................................... 34

6.2.1. Ficheros ................................................................................................................................... 34

6.2.2. Clases ...................................................................................................................................... 34

6.2.3. Funciones ................................................................................................................................ 34

6.3. BASES DE DATOS ..................................................................................................................... 35

6.3.1. Extensiones ............................................................................................................................. 35

6.3.1.1. MySQL extensión ................................................................................................................ 35






6.3.1.2. PDO extensión .................................................................................................................... 35

6.3.2. Inyección SQL ......................................................................................................................... 35

6.4. CACHÉ ........................................................................................................................................ 36

6.4.1. Opcode cache ......................................................................................................................... 36

6.4.2. Caché de objetos..................................................................................................................... 36

6.5. SEGURIDAD ............................................................................................................................... 37

6.5.1. Seguridad en aplicaciones web ............................................................................................... 37

6.5.2. Password Hashing................................................................................................................... 37

6.5.3. Filtrado de Datos ..................................................................................................................... 37

6.5.4. Gestión de la sesión ................................................................................................................ 38

6.5.4.1. Medidas contra la predicción de sesión .............................................................................. 38

6.5.4.2. Medidas contra la captura del identificador a través de ataques XSS ............................... 38

6.5.4.3. Medidas contra la fijación de sesión ................................................................................... 38

6.5.4.4. Medidas contra el eavesdropping ....................................................................................... 38

6.5.4.5. Medidas contra los errores en el cierre de sesión .............................................................. 38

6.5.4.6. Medidas ante aspectos propios de la implementación de la gestión de sesiones de PHP 39

6.5.5. Validación ................................................................................................................................ 39

6.5.6. Archivos de Configuración ...................................................................................................... 39

6.5.7. Informe de Errores................................................................................................................... 40

ANEXO 1: CONFIGURACIÓN PHP......................... ............................................................................. 41

ANEXO 2: SECURIZACIÓN DEL ENTORNO ................. ..................................................................... 50

ANEXO 3: CONVENIO DE NOMENCLATURA DE OBJETOS DE BBD D .......................................... 52






1. Introducción

El presente documento define las especificaciones técnicas a seguir por toda aplicación que se despliegue en la arquitectura LAMP del Gobierno de Aragón.

Con el objetivo de facilitar la labor de desarrollo, integración y despliegue, el documento divide el escenario en varias partes diferenciadas:

� Parte I: Arquitectura. Breve descripción de todos los componentes que forman parte de la arquitectura del sistema, balanceo, servidor de aplicaciones, capa de datos,..

� Parte II: Estructura de un proyecto. Estructura organizativa que deben cumplir los desarrollos LAMP.

� Parte III: Especificaciones del entorno. Configuración del entorno de servidores del Gobierno de Aragón.

� Parte IV: Especificaciones de desarrollo. Directrices que se deben seguir en el desarrollo de aplicaciones LAMP para albergar desarrollos en los servidores del Gobierno de Aragón.

� Parte V: Obligaciones y recomendaciones. Recomendaciones y fundamentos para la codificación y aspectos de seguridad en los servidores del Gobierno de Aragón.

El documento va complementado con varios anexos con información más específica a modo de complemento.






2. Arquitectura de plataforma tecnológica

A continuación se detalla la arquitectura tecnológica para la plataforma LAMP en el Gobierno de Aragón. El objetivo es que antes de comenzar los desarrollos se tenga en cuenta el entorno final, de forma que se eviten conflictos a la hora de la puesta en producción de las aplicaciones.

Existen 3 entornos disponibles en los que se instalarán las aplicaciones de forma secuencial:

1. Integración: entorno para realizar el primer despliegue de la aplicación, además de pruebas básicas de funcionamiento.

2. Preproducción: entorno idéntico al de producción que facilitará la realización de las pruebas previas al paso a producción (integración, validación de usuario, carga, etc.).

3. Producción: entorno final.

El escenario que detallaremos a continuación define la estructura del entorno de producción, siendo el entorno de preproducción idéntico tanto en componentes como en configuración. Del mismo modo, el entorno de integración sirve para comprobar que la aplicación funciona adecuadamente y garantizar que las versiones de los productos coinciden con el escenario que nos vamos a encontrar en el entorno de producción.

La arquitectura tecnológica del Gobierno de Aragón está organizada en base a una estructura de 3 capas (frontales web, capa media y capa de base de datos).

Diagrama arquitectura LAMP (entorno de producción)






La nomenclatura de los servidores sigue estos criterios:

CAPA ENTORNO TIPO MÁQUINA

f- frontal

m-media

b-back

o – pro ducción

e – preproducción

i – integración

f–físico

l – virtual ldom

v-virtual vmware

De esta forma el prefijo “mov” en mov-lamp2016-01 sería:

m - Capa Media / o - Producción / v - Virtual

La siguiente tabla muestra la relación de los productos instalados divididos por capa en el entorno de producción:

Descripción Componente (arquitectura) Máquina Sistema operativo Descripción detallada

Capa f rontal Apache 2.2 fov-apache-01, fov-apache-02

Red Hat Enterprise Linux 6.4 (x86_64)

Apache Web Server con ProxyPass

Capa media Apache 2.4.6 mov-lamp2016-01 Red Hat Enterprise Linux Server release 7.2 (Maipo)

Apache web server con PHP 5.4.16 como módulo

Capa back MariaDB 5.5.47 bov-lamp2016-01 Red Hat Enterprise Linux Server release 7.2 (Maipo)

Servidor MariaDB, puerto 3306






3. Estructura de un proyecto

Todo proyecto que se entregue para ser desplegado en los servidores del Gobierno de Aragón debe tener una estructura determinada y cumplir con una serie de especificaciones que se detalla a continuación.

3.1. Directorios generales comunes a todos los tipo s de proyecto

Existe una serie de directorios que nos vamos a encontrar en todos los tipos de proyectos.

Los directorios que aparecen siempre en los proyectos son:

Directorio Contenido

docs/ Contiene toda la documentación relativa a un proyecto

src/ Dentro de este directorio se incluyen dos subdirectorios:

• “php” donde ubicamos los ficheros fuente • “conf ”, que contendrá los ficheros de configuración a parametrizar por entorno.

setup/ Este directorio contiene ficheros relacionados con la instalación del sistema, por ejemplo, manual de instalación, ficheros de creación de la base de datos, etc.

NOTA: es imprescindible la entrega de un manual de instalación adecuado a la versión de la aplicación junto a los ficheros fuentes de la misma.

3.1.1. Directorio docs/

Contiene toda la documentación relacionada con el proyecto: documentación técnica, manuales de usuario, manual de explotación, etc.

3.1.2. Directorio src/

Este directorio almacena dos carpetas: la carpeta php , que contiene la aplicación web y la carpeta conf, que contiene la configuración de la misma, parametrizable por entornos.






3.1.2.1. Directorio php/

Contiene los fuentes de la aplicación web . Los ficheros ubicados en esta carpeta serán copiados a la carpeta document root del virtual host de apache en los distintos entornos.

3.1.2.2. Directorio conf/

Dentro de este directorio se distribuirán todos los ficheros susceptibles de parametrización de un entorno a otro, como por ejemplo, el acceso a fuentes de datos, WebServices o configuración genérica de la aplicación. Estos ficheros no deben tener un formato determinado, pero sí contener las propiedades comunes que queremos utilizar en la aplicación, evitando así valores “hardcodeados” dentro de la misma.

Salvo parámetros que el proveedor desconoce y no pueden ser facilitados, como pueden ser accesos o contraseñas a distintas URLs de la DGA, todos los demás parámetros deben ser informados correctamente en cada fichero según el entorno para el que estén definidos.

Estos ficheros se deberán entregar por triplicado, uno por cada uno de los entornos de ejecución de las aplicaciones (integración, preproducción, producción), de forma que el proveedor entregue la aplicación una única vez por versión . Desde despliegue, a medida que la aplicación vaya pasando por los distintos entornos, se ajustarán los parámetros de acuerdo con este y se copiarán el/los fichero/s dentro de su ruta en src/php (ruta especificada en el manual de instalación).

NOTA: una misma entrega parametrizable se utilizará para el paso de la aplicación por los tres entornos. En ningún caso se aceptarán para una misma versión entregas diferentes o con alguna corrección para preproducción o producción.

Cualquier cambio en ficheros que no tenga que ver con la parametrización deberá generar una nueva versión y, por consiguiente, una nueva entrega.

3.1.3. Directorio setup/

Contiene toda la información para la puesta en marcha de la aplicaci ón . No debe faltar el siguiente contenido:

3.1.3.1. Manual de instalación

Debe incluir obligatoriamente:

� Descripción de la aplicación y pasos para su instalación en cada entorno.

� Si es necesario que la aplicación se ejecute bajo http o https.

� Instrucciones de creación de directorios en el servidor, como por ejemplo, directorios de almacenamiento de ficheros temporales.

� Explicación de los ficheros de configuración distribuidos bajo el directorio src/conf/ y valores que es necesario parametrizar para que la aplicación funcione correctamente






en los entornos del Gobierno de Aragón. También se indicará la ubicación de los mismos dentro de src/php.

� Creación de alias o directorios virtuales en el servidor web, en caso de ser necesario.

� Si se trata de una subida de versión, relación de cambios implementados respecto a la versión anterior.

NOTA: cualquier relación de dependencia de la aplicación con otros módulos, plataformas comunes, plataformas de autenticación propias de algún Departamento, directivas específicas a aplicar en el virtualhost de apache, etc, deberá ser indicada explícitamente en el manual de instalación.

NOTA: cualquier ausencia de lo indicado anteriormente implicará el rechazo de las peticiones de despliegue hasta su subsanación.

3.1.3.2. Scripts de BBDD

NOTA: en todas las entregas se deberá incluir un manual con las instrucciones de ejecución de los scripts, así como las posibles acciones en caso de errores (continuar la ejecución o no, ejecutar scripts de borrado o regresión, etc...).

Los componentes para la instalación o modificación de la base de datos se proporcionarán en scripts SQL que deben poder ser re-ejecutados, para lo cual se proporcionarán scripts para el borrado de los objetos y/o vaciado de tablas.

Es obligatorio proporcionar scripts separados para:

� Creación de tablas

� Creación de claves ajenas (relaciones)

� Creación de índices

� Creación de vistas

� Creación de triggers

� Creación de procedimientos y funciones

� Scripts para carga inicial de datos

� Otros

NOTA: no se deben incluir scripts para la creación de usuarios. Para tal fin existen formularios de solicitud de usuarios/bases de datos.






3.1.4. Ficheros estáticos y temporales

Si la aplicación necesita directorios para ubicar ficheros generados por la propia aplica ción ya sean temporales o no, debe indicarse en el manual de instalación.

La ubicación de estos ficheros en el servidor se especifica en el apartado “Carpetas de la aplicación en el servidor web” de este mismo documento.

NOTA: siempre que sea necesario actualizar estos ficheros, deberá indicarse en el Manual de Instalación de la versión correspondiente.






4. Especificaciones del entorno

A continuación se detallan las características de la capa frontal y media, fundamentales para el desarrollo y despliegue de aplicaciones.

4.1. Capa frontal

Está compuesta de dos servidores Apache HTTP Server 2.2 con ProxyPass, que redirigen a la capa media. La distribución de máquinas por entorno es la siguiente:

Entorno Máquina s

Integración fiv-apache-01.aragon.local

Preproducción fev-apache-01.aragon.local, fev-apache-02.aragon.local

Producción fov-apache-01.aragon.local, fov-apache-02.aragon.local

4.2. Capa media

Está compuesta de un servidor Apache versión 2.4.6 con PHP 5.4.16 instalado como módulo. La distribución de máquinas por entorno es la siguiente:

Entorno Máquina

Integración miv-lamp2016-01.aragon.local

Preproducción mev-lamp2016-01.aragon.local

Producción mov-lamp2016-01.aragon.local

Los subdominios DNS están definidos de forma que las URLs de las aplicaciones sean las siguientes, dependiendo si se debe habilitar o no el acceso por protocolo seguro:

Entorno APACHE

Integración http://desaplicaciones.aragon.es/[app] https://desaplicaciones.aragon.es/[app]

Preproducción http://preaplicaciones.aragon.es/[app] https://preaplicaciones.aragon.es/[app]

Producción http://aplicaciones.aragon.es/[app] https://aplicaciones.aragon.es/[app]

En caso de necesitar una URL diferente debe contactar con Aragonesa de Servicios Telemáticos.

Si dispone de un subdominio [app].aragon.es las urls de las aplicaciones tendrán el siguiente formato: http(s)://[des|pre][app].aragon.es . En caso que no tenga y sea necesario, puede solicitarlo -previa justificación- al Servicio de Administración Electrónica para su autorización administrativa.






4.3. Capa back o de base de datos

La capa back se encuentra implementada con MariaDB 5.5.47 . El puerto por el cual escucha MariaDB es el 3306, esto es importante a la hora de configurar la conexión en la aplicación.

NOTA: el valor del puerto nunca debe ir ‘hardcodeado’ en la aplicación, debe incluirse como parámetro dentro de un fichero de configuración.

La distribución de máquinas por entorno es la siguiente:

Entorno Máquina

Integración biv-lamp2016-01.aragon.local

Preproducción bev-lamp2016-01.aragon.local

Producción bov-lamp2016-01.aragon.local

4.3.1. Configuración de BBDD

Estos son algunas variables de configuración del servidor MariaDB

Se han aplicado los siguientes cambios:

� Establecidos character_set_database y character_set_server a utf8

� El valor de data_dir es /opt/mysql/data

� Desactivados los binary_logs

� Asignados en el fichero /etc/my.cnf los siguientes valores:

user=mysql old_passwords=1 lower_case_table_names=1 character-set-server=utf8

VARIABLE VALOR

open_files_limi t 2500

max_connections 500

innodb_buffer_pool_size 8388608

key_buffer_size 8384512

max_connections 500

tmp_table_size 33554432

have_innodb YES

innodb_data_file_path ibdata1:10M:autoextend






collation-server=utf8_general_ci skip-character-set-client-handshake port=3306 log_slow_queries = slow-queries.log open_files_limit=2500 max_connections=500 tmp_table_size=33554432






5. Especificaciones de desarrollo

Previamente al desarrollo de una nueva aplicación deberá asegurarse de que se está en posesión de la última versión disponible del documento de especificaciones.

5.1. Versión de PHP

La versión de PHP instalada en todos los entornos es la 5.4.16. Puede encontrar más detalle sobre la configuración y las extensiones habilitadas en el Anexo “Configuración PHP” de este mismo documento.

NOTA: si su aplicación requiere de una extensión que no está instalada en el servidor, debe ponerse en contacto con AST antes de solicitar el despliegue de la misma. Tenga en cuenta que es posible que no se autorice dicha extensión, lo que implicaría trabajo adicional en el desarrollo. Se recomienda el uso de las extensiones instaladas exclusivamente.

5.2. Código de Aplicación

Toda aplicación desplegada en los servidores del Gobierno de Aragón debe estar registrada en la base de datos de “Gestión de la configuración” (CMDB). Por ello, es necesario que el código de aplicación sea único y el nombre suficientemente de scriptivo para poder identificarla.

NOTA: El código será alfanumérico, preferiblemente de 3 ó 4 caracteres y, generalmente, estará formado por las iniciales del nombre de la aplicación. Será acordado entre la empresa desarrolladora y el grupo de [email protected] al comienzo del proyecto.

5.3. Versión de la aplicación

En la página inicial de la aplicación, deberá hacerse referencia, a modo informativo, a la versión correspondiente de la misma.






5.4. Carpetas de la aplicación en el servidor web

Cada aplicación dispondrá de la siguiente estructura de directorios :

Estructura de directorios asociados a la aplicación dentro del servidor web

� Directorio html , corresponde al “document root” del virtual host asociado al sitio. A este directorio se copiará el contenido de src/php del entregable.

� Directorio ficheros , esta carpeta almacenará ficheros generados por la aplicación y el servidor web tendrá permisos de lectura y escritura sobre ella. La ruta a la carpeta debe estar parametrizada en el fichero de configuración, siempre y cuando se haga uso de ella. Distinguiremos entre dos tipos:

Temporales: se almacenarán en la subcarpeta tmp . Son generados y usados en un momento puntual por la aplicación. Deberán ser eliminados tras su uso por la misma, de lo contrario, con el paso del tiempo, pueden llegar a ocupar excesivo espacio en disco y su contenido podría ser susceptible de eliminarse en tareas de liberación de espacio en disco.

Estáticos: se almacenarán en la subcarpeta datos . Son aquellos que son generados o no por la aplicación y cuyo uso perdura en el tiempo.

� Directorio logs , almacenará los siguientes ficheros:

access.log, registro de accesos de Apache

error.log, registro de errores de Apache.

ssl_access.log, registro de accesos https de Apache, si SSL está activado

ssl_error.log, registro de errores https de Apache, si SSL está activado

php.log, registro de errores php.






5.5. Uso de nuevos frameworks

Se permitirá el uso de cualquier framework que cumpla las siguientes condiciones:

� Debe ser compatible con la versión PHP 5.4.16.

5.6. Interoperabilidad

Para la realización de webservices, deberán cumplirse las especificaciones marcadas en el documento “AST-ESPEC-InteroperabilidadTecnicaWS.pdf”.

5.7. Logs

Para cada aplicación, el servidor generará por defecto estos ficheros de log en la ruta app/logs/: access.log, error.log, ssl_access.log, ssl_errorlog y php.log. Si la aplicación necesita generar logs adicionales, deberá utilizar un sistema de log que escriba en esta ruta. La rotación de logs es diaria, de esta forma se tendrá un histórico del log almacenado por día, lo que facilita su consulta y envío al proveedor en caso de ser solicitados.

NOTA: si la aplicación necesita generar logs específicos, al margen de los generados por defecto, debe indicarlo en el manual de instalación.

A continuación mostramos la configuración del nivel de log en los distintos entornos:

Entorno Directiva LogLevel (Apache) Nivel log PHP

Integración warn E_ALL & ~E_DEPRECATED & ~E_STRICT

Preproducción warn E_ALL & ~E_DEPRECATED & ~E_STRICT

Producción warn E_ALL & ~E_DEPRECATED & ~E_STRICT

5.8. Gestión de usuarios

En referencia a la gestión de usuarios, distinguiremos entre usuarios de aplicación y usuarios de base de datos.

5.8.1. Usuarios de aplicación

Para la autenticación/autorización de usuarios en las aplic aciones , alternativamente a la implementación de un sistema propio, existen varias soluciones con las que integrarse:

� LDAP: todo empleado del Gobierno de Aragón dispone de una cuenta en el directorio LDAP corporativo.

� Autoregistro: para escenarios de usuarios externos (ciudadanos/empresas).






NOTA: La utilización de estas plataformas deberá solicitarse previamente a AST a través del gestor de la aplicación e indicarse claramente en el Manual de Instalación de la aplicación.

5.8.2. Usuarios de Base de Datos

La aplicación utilizará por lo general un usuario para conectarse a la base de datos. Este tendrá asignados una serie de privilegios en función de las necesidades de la aplicación. Será nombrado con el código de aplicación seguido de “US ER” (APP_USER).

Deberá indicarse en el manual de instalación el/los usuarios a crear y los privilegios asociados a los mismos. El grupo de despliegue se encargará de gestionar la creación de dichos usuarios.

5.9. Definición/Creación de Base de Datos

El conjunto de especificaciones técnicas a tener en cuenta en el diseño físico de la base de datos se detalla en el convenio de nomenclatura adjunto en el Anexo “Convenio de nomenclatura de objetos de BBDD”, basado en el código de aplicación que deberá ser solicitado al inicio del proyecto.






6. Obligaciones y recomendaciones

6.1. Codificación

Se deben tener en cuenta los fundamentos indicados por PHP para su codificación cumpliéndose obligatoriamente al menos los indicados en el apartado “Verificaciones SonarQube” incluidas en este documento.

6.1.1. Guía de estilo de código

Se ha de adherir a un estilo de código común para facilitar el trabajo de los desarrolladores al combinar una variedad de librerías para los proyectos.

El Framework Interop Group (antes conocido como el ‘PHP Standards Group’) ha propuesto y aprobado una serie de recomendaciones de estilo conocidas como PSR-0, PSR-1, PSR-2 y PSR-4.

Se recomienda escribir código PHP que se adhiera a uno o más de estos estándares. Puede ser cualquier combinación de PSR, o uno de los estándares de codificación hechos por PEAR o Zend.

� Más acerca de PSR-0




� Más acerca de los Estándares de Codificación de PEAR

� Más acerca de los Estándares de Codificación de Zend

� Más acerca de los Estándares de Codificación de Symfony

Para verificar que el código construido cumple estas recomendaciones puede utilizarse PHP_CodeSniffer y para obtener un análisis en tiempo real pueden usarse plugins para editores de texto como Sublime Text.

Para modificar la sintaxis de código automáticamente y que quede conforme a estos estándares puede utilizarse:

� PHP Coding Standards Fixer (Fabien Potencier),

� php.tools (popularizado como plugin del editor sublime-phpfmt).

Se prefiere la utilización del inglés para los nombres de símbolos e infraestructura del código.

6.1.2. Estilo

6.1.2.1. Indentación

La indentación debe consistir en 4 espacios . Las tabulaciones no están permitidas.

6.1.2.2. Longitud de la línea

Lo recomendable es mantener líneas que como máximo tengan de longitud 80 caracteres . Si en circunstancias especiales no es posible, el tamaño máximo permitido para una línea de PHP es de 120 caracteres .

6.1.2.3. Terminación final

La terminación de la línea sigue la convención del archivo UNIX. Las líneas deben finalizar con un salto de línea única (LF) .

6.1.2.4. Demarcación de código en PHP

No se deben utilizar atajos-uso abreviado de tags . SI los ficheros solo contienen código PHP la etiqueta de cierre puede ser omitida. El código siempre debe comenzar delimitado por las etiquetas PHP como en el ejemplo siguiente;

<?php ?>

6.1.2.5. Manejo de cadenas

� Literal (no contiene substituciones) se marca la cadena entre comillas simples .

$a = 'Example String';

� Cadena que incluye diferentes apóstrofes: debe de marcarse con comillas dobles.

$sql = "SELECT id, name from people WHERE name='Fre d' OR name='Susan'";

� Substituciones de variables: deben reflejarse de alguna de estas dos maneras

$greeting = "Hello $name, welcome back!"; $greeting = "Hello {$name}, welcome back!";

� Concatenación de cadenas: debe utilizar el operador ".". Se debe de añadir un espacio delante y posteriormente al operador

$company = 'Zend' . ' ' . 'Technologies';

Es aconsejable dividir la instrucción en varias líneas para mejorar la legibilidad. En este caso cada línea utiliza el operador "."

$sql = "SELECT id, name FROM people “ . “WHERE name = 'Susan' “ . “ORDER BY name ASC ";

6.1.2.6. Manejo del Array

Un array con un índice debe de comenzar situando el mismo a 0 . No está permitido utilizar números negativos. Cuando el array se declara utilizando el constructor, se debe dejar un espacio tras cada delimitador para mejorar la legibilidad:

$sampleArray = array(1, 2, 3, "ispCP");

También está permitido declarar arrays inicializados mediante el constructor. En este caso, cada línea sucesiva debe alinearse con la superior de la siguiente manera:

$sampleArray = array( 1, 2, 3, "ispCP", $a, $b, $c, 56.44, $d, 500 );

6.1.2.7. Llamadas a función

Las funciones deben invocarse sin espacios entre el nombre de la funció n, el paréntesis de apertura y el primer parámetro . Después deben situarse comas entre cada parámetro y no existir espacios entre el último parámetro, el último paréntesis y el punto y coma final.

<?php $var = foo($bar, $baz, $quux); ?>

6.1.2.8. Estructuras de control

Esto incluye a las instrucciones de tipo if, for, while, switch. Las instrucciones de control deben tener un espacio entre la palabra reservada del control y el paréntesis . De esta manera se distinguen de las llamadas a funciones. Un ejemplo de una instrucción if es la siguiente:

<?php if ((condition1) || (condition2)) { action1; } elseif ((condition3) && (condition4)) { action2; } else { defaultaction; } ?>






6.1.3. Nomenclatura

6.1.3.1. Clases

Los nombres de clases sólo pueden contener caracteres alfanuméricos . Se desaconseja el uso de números dentro de la nomenclatura de clases.

Si se utiliza más de una palabra para el nombre de una clase, es necesario poner en mayúscula la primera letra de cada palabra. El resto de las letras no pueden indicarse en mayúsculas.

La clase "Rcci_Genera_PDF" no está permitida La clase "Rcci_Genera_Pdf" está permitida

6.1.3.2. Clases Abstractas

En general, las clases abstractas siguen las mismas consideraciones que las clases, pero con una regla adicional: deben terminar con la palabra "Abstract" . Este sufijo no puede ir precedido de guión bajo.

La clase Zend_Controller_Plugin_Abstract es conside rada como inválida La clase Zend_Controller_PluginAbstract sería válid a.

6.1.3.3. Interfaces

Las interfaces siguen la misma convención que las clases con la única regla adicional que deben finalizar con la palabra "Interface" . Este sufijo no puede ir precedido de guión bajo.

La interfaz Zend_Controller_Plugin_Interface es con siderada inválida La interfaz Zend_Controller_PluginInterface es cons iderada como válida

6.1.3.4. Nombre de ficheros

Para todos los ficheros, sólo los caracteres alfanuméricos, guiones bajos y el guión normal están permitidos. Los espacios están estrictamente prohibidos . Todos los ficheros que contienen código PHP terminan con la extensión ".php", con la excepción de la vista de los scripts.

6.1.3.5. Funciones y Métodos

Los nombres de las funciones sólo pueden contener caracteres alfanuméricos . Los guiones bajos no están permitidos y el uso de los números es desaconsejable. Las funciones siempre comienzan en minúsculas. Si una función tiene más de una palabra, cada palabra a excepción de la primera debe de comenzar en mayúsculas. Es recomendable dar un nombre a la función que describa su funcionalidad y su comportamiento

// Ejemplos de funciones filtradoEntrada() getElementoPorId()






En la programación orientada a objetos, los métodos que acceden a los objetos deben ser siempre prefijados por "get" o "set ". Cuando se usan patrones de diseño , tales como singleton o factory , el nombre del método debería contener el nombre del patrón para facilitar la lectura del código.

Las funciones de ámbito global están permitidas, pero se desaconseja su uso. Se recomienda que estas funciones se encapsulen en clases estáticas.

6.1.3.6. Variables

Los nombres de las variables solo pueden contener caracteres alfanuméricos . Los guiones bajos no están permitidos y el uso de los números es desaconsejable.

Para las variables que son declaradas con el modificador "private" o "protected", el primer carácter debe de ser un simple guion bajo. Las variables declaradas como públicas nunca comenzarán con guion bajo. Las variables siempre comenzarán con una letra en minúscula y seguir la convención de mayúsculas "camelCaps ".

Se recomienda que los nombres de las variables sean tan descriptivos como sea posible, para facilitar el entendimiento del código. Los nombres de variables como "$i" y "$j" están desaconsejados para otro contexto que no sean bucles sencillos. Si un bucle contiene más de 20 líneas de código, los nombres de las variables índices, deben tener nombres más descriptivos

6.1.3.7. Constantes

Los nombres de las constantes sólo pueden contener caracteres alfanuméricos . Si el nombre de la constante está compuesto por varias palabras, éstas deben de ir separadas por guion bajo (_). Se permite el uso de números pero se desaconseja su uso. Todos los caracteres de las constantes deben ser escritos siempre en mayúsculas.

Las constantes deben ser definidas como miembros de una clase con la palabra clave "const ". La definición de constantes de ámbito global está permitida con "define " pero se desaconseja.

La constantes TEXTO_CARTA_LARGA está permitida, mientras que la constante TEXTO_CARTALARGA no está permitida

6.1.4. Ficheros

6.1.4.1. Nomenclatura de ficheros

� Para revisar los nombres de ficheros se utilizan las funciones realpath() y basename(). La primera convierte direcciones relativas en absolutas y la segunda toma una ruta y devuelve la parte correspondiente al nombre del fichero.

$file = $_POST[‘username’]; $file2 = basename (real path($file)); if ($file2 != $file) die (“$file no es un username válido”); include (“/ usr/local/lib/bienvenida/$file”);






� Se podría limitar las operaciones sobre ficheros a un directorio especificado y sus subdirectorios.

include (“/alguna/ruta/lib.inc”); // permitido include (“/otra/ruta/lib.inc”); // da error

NOTA: por securización del entorno -tal y como se refleja en el Anexo “Securización del entorno”- está desactivada la funcionalidad de acceso a ficheros remotos (allow_url_fopen = off) y definida la directiva open_basedir.

6.1.4.2. Subida de ficheros

� Debe evitar utilizar el nombre enviado por el navegador (podría ser, por ejemplo, /etc/passwd). Es conveniente generar un nombre único para el fichero subido.

� Para limitar el tamaño de los ficheros se utiliza la directiva post_max_size de php.ini.

6.1.4.3. Bibliotecas

� Debe almacenar los ficheros de biblioteca fuera de la raíz de la web para evitar que puedan ser accedidos por su URL e indicar a PHP la ubicación de esos ficheros indicando la ruta completa en los include() y require() o mediante la directiva include_path en php.ini

include_path = “.:/usr/local/php:/usr/local/lib/mya pp”

6.1.5. Gestión de dependencias

Existen gran cantidad de librerías, frameworks y componentes de PHP que pueden ser utilizados en los proyectos: dependencias de proyecto.

Actualmente hay dos sistemas principales de gestión de paquetes para PHP: Composer y PEAR. El uso recomendado es el siguiente:

� Composer: gestionar las dependencias de un solo proyecto.

� PEAR: gestionar las dependencias de todo el sistema de PHP de la plataforma.

6.1.5.1. Composer y Packagist

Solo hay que añadir las dependencias de su proyecto a un archivo llamado composer.json, ejecutar algunos comandos y Composer descargará automáticamente las dependencias para su proyecto y configurará el cargador automático en cuestión de segundos.

Ya existen muchas librerías PHP compatibles con Composer y están listas para su uso. Hay una lista de estos “paquetes” en el sitio Packagist, que es el repositorio oficial de librerías compatibles con Composer.






A tener en cuenta:

1.- Activar la recepción de notificaciones de actualización y nuevas versiones mediante VersionEye.

2.- Revisar las dependencias por actualizaciones de seguridad mediante Security Advisories Checker

� Más acerca de Composer

6.1.5.2. PEAR

Otra alternativa para la gestión de paquetes es PEAR. Su funcionamiento es muy similar al de Composer. También puede utilizarse conjuntamente con Composer.

� Más acerca de PEAR.

� Más acerca de PEAR con Composer.

6.1.6. Verificaciones SonarQube

Se han automatizado verificaciones para garantizar la calidad software del proyecto que va a entregar utilizando la herramienta SonarQube. Debe realizar verificaciones para subsanar los problemas que se detecten. Existen para SonarQube plugins como pmd, checkstyles, findbugs… Para usar estas primeras verificaciones puede descargar el perfil del proyecto SonarQube en la intranet de AST: http://ast.aragon.es.

6.1.6.1. Crítica

� No utilizar la función sleep

Esta función hace que la aplicación sea más vulnerable a los ataques DoS (denegación del servicio).

Ejemplo de código no válido:

if (is_bad_ip($requester)) { sleep(5); // Noncompliant }

� No hardcodear credenciales

Deben ser almacenadas fuera del código encriptadas en un fichero de configuración o en BBDD.

Ejemplo de código válido:

$uname = getEncryptedUser(); $password = getEncryptedPass(); connect($uname, $password);

� No pasar parámetros por referencia

A partir de PHP 5.4.0 utilizar llamadas con parámetros por referencia causará un error fatal.


myfun($name);

� Utilizar break en la sentencia switch

Si no se explicita terminar la ejecución de “case” se continúan ejecutando los casos siguientes. En caso que no se realice intencionadamente debe finalizarse siempre con “break”.


switch ($myVariable) { case 0: // Empty case used to sp ecify the same behavior for a group of cases. case 1: do_something(); break; case 2: // Use of continue state ment continue; case 3: // Case includes a jump statement (exit, return, break &etc) exit(0); case 4: echo 'Second case, which falls through'; // no break <- comment is used when fall -through is intentional in a non-empty case body default: // For the last case, us e of break statement is optional doSomethingElse(); }

� Ubicar al final los argumentos con valor por defect o

Para evitar resultados inesperados y warnings del tipo “Missing argument 2 in call to nombreFuncion()”.

Las sentencias if con condiciones que siempre son false generan bloques de código no funcionales y las que siempre son true son redundantes. Por ello se debe evitar el uso de sentencias if sin condiciones.


if (true) { // Noncompliant doSomething(); } ... if (false) { // Noncompliant doSomethingElse(); }


doSomething();

� No dejar bloques de código vacíos

Los bloques de código vacíos deben ser eliminados. Un bloque que contenga comentarios no se considera vacío.


for ($i = 0; $i < 42; $i++){} // Empty on purpose or missing piece of code ?

� Controlar el número de parámetros en una llamada

Un número excesivo de parámetros indica que pueden resolverse mediante el uso de objetos. No es recomendable realizar llamadas que involucren a más de 7 parámetros .

� No sobrecargar funciones

Se recomienda no realizar funciones con más de 150 líneas .

� No sobrecargar “switch case”

En vez de añadir líneas se debe extraer a una función. El máximo de líneas permitido es 10.

� Evitar comentar bloques de código

Si existen bloques de código que no se utilizan se deben eliminar en vez de comentarlos.

� No variar las condiciones de parada/incremento en “ for”

La condición de parada se establece en una variable local antes de que comience el bucle y no debe modificarse en el cuerpo.


for ($i = 0; $i < 10; $i++) { echo $i; if(condition) {

$i = 20; } }


for ($i = 0; $i < 10; $i++) { echo $i; }

� "if ... else if" debe terminar con una sentencia "e lse"

La última acción debe finalizar siempre con sentencia “else” y no con “else if”.


if (condition1) { do_something(); } else if (condition2) { do_something_else(); } else { throw new InvalidArgumentException('message'); }

� "switch" debe terminar con una sentencia "case defa ult”

Es el mismo caso que la situación anterior.


switch ($param) { case 0: do_something(); break; case 1: do_something_else(); break; default: error(); break; }

� "if”, “for”, “while”, “switch" y “try” no deben ser muy anidadas

La máxima profundidad de anidamiento debe ser 4.

� Eliminar los parámetros no utilizados en una funció n

� “switch” no debe tener demasiadas sentencias “case”

El máximo permitido es 30.

� La llave de apertura “{“ ha de estar al final de la línea

� No usar variables predefinidas deprecadas






Utilizar las que ofrecen en la nueva versión. P.e.:

REPLACE WITH

$HTTP_SERVER_VARS $_SERVER

$HTTP_GET_VARS $_GET

$HTTP_POST_VARS $_POST

$HTTP_POST_FILES $_FILES

$HTTP_SESSION_VARS $_SESSION

$HTTP_ENV_VARS $_ENV

$HTTP_COOKIE_VARS $_COOKIE

� No usar las declaraciones “constructor” de PHP4

En PHP 5 debe utilizarse el método "__construct".

� En las funciones “__construct” PHP5 no usar el esti lo de llamada de PHP4


class Foo extends Bar { function __construct() { parent::__construct(); } }

� Cumplir la nomenclatura en los nombres de clase

� No utilizar la función eval()

Para asegurar que los datos usados en la construcción no han sido manipulados.

� Las clases no deben ser complejas

La máxima complejidad permitida es 200.

� Eliminar cuerpos de código vacíos

� No utilizar el mismo nombre para las variables loca les y las clases

� No usar en llamadas a métodos ni mezclar con otros operadores en expresiones los operadores de incremento (++) y decremento (--)

� No utilizar variables variable

� Utilizar siempre llaves en las estructuras de contr ol

� No utilizar la sentencia “goto”






� Separar las sentencias en líneas diferentes

� Combinar las sentencias “if” y no anidarlas

� Las expresiones no deben ser complejas

El número máximo de operadores condicionales en la expresión es de 3.

� Eliminar los campos “private” declarados y no utili zados

� Las funciones no deben ser complejas

El máximo nivel permitido es de 20.

� Cumplir la nomenclatura en las constantes

� Cumplir la nomenclatura en las variables locales y funciones

� Revisar los tags “FIXME” utilizados

� Las clases no deben tener muchos métodos

El máximo establecido es 20.

� Los ficheros no deben tener muchas líneas

Las máximas líneas permitidas son 1000.

� No duplicar bloques en los fuentes

� Comentar suficientemente los fuentes

La densidad requerida es de 25.0.

6.1.6.3. Menor

� “switch” debe contener tres sentencias “case” mínim o

� No utilizar tabuladores

� No duplicar cadenas de texto

� No declarar variables locales y devolverlas inmedia tamente después

� Colocar la llave de cierre “]” en el principio de u na línea

� Utilizar bucle “while” en lugar de “for”

� No utilizar en expresiones de condición literales b ooleanos

� No devolver expresiones boleanas en sentencias “if- then-else”

6.1.6.4. Info

� No ubicar los comentarios al final de las líneas de código

� Revisar los tags “TODO” utilizados

6.1.7. Buenas prácticas

6.1.7.1. No sobrecargar métodos

Comprobar que los métodos hacen lo que tienen que hacer y no desarrollan una excesiva funcionalidad que provoca que su mantenimiento sea complejo. No es recomendable crear métodos con más de 100 líneas de código.

6.1.7.2. No usar funciones dentro de bucles de cont eo

El siguiente código seguro que funciona, pero el problema es que la función count() que es ejecutada dentro de la iteración del bucle torna penaliza severamente la velocidad del proceso el proceso.

<?php for ($i = 0; $i < count($miArray); $i++) { // Código } ?>

Si calculamos la función fuera del bucle , mejoramos la velocidad en torno a un 600% con respecto a la función inicial.

<?php $total = count($miArray); for ($i = 0; $i < $total; $i++) { // Código } ?>

6.1.7.3. Declarar los métodos estáticos

Si es posible, hay que declarar los métodos como estáticos si van a ser tratados de esta manera. Está probado que se reduce su tiempo de ejecución hasta cuatro veces con respecto a los métodos que no están declarados como estáticos.

6.1.7.4. Utilizar la variable $_SERVER [ ’REQUEST_T IME’ ]

Cuando necesite calcular el tiempo actual dentro de la ejecución del algún script dentro de una aplicación es mucho más eficiente utilizar $_SERVER [ ’REQUEST_TIME’ ] que la función time().

6.1.7.5. Utilizar foreach() en los bucles de colecc iones y arrays

Cuando tenemos una estructura con un bucle destinado a la lectura de un array o una colección está demostrado que es mucho más rápido utilizar foreach() , preferentemente a estructuras del tipo while o for.

// Un ejemplo basado en array Hash con 100 elemento s, 24 byte para claves y 10k datos por cada entrada foreach($aHash as $val) // Tiempo de ejecución + 10 0 % while(list(,$val) = each($aHash) // Tiempo de ejecu ción + 579 %

6.1.7.6. Utilizar strpos() para las búsquedas de su bcadenas

Para realizar la búsqueda de subcadenas dentro de cadenas de texto, la mejor manera de realizarlo es utilizar la función strpos(), preferentemente sobre preg_match() o ereg().

<?php if (strpos($authors, 'Chris') !== FALSE) { echo 'Chris is an author.'; } else { echo 'Chris is not an author.'; } ?>

6.1.7.7. Realizar preincremento de las variables

Realizar un preincremento como ++$i es más rápido que el postincremento $i++ en las variables, así que use el preincremento cada vez que sea posible. El preincremento es casi un 10% más rápido: debe cambiar las instrucciones para que hagan el pre-incremento, sobre todo en los bucles críticos.

6.1.7.8. Realizar depuraciones de código

Errores en el código pueden consumir los recursos dedicados, por ello debe revisar la salida que las páginas producen con el fin de asegurarse de que PHP no está registrando errores.

Existen funciones que aumentan la capacidad de depuración, permitiendo comprobar los scripts sin necesidad de mostrar datos en HTML. Algunas son SitePoint, Xdebug y Scream.

6.1.7.9. Variables globales

En relación a las variables debe:






� Inicializar todas las variables antes de usarlas .

� Evitar la aparición de mensajes de aviso o error (en el entorno de producción).

NOTA: tal y como se refleja en el Anexo “Securización del entorno”, la directiva register_globals tiene el valor off.

6.2. Documentación

Los bloques de documentación deben ser compatibles con phpDocumentor.

6.2.1. Ficheros

Cada fichero que contenga código PHP debe tener un bloque cabecera al comienzo del fichero que contenga estos tags de phpDocumentor como mínimo:

/** * Short description for file * * Long description for file (if any)... * * LICENSE: Some license information * * @copyright 2005 Zend Technologies * @license http://www.zend.com/license/3_0.txt PHP License 3.0 * @version CVS: $Id:$ * @link http://dev.zend.com/package/PackageName * @since File available since Release 1.2.0 */

6.2.2. Clases

Cada clase debe tener un bloque que contenga estos tags de phpDocumentor como mínimo:

/** * Short description for class * * Long description for class (if any)... * * @copyright 2005 Zend Technologies * @license http://www.zend.com/license/3_0.txt PHP License 3 .0 * @version Release: @package_version@ * @link http://dev.zend.com/package/PackageName * @since Class available since Release 1.2.0 * @deprecated Class deprecated in Release 2.0.0 */

6.2.3. Funciones

Cada función o método, debe tener un bloque de documentación que contenga al menos:






� Una descripción de la función

� Todos los argumentos

� Todos los posibles valores de retorno

No es necesario el uso del tag @access ya que el nivel de acceso es conocido por las palabras clave "public", "private", o "protected" usadas para declarar la función.

Si una función o método puede lanzar una excepción debe usarse el tag @throws:

@throws exceptionclass [description]

6.3. Bases de datos

Hasta la versión de PHP 5.1.0 la opción recomendada para conectar con BBDD era utilizar drivers nativos (mysqli, pgsql, mssql…), actualmente la extensión PDO (Objetos de Datos de PHP) se considera la manera más correcta y segura de acceder a cualquier BBDD.

6.3.1. Extensiones

6.3.1.1. MySQL extensión

Extensión muy antigua que ha sido sustituida por:

� mysqli

� pdo

mysql ha sido deprecada en versión PHP 5.5.0 y eliminada en PHP 7.0. Se recomienda la actualización a cualquiera de esas extensiones incluso aunque no se utilice PHP 7.0 sino versiones anteriores.

6.3.1.2. PDO extensión

PDO (PHP Data Objects) se incluye desde la versión 5.1.0 de PHP proporcionando un interfaz común para conectar con diferentes BBDD. Además permite incluir –de forma segura- entradas externas (p.e. IDs) en las sentencias SQL sin tener que preocuparse de ataques a la BBDD.

� Más acerca de PDO.

6.3.2. Inyección SQL

� Validar los valores que se han de integrar en la consulta SQL






� Nunca incluir datos de usuario en la sentencia SQL

� No utilizar mysql_real_escape_string

� Utilizar sentencias preparadas. En caso que no se pudiera debería utilizar el constructor de sentencias del framework o utilizar paquetes proporcionados por Composer-Packagist.

6.4. Caché

Para la mejora del rendimiento se recomienda el uso de diferentes utilidades de caché que mejoren la carga de las páginas del sitio.

6.4.1. Opcode cache

Previene recompilaciones almacenando códigos opcode en memoria y reutilizándolos. Algunas cachés opcode disponibles son:

� OPcache (desde PHP 5.5)

� APC (PHP 5.4 y anteriores)

� XCache

� Zend Optimizer+ (parte del paquete Zend Server)

� WinCache (extensión para MS Windows Server)

� List of PHP accelerators on Wikipedia

6.4.2. Caché de objetos

Importante cuando hay que cachear objetos individuales para almacenarlos en memoria y obtener un acceso rápido a ellos. Las soluciones más populares son: APCu, memcached, XCache y WinCache.

Las más utilizadas son APCu y memcached. APCu es mejor para el cache de objetos, su pega es que se asocia al servidor en que está instalado. Memcached se instala como servicio separado y puede accederse a través de la red, es más indicado para instalaciones de varios servidores.

Se determina pues el uso de Memcached en sistemas distribuidos y en caso contrario APCu.






6.5. Seguridad

6.5.1. Seguridad en aplicaciones web

Debe tomar las precauciones necesarias para mejorar la seguridad de los proyectos.

La comunidad del The Open Web Application Security Project (OWASP) ha compilado una lista completa de problemas de seguridad conocidos y los métodos a seguir para protegerse contra ellos. Esta guía es lectura obligada para cualquier desarrollador.

Leer la Guía de seguridad de OWASP (Disponible solo en inglés)

6.5.2. Password Hashing

Al desarrollar una aplicación PHP que realice una conexión de usuario debe de realizar hash de las contraseñas antes de almacenarlas, ya que si no están hasheadas y accede a la base de datos un tercero no autorizado, todas las cuentas de usuario están comprometidas.

Para ello se ha de utilizar password_hash() . Actualmente utiliza el algoritmo BCrypt, en un futuro soportará algoritmos adicionales.

6.5.3. Filtrado de Datos

Siempre debe sanear y verificar los datos de entrada de la aplicación PHP antes de usarlos en el código. Las funciones filter_var() y filter_input() proporcionan limpieza de los datos y verifican la validez del formato del texto (por ejemplo, las direcciones de correo electrónico).

Los datos de entrada exteriores pueden contener cualquier cosa: datos provenientes de formularios en $_GET y $_POST, algunos valores provenientes del $_SERVER, el cuerpo de la solicitud HTTP vía la función fopen('php://input', 'r'). Han de ser filtrados de diferente manera dependiendo de su propósito.

� Datos sin filtrar a la salida de HTML : se corre el riesgo de ejecutar código sin verificar de HTML o JavaScript en el sitio: Cross-Site Scripting (XSS). Para prevenir estos ataques hay que sanear todas las etiquetas de HTML en los datos de entrada al remover etiquetas o convirtiéndolas en entidades de HTML. Se puede utilizar strip_tags(), htmlentities() o htmlspecialchars().

� Pasar opciones que van a ser ejecutadas en la línea de comando : es extremadamente peligroso. Se puede usar la función escapeshellarg -que viene incluida en PHP- para sanear los argumentos de ejecución de un comando.

� Aceptar la entrada de datos para determinar qué arc hivo necesita cargar del sistema de archivos : debe quitar los caracteres “/”, “../”, bytes nulos y otros de la ruta de archivo para que no permita cargar archivos escondidos, no públicos, o sensitivos.

Más sobre los filtros de saneamiento






6.5.4. Gestión de la sesión

6.5.4.1. Medidas contra la predicción de sesión

� Aleatorización y longitud suficiente del identifica dor de sesión : la configuración por defecto de aleatorización del identificador de sesión es suficientemente buena, pero se pueden añadir fuentes de datos para la generación del identificador mediante session.entropy_file y session.entropy_length para, por ejemplo, utilizar el API de Windows o el archivo /dev/random en sistemas Unix

6.5.4.2. Medidas contra la captura del identificado r a través de ataques XSS

� Las cookies sólo son accesibles a través del protocolo HTTP : está activada la opción session.cookie_httponly.

� Está deshabilitado el método TRACE .

6.5.4.3. Medidas contra la fijación de sesión

� Renovar el identificador al autenticarse el usuario o asignarlo únicamente después de la autenticación: utilizar la función session_regenerate_id, siempre con el parámetro "$delete_old_session = true" para que el identificador de la sesión anterior no sea utilizable.

� Permitir únicamente el identificador en cookies : esta restricción, activa por defecto, se controla mediante la variable session.use_only_cookies.

� Asociar el identificador a información del usuario única como su dirección IP: la dirección IP, que se puede obtener de la variable $_SERVER['REMOTE_ADDR'], puede almacenarse en los datos de sesión, a través de $_SESSION, y simplemente en cada nueva petición comprobar que no ha cambiado. Esta medida no tiene por qué limitarse a la dirección IP, se puede establecer un perfil más detallado a través de acciones comunes, patrones de navegación, localización, etc.

6.5.4.4. Medidas contra el eavesdropping

� Utilizar el protocolo HTTPS .

� Utilizar la opción secure en las cookies de sesión ya que está activada la opción session.cookie_secure.

6.5.4.5. Medidas contra los errores en el cierre de sesión

� Establecer un timeout de sesión . Se puede utilizar un código similar al siguiente para controlar este timeout:

if (!isset($_SESSION['timeout_idle'])) {

$_SESSION['timeout_idle'] = time() + ini_get('session.gc_maxlifetime'); } else { if ($_SESSION['timeout_idle'] < time()) { //destroy session } else { $_SESSION['timeout_idle'] = time() + ini_get('session.gc_maxlifetime'); } }

Se puede delegar esta medida de seguridad en el mecanismo de eliminación de archivos de sesión que no han sido accedidos en el tiempo definido por session.gc_maxlifetime, pero entonces habrá que ajustar su ejecución para que no sea aleatoria y para que dependa de una tarea programada.

� Establecer un tiempo máximo de validez de sesión : este timeout puede ser establecido mediante un código similar al anterior, utilizando el parámetro session.cookie_lifetime, etc.

� Utilizar cookies no persistentes : el tiempo de validez de la cookie se controla mediante el parámetro session.cookie_lifetime que por defecto es 0, lo que significa que no es persistente. Por otro lado, por defecto las cookies están restringidas al dominio y directorio raíz del servidor web (opciones controladas mediante session.cookie_domain y session.cookie_path).

� Invalidar y no reutilizar los identificadores de se sión : cuando se destruye la sesión, mediante session.destroy, se elimina el archivo de sesión, por lo que cuando el usuario acceda de nuevo el servidor web no reconocerá la sesión. Otra cosa a tener en cuenta es invocar session_regenerate_id siempre incluyendo el parámetro "$delete_old_session = true" para inutilizar el identificador anterior.

6.5.4.6. Medidas ante aspectos propios de la implem entación de la gestión de sesiones de PHP

� Restringir el acceso al directorio session.save_pat h donde se guardan los archivos de sesión sin encriptar. En la instalación por defecto, sólo tiene acceso a ese directorio el usuario bajo el que se ejecuta el servidor web. Los usuarios no deben ni poder listar los archivos ya que su nombre contiene el identificador de sesión.

6.5.5. Validación

� La validación asegura que lo que contiene la entrada de datos es lo que se espera . Por ejemplo, se debe validar una dirección de correo electrónico, un número telefónico, o la edad de un usuario al procesar una solicitud de registro.

Más sobre los filtros de validación

6.5.6. Archivos de Configuración

Se han de cumplir –al menos- las buenas prácticas siguientes:






� Almacenar los archivos de configuración donde no se pueda acceder a ellos directamente por medio del sistema de archivos.

� Si no hay otra alternativa más que almacenar los archivos de configuración en la raíz de documentos de su aplicación, se debe adjuntar la extensión .php al nombre de los archivos . De esta manera, aún si alguien accede a ellos directamente, la información no será impresa en forma de texto a la pantalla.

� La información en los archivos de configuración debe ser protegida ya sea por medio de codificación o con los permisos de grupo/usuario pertinentes en el sistema de archivos.

6.5.7. Informe de Errores

Se recomienda aplicar los siguientes valores en el fichero php.ini en función del entorno:

� Desarrollo

display_errors = On display_startup_errors = On error_reporting = -1 (1) log_errors = On

(1) El valor -1 mostrará cualquier error independientemente que en versiones posteriores de PHP se añadan nuevas constantes.

� Producción

display_errors = Off display_startup_errors = Off error_reporting = E_ALL log_errors = On






ANEXO 1: configuración PHP

A continuación se muestra la configuración de PHP en producción.

PHP Version 5.4.16

PHP Version => 5.4.16 System => Linux mov-lamp2016-01 3.10.0-327.22.2.el7 .x86_64 #1 SMP Thu Jun 9 10:09:10 EDT 2016 x86_64 Build Date => Apr 4 2016 07:13:12 Server API => Command Line Interface Virtual Directory Support => disabled Configuration File (php.ini) Path => /etc Loaded Configuration File => /etc/php.ini Scan this dir for additional .ini files => /etc/php .d Additional .ini files parsed => /etc/php.d/curl.ini , /etc/php.d/fileinfo.ini, /etc/php.d/json.ini, /etc/php.d/phar.ini, /etc/php.d/zip.ini PHP API => 20100412 PHP Extension => 20100525 Zend Extension => 220100525 Zend Extension Build => API220100525,NTS PHP Extension Build => API20100525,NTS Debug Build => no Thread Safety => disabled Zend Signal Handling => disabled Zend Memory Manager => enabled Zend Multibyte Support => disabled IPv6 Support => enabled DTrace Support => disabled Registered PHP Streams => https, ftps, compress.zli b, compress.bzip2, php, file, glob, data, http, ftp, phar, zip Registered Stream Socket Transports => tcp, udp, un ix, udg, ssl, sslv3, sslv2, tls Registered Stream Filters => zlib.*, bzip2.*, conve rt.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk

Configuration

bz2

BZip2 Support => Enabled Stream Wrapper support => compress.bzip2:// Stream Filter support => bzip2.decompress, bzip2.co mpress BZip2 Version => 1.0.6, 6-Sept-2010

calendar

Calendar support => enabled

Core

Directive => Local Value => Master Value allow_url_fopen => Off => Off allow_url_include => Off => Off

always_populate_raw_post_data => Off => Off arg_separator.input => & => & arg_separator.output => & => & asp_tags => Off => Off auto_append_file => no value => no value auto_globals_jit => On => On auto_prepend_file => no value => no value browscap => no value => no value default_charset => no value => no value default_mimetype => text/html => text/html disable_classes => no value => no value disable_functions => symlink,system,shell_exec,exec,proc_get_status,proc _nice,proc_terminate,define_syslog_variables,syslog,openlog,closelog,escapeshellcmd,p assthru,ocinumcols,ini_alter,leak,listen,chgrp,apache_note,apache_setenv,debugger_on, debugger_off,ftp_exec,dl,dll,ftp,myshellexec,proc_open,socket_bind,proc_close,popen,s how_source,curl_exec,curl_multi_exec,parse_ini_file => symlink,system,shell_exec,exec,proc_get_status,proc _nice,proc_terminate,define_syslog_variables,syslog,openlog,closelog,escapeshellcmd,p assthru,ocinumcols,ini_alter,leak,listen,chgrp,apache_note,apache_setenv,debugger_on, debugger_off,ftp_exec,dl,dll,ftp,myshellexec,proc_open,socket_bind,proc_close,popen,s how_source,curl_exec,curl_multi_exec,parse_ini_file display_errors => Off => Off display_startup_errors => Off => Off doc_root => no value => no value docref_ext => no value => no value docref_root => no value => no value enable_dl => Off => Off enable_post_data_reading => On => On error_append_string => no value => no value error_log => no value => no value error_prepend_string => no value => no value error_reporting => 22527 => 22527 exit_on_timeout => Off => Off expose_php => Off => Off extension_dir => /usr/lib64/php/modules => /usr/lib 64/php/modules file_uploads => On => On highlight.comment => # FF8000 => #FF8000 highlight.default => # 0000BB => #0000BB highlight.html => #000 000 => #000000 highlight.keyword => # 007700 => #007700 highlight.string => #D D0000 => #DD0000 html_errors => Off => Off ignore_repeated_errors => Off => Off ignore_repeated_source => Off => Off ignore_user_abort => Off => Off implicit_flush => On => On include_path => .:/usr/share/pear:/usr/share/php => .:/usr/share/pear:/usr/share/php log_errors => On => On log_errors_max_len => 1024 => 1024 mail.add_x_header => On => On mail.force_extra_parameters => no value => no value mail.log => no value => no value max_execution_time => 0 => 0 max_file_uploads => 20 => 20 max_input_nesting_level => 64 => 64 max_input_time => -1 => -1 max_input_vars => 1000 => 1000 memory_limit => 128M => 128M open_basedir => /var/www/sites => /var/www/sites output_buffering => 0 => 0






output_handler => no value => no value post_max_size => 8M => 8M precision => 14 => 14 realpath_cache_size => 16K => 16K realpath_cache_ttl => 120 => 120 register_argc_argv => On => On report_memleaks => On => On report_zend_debug => Off => Off request_order => GP => GP sendmail_from => no value => no value sendmail_path => /usr/sbin/sendmail -t -i => /usr/s bin/sendmail -t -i serialize_precision => 17 => 17 short_open_tag => Off => Off SMTP => localhost => localhost smtp_port => 25 => 25 sql.safe_mode => Off => Off track_errors => Off => Off unserialize_callback_func => no value => no value upload_max_filesize => 2M => 2M upload_tmp_dir => /tmp => /tmp user_dir => no value => no value user_ini.cache_ttl => 300 => 300 user_ini.filename => .user.ini => .user.ini variables_order => GPCS => GPCS xmlrpc_error_number => 0 => 0 xmlrpc_errors => Off => Off zend.detect_unicode => On => On zend.enable_gc => On => On zend.multibyte => Off => Off zend.script_encoding => no value => no value

ctype

ctype functions: enabled

curl

cURL support => enabled cURL Information => 7.29.0 Age => 3 Features AsynchDNS => Yes Debug => No GSS-Negotiate => Yes IDN => Yes IPv6 => Yes Largefile => Yes NTLM => Yes SPNEGO => No SSL => Yes SSPI => No krb4 => No libz => Yes CharConv => No Protocols => dict, file, ftp, ftps, gopher, http, h ttps, imap, imaps, ldap, ldaps, pop3, pop3s, rtsp, scp, sftp, smtp, smtps, telnet, tftp Host => x86_64-redhat-linux-gnu SSL Version => NSS/3.16.2.3 Basic ECC ZLib Version => 1.2.7 libSSH Version => libssh2/1.4.3

date

date/time support => enabled






"Olson" Timezone Database Version => 0.system Timezone Database => internal Default timezone => UTC Directive => Local Value => Master Value date.default_latitude => 31.7667 => 31.7667 date.default_longitude => 35.2333 => 35.2333 date.sunrise_zenith => 90.583333 => 90.583333 date.sunset_zenith => 90.583333 => 90.583333 date.timezone => no value => no value

ereg

Regex Library: Bundled library enabled

exif

EXIF Support => enabled EXIF Version => 1.4 $Id$ Supported EXIF Version => 0220 Supported filetypes => JPEG,TIFF Directive => Local Value => Master Value exif.decode_jis_intel => JIS => JIS exif.decode_jis_motorola => JIS => JIS exif.decode_unicode_intel => UCS-2LE => UCS-2LE exif.decode_unicode_motorola => UCS-2BE => UCS-2BE exif.encode_jis => no value => no value exif.encode_unicode => ISO-8859-15 => ISO-8859-15

fileinfo

fileinfo support: enabled version: 1.0.5

filter

Input Validation and Filtering: enabled Revision: $Id: 2aa8dd57d9c0c655cd45e6e5872bb95fa5ad 76cf $ Directive => Local Value => Master Value filter.default => unsafe_raw => unsafe_raw filter.default_flags => no value => no value

ftp

FTP support: enabled

gettext

GetText Support: enabled

gmp

gmp support: enabled GMP version: 6.0.0

hash






hash support => enabled Hashing Engines => md2 md4 md5 sha1 sha224 sha256 s ha384 sha512 ripemd128 ripemd160 ripemd256 ripemd320 whirlpool tiger128,3 tiger160,3 tiger192,3 tiger128,4 tiger160,4 tiger192,4 snefru snefru256 gost adler32 crc32 crc3 2b fnv132 fnv164 joaat haval128,3 haval160,3 haval192,3 haval224,3 haval256,3 haval12 8,4 haval160,4 haval192,4 haval224,4 haval256,4 haval128,5 haval160,5 haval19 2,5 haval224,5 haval256,5

iconv

iconv support => enabled iconv implementation => glibc iconv library version => 2.17 Directive => Local Value => Master Value iconv.input_encoding => ISO-8859-1 => ISO-8859-1 iconv.internal_encoding => ISO-8859-1 => ISO-8859-1 iconv.output_encoding => ISO-8859-1 => ISO-8859-1

json

json support: enabled json version: 1.2.1

libxml

libXML support: active libXML Compiled Version: 2.9.1 libXML Loaded Version: 20901 libXML streams: enabled

mhash

MHASH support: Enabled MHASH API Version: Emulated Support

openssl

OpenSSL support: enabled OpenSSL Library Version: OpenSSL 1.0.1e-fips 11 Feb 2013 OpenSSL Header Version: OpenSSL 1.0.1e-fips 11 Feb 2013

pcntl

pcntl support => enabled

pcre

PCRE (Perl Compatible Regular Expressions) Support: enabled PCRE Library Version: 8.32 2012-11-30 Directive => Local Value => Master Value pcre.backtrack_limit => 1000000 => 1000000 pcre.recursion_limit => 100000 => 100000

Phar

Phar: PHP Archive support enabled Phar EXT version: 2.0.1 Phar API version: 1.1.1






SVN revision => $Id: c5042cc34acebcc0926625b57dff03 deebbe6472 $ Phar-based phar archives => enabled Tar-based phar archives => enabled ZIP-based phar archives => enabled gzip compression => enabled bzip2 compression => enabled Native OpenSSL support => enabled Directive => Local Value => Master Value phar.cache_list => no value => no value phar.readonly => On => On phar.require_hash => On => On

readline

Readline Support => enabled Readline library => EditLine wrapper Directive => Local Value => Master Value cli.pager => no value => no value cli.prompt => \b \> => \b \>

Reflection

Reflection: enabled Version: $Id: 6c4d8062369898a397e4b128348042f5c01b4 427 $

session

Session Support: enabled Registered save handlers: files user Registered serializer handlers: php php_binary Directive => Local Value => Master Value session.auto_start => On => On session.cache_expire => 180 => 180 session.cache_limiter => nocache => nocache session.cookie_domain => no value => no value session.cookie_httponly => On => On session.cookie_lifetime => 0 => 0 session.cookie_path => / => / session.cookie_secure => On => On session.entropy_file => /dev/urandom => /dev/urando m session.entropy_length => 32 => 32 session.gc_divisor => 1000 => 1000 session.gc_maxlifetime => 1440 => 1440 session.gc_probability => 1 => 1 session.hash_bits_per_character => 5 => 5 session.hash_function => 0 => 0 session.name => GAPHPSESSID => GAPHPSESSID session.referer_check => no value => no value session.save_handler => files => files session.save_path => /tmp => /tmp session.serialize_handler => php => php session.upload_progress.cleanup => On => On session.upload_progress.enabled => On => On session.upload_progress.freq => 1% => 1% session.upload_progress.min_freq => 1 => 1 session.upload_progress.name => PHP_SESSION_UPLOAD_ PROGRESS => PHP_SESSION_UPLOAD_PROGRESS session.upload_progress.prefix => upload_progress_ => upload_progress_ session.use_cookies => On => On session.use_only_cookies => On => On






session.use_trans_sid => 0 => 0

shmop

shmop support: enabled

SimpleXML

Simplexml support: enabled Revision: $Id: 692516840b2d7d6e7aedb0bedded1f53b764 a99f $ Schema support: enabled

sockets

Sockets Support: enabled

SPL

SPL support => enabled Interfaces => Countable, OuterIterator, RecursiveIt erator, SeekableIterator, SplObserver, SplSubject Classes => AppendIterator, ArrayIterator, ArrayObje ct, BadFunctionCallException, BadMethodCallException, CachingIterator, CallbackFi lterIterator, DirectoryIterator, DomainException, EmptyIterator, FilesystemIterator, FilterIterator, GlobIterator, InfiniteIterator, InvalidArgumentException, Iterato rIterator, LengthException, LimitIterator, LogicException, MultipleIterator, No RewindIterator, OutOfBoundsException, OutOfRangeException, Overflow Exception, ParentIterator, RangeException, RecursiveArrayIterator, RecursiveCa chingIterator, RecursiveCallbackFilterIterator, RecursiveDirectory Iterator, RecursiveFilterIterator, RecursiveIteratorIterator, RecursiveRegexIterator, RecursiveTreeIterator, RegexIterator, RuntimeException, SplDoublyLinkedLis t, SplFileInfo, SplFileObject, SplFixedArray, SplHeap, SplMinHeap, SplMaxHeap, Spl ObjectStorage, SplPriorityQueue, SplQueue, SplStack, SplTempFileObject, UnderflowExc eption, UnexpectedValueException

standard

Dynamic Library Support: enabled Path to sendmail: /usr/sbin/sendmail -t –i Directive => Local Value => Master Value assert.active => 1 => 1 assert.bail => 0 => 0 assert.callback => no value => no value assert.quiet_eval => 0 => 0 assert.warning => 1 => 1 auto_detect_line_endings => 0 => 0 default_socket_timeout => 60 => 60 from => no value => no value url_rewriter.tags => a=href,area=href,frame=src,inp ut=src,form=fakeentry => a=href,area=href,frame=src,input=src,form=fakeentry user_agent => no value => no value

tokenizer

Tokenizer Support: enabled

xml

XML Support: active XML Namespace Support: active






libxml2 Version: 2.9.1

zip

Zip: enabled Extension Version: $Id: 0c033d4e4613d577409950ed7bf 8da4b68286d15 $ Zip version: 1.11.0 Compiled against libzip version: 0.10.1

zlib

ZLib Support: enabled Stream Wrapper: compress.zlib:// Stream Filter: zlib.inflate, zlib.deflate Compiled Version: 1.2.7 Linked Version: 1.2.7 Directive => Local Value => Master Value zlib.output_compression => Off => Off zlib.output_compression_level => -1 => -1 zlib.output_handler => no value => no value

Environment

Variable => Value MANPATH => :/var/cfengine/share/man XDG_SESSION_ID => 51749 HOSTNAME => mov-lamp2016-01 SHELL => /bin/bash TERM => xterm HISTSIZE => 1000 USER => root LS_COLORS => rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=0 1;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw =30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.t az=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.t zo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;3 1:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:* .tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.r ar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab =01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm =01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg =01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2 v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.v ob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc =01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01 ;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01; 35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01; 36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36 :*.xspf=01;36: MAIL => /var/spool/mail/root PATH => /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin :/usr/bin:/var/cfengine/bin:/root/bin PWD => /var/www/sites LANG => es_ES.UTF-8 HISTCONTROL => ignoredups SHLVL => 1 HOME => /root LOGNAME => root LESSOPEN => ||/usr/bin/lesspipe.sh %s OLDPWD => /var/www/sites _ => /bin/php






PHP Variables

Variable => Value _SERVER["MANPATH"] => :/var/cfengine/share/man _SERVER["XDG_SESSION_ID"] => 51749 _SERVER["HOSTNAME"] => mov-lamp2016-01 _SERVER["SHELL"] => /bin/bash _SERVER["TERM"] => xterm _SERVER["HISTSIZE"] => 1000 _SERVER["USER"] => root _SERVER["LS_COLORS"] => rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=0 1;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw =30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.t az=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.t zo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;3 1:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:* .tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.r ar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab =01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm =01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg =01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2 v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.v ob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc =01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01 ;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01; 35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01; 36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36 :*.xspf=01;36: _SERVER["MAIL"] => /var/spool/mail/root _SERVER["PATH"] => /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin :/usr/bin:/var/cfengine/bin:/root/bin _SERVER["PWD"] => /var/www/sites _SERVER["LANG"] => es_ES.UTF-8 _SERVER["HISTCONTROL"] => ignoredups _SERVER["SHLVL"] => 1 _SERVER["HOME"] => /root _SERVER["LOGNAME"] => root _SERVER["LESSOPEN"] => ||/usr/bin/lesspipe.sh %s _SERVER["OLDPWD"] => /var/www/sites _SERVER["_"] => /bin/php _SERVER["PHP_SELF"] => phpinfo.php _SERVER["SCRIPT_NAME"] => phpinfo.php _SERVER["SCRIPT_FILENAME"] => phpinfo.php _SERVER["PATH_TRANSLATED"] => phpinfo.php _SERVER["DOCUMENT_ROOT"] => _SERVER["REQUEST_TIME_FLOAT"] => 1472038560.2836 _SERVER["REQUEST_TIME"] => 1472038560 _SERVER["argv"] => Array ( [0] => phpinfo.php ) _SERVER["argc"] => 1






ANEXO 2: Securización del entorno

� Funciones que no se deben utilizar

Está prohibido el uso de las siguientes funcionalidades:

phpinfo,symlink,system,shell_exec,exec,proc_get_sta tus,proc_nice,proc_terminate,define_syslog_variables,syslog,openlog,closelog,escapesh ellcmd,passthru,ocinumcols,ini_alter,leak,listen,chgrp,apache_note,apache_setenv,debu gger_on,debugger_off,ftp_exec,dl,dll,ftp,myshellexec,proc_open,socket_bind,proc_close ,popen,show_source,curl_exec,curl_multi_exec,parse_ini_file

� Uso de PHP open_basedir

Esta directiva limita los archivos que pueden ser abiertos por PHP al árbol de directorios especificado. Se han habilitado las siguientes opciones:

open_basedir = /var/www/sites/ upload_tmp_dir = /tmp

� Deshabilitar register_globals

register_globals = Off

� Deshabilitar allow_url_fopen

De este modo, no se pueden ejecutar scripts de una URL remota.

allow_url_fopen = Off

� Versión de PHP

Ocultar versión de PHP.

expose_php = Off

� Deshabilitar el método TRACE

TraceEnable Off

� Activar session.autostart

Para iniciar sesión automáticamente al comenzar la petición.

session.auto_start = 1

� Activar session.cookie_httponly

Para que las cookies sólo estén accesibles a través del protocolo http. Esto implica que JavaScript no tiene acceso a las cookies de sesión

session.cookie_httponly = 1






� Activar session.cookie_secure

Implica utilizar la opción secure en las cookies de sesión.

session.cookie_secure = 1

� Cambiar el valor de session.name

_session.name = GAPHPSESSID






ANEXO 3: Convenio de Nomenclatura de Objetos de BBD D

Objetivo

El presente documento define un convenio para nominar objetos de base de datos para:

� Facilitar el diseño de base de datos reduciendo el tiempo invertido en la elección de nombres de objetos.

� Evitar conflictos entre nombres de objetos de distintas aplicaciones.

� Facilitar las tareas de administración.

Convenio de Nombres

Reglas.

El presente convenio sigue unas reglas fáciles de explicar y de aplicar:

� Todo objeto debe ir precedido del prefijo apl_, donde apl debe sustituirse por el código de la aplicación a la que pertenece el objeto. Esta regla evita los conflictos entre nombres de objetos de aplicaciones distintas.

� Todo objeto debe incorporar en el nombre el tipo del objeto (p.e. i para índices, pk para primary keys, etc.). Como excepción a esta regla están las tablas, por ser el objeto principal de la base de datos. Esta regla evita dedicar tiempo en pensar nombres distintos para objetos de distinto tipo dentro de la misma aplicación.

� Todo objeto debe terminar con una cadena de caracteres que debe definirse libremente para distinguir los objetos del mismo tipo y aplicación.

� Todo objeto que depende jerárquicamente de otro debe ir precedido del nombre del objeto del depende (p.e. índices sobre tablas. Esta regla da una visión de la jerarquía de objetos a nivel de nombres y proporciona un método rápido de nombrar objetos que no son utilizados en sentencias DML.

Convenio de estilos .

� La letra cursiva se utiliza para definir cadenas que deben ser sustituidas por literales definidos previamente.

� La letra negrita se utiliza para definir cadenas fijas que deben escribirse literalmente.

� Los caracteres de subrayado son fijos y deben escribirse literalmente.

� La cadena ‘id’ representa cualquier cadena de caracteres válidos a definir libremente.




Entidad Pública Aragonesa de Servicios TelemáticosAv. Ranillas, 3 A, 3ª Oficina J • 50018 ZARAGOZA

Tel. 976 71 4495 • Fax. 976 71 4145www.aragon.es

Longitud de nombres .

La longitud total de un nombre de objeto no puede exceder el límite MariaDB Este límite debe reducirse para el caso de las tablas, ya que el nombre de estas sirve de base para la definición de otros nombres de objetos dependientes.

Tipo de Objeto Nombre Coment ario

Base de Datos apl_bd # DB

Tabla apl_id # Table

Vista apl_v_id # View

Dependencias sobre Tablas

Clave Primaria tabla_pk # Primary Key

Clave Ajena tabla_fk_ id # Foreign Key

Índice tabla_ix_id # Index

Convenio de Nombres

Ejemplos: OEP – Oferta de Empleo Público Tablas: OEP_SOLICITANTES OEP_CONVOCATORIAS Vistas: OEP_V_ADMITIDOS Clave Primaria: OEP_SOLICITANTES_PK Clave Foránea: OEP_SOLICITANTES_FK_CONVOCAT Índices: OEP_SOLICITANTES_IX_DNI OEP_SOLICITANTES_IX_APELLIDOS

Entorno LAMP 2016 del Gobierno de Aragón · No usar funciones dentro de bucles de conteo ..... 32...

Documents

Transcript of Entorno LAMP 2016 del Gobierno de Aragón · No usar funciones dentro de bucles de conteo ..... 32...