Seguridad de las conexiones

La seguridad de su servidor web 4D está basada en los siguientes elementos:

• La combinación del sistema de gestión de contraseñas (modo BASIC o modo DIGEST) y del Método de base On Web Authentication,
• La definición de un Usuario web genérico,
• La definición de una carpeta Root HTML por defecto,
• La definición de la propiedad “Disponible vía las etiquetas y los URLs 4D (4D ACTION.)” para cada método proyecto de la base.
• La opción para el soporte específico de peticiones de sincronización vía HTTP.

Notas:

• la seguridad de la conexión misma puede ser administrada por el protocolo SSL. Para mayor información, consulte la sección [#title id="777"/].
• para una descripción general de las funcionalidades de seguridad de 4D, consulte la guía de seguridad 4D.

Puede definir en las preferencias de la base, el sistema de control de acceso que quiere aplicar a su servidor web. Se ofrecen dos modos de autenticación: Modo BASIC y modo DIGEST.
El modo autenticación concierne a la manera como se colecta y procesa la información relativa al nombre de usuario y contraseña.

• En modo BASIC, el nombre y la contraseña introducida por el usuario son enviadas sin encriptar en las peticiones HTTP. Este principio no asegura una seguridad total al sistema ya que la información puede ser interceptada y utilizada por terceros.

• El modo DIGEST ofrece un nivel mayor de seguridad ya que la información de autenticación es procesada por un proceso unidireccional llamado dispersión (hashing) que hace que su contenido sea imposible de descifrar.

Para el usuario, el uso de un modo de autenticación u otro es transparente.

Notas:

• Por razones de compatibilidad, el modo de autenticación BASIC se utiliza por defecto en las bases 4D convertidas a versión 11 (si la opción “Utilizar contraseñas” fue seleccionada en la versión anterior). Debe activar explícitamente el modo Digest.

• La autenticación Digest es una función de HTTP1.1 y no es soportada por todos los navegadores. Por ejemplo, sólo las versiones 5.0 y superiores de Microsoft Internet Explorer aceptan este modo. Si un navegador no soporta esta funcionalidad envía una petición a un servidor web cuando se activa la autenticación Digest, el servidor rechazará la petición y devolverá un mensaje de error al navegador.

La elección del modo de autenticación se efectúa en la página Web/Opciones (I) de la caja de diálogo de Propiedades de la base:

En el área "Contraseñas web", hay tres opciones disponibles:

• Sin contraseñas: ninguna autenticación se lleva acabo para la conexión al servidor web. En este caso:

- Si existe el Método de base On Web Authentication, se ejecuta y además de $1 y $2, sólo las direcciones IP del navegador y del servidor ($3 y $4) son suministradas, el nombre de usuario y la contraseña ($5 y $6) están vacíos. En este caso, puede filtrar las conexiones en función de la dirección IP del navegador y/o de la dirección IP pedida del servidor.

- Si el Método de base On Web Authentication no existe, las conexiones son aceptadas automáticamente.

• Contraseñas con protocolo BASIC: autenticación estándar en modo BASIC. Cuando un usuario se conecta al servidor, aparece una caja de diálogo en su navegador permitiéndole introducir su nombre y su contraseña. Estos dos valores se envían al Método de base On Web Authentication junto con los otros parámetros de la conexión (dirección y puerto IP, URL...) de manera que usted los pueda procesar.
  Este modo ofrece acceso a la opción Incluir contraseñas 4D que permite utilizar, en lugar de o en adición a su propio sistema de contraseñas, el sistema 4D de contraseñas de la base (definido en 4D).

• Contraseñas con protocolo DIGEST: autenticación en modo DIGEST. Como en modo BASIC, los usuarios deben introducir su nombre y contraseña cuando se conectan. Estos dos valores son enviados encripatados al Método de base On Web Authentication con los otros parámetros de la conexión. Debe autenticar un usuario utilizando el comando Ventana de resultados.

Notas:

• Debe reiniciar el servidor web para que las modificaciones efectuadas a estos parámetros sean tenidas en cuenta

• Con el servidor web de 4D Client, recuerde que todos los sitios publicados por los equipos clientes 4D compartirán la misma tabla de usuarios. La validación de los usuarios/contraseñas es llevada a cabo por la aplicación 4D Server.

Si utiliza el modo BASIC, el sistema de filtro de las conexiones al servidor web de 4D depende de la combinación de dos parámetros:

• Las opciones de contraseñas web en la caja de diálogo de Propiedades de la base,
• La existencia del Método de base On Web Authentication.

Estas son las diferentes posibilidades de control de las conexiones:

La opción “Contraseñas con protocolo BASIC” está seleccionada y la opción “Incluir contraseñas 4D” no está seleccionada.

• Si existe el Método de base On Web Authentication, se ejecuta y todos sus parámetros son dados. Puede filtrar más precisamente las conexiones de acuerdo al nombre de usuario, contraseña, y/o a las direcciones IP del navegador y del servidor web.

• Si el Método de base On Web Authentication no existe, la conexión se rechaza automáticamente y se envía un mensaje al navegador indicando que el método de autenticación no existe.

Nota: si el nombre de usuario enviado es una cadena vacía y si el Método de base On Web Authentication no existe, se envía al navegador una caja de diálogo de petición de contraseña.

Las opciones “Contraseñas con protocolo BASIC” e “Incluir contraseñas 4D” están seleccionadas.

• Si el nombre de usuario enviado por el navegador existe en la tabla de usuarios 4D y la contraseña es correcta, la conexión es aceptada. Si la contraseña es incorrecta, la conexión es rechazada.

• Si el nombre de usuario enviado por el navegador no existe en 4D, dos resultados son posibles:

- Si existe el Método de base On Web Authentication, se devuelven los parámetros $1, $2, $3, $4, $5, y $6. Por lo tanto puede filtrar las conexiones de acuerdo con el nombre de usuario, contraseña, y/o las direcciones IP del navegador y del servidor web.

- Si el Método de base On Web Authentication no existe, la conexión se rechaza.

A diferencia del modo BASIC, el modo DIGEST no es compatible con las contraseñas 4D estándar: no es posible utilizar las contraseñas 4D como identificadores web. La opción “Incluir contraseñas 4D” está gris cuando se selecciona este modo. Los identificadores de los usuarios Web deben ser administrados de manera personalizada (por ejemplo, vía una tabla).
Cuando el modo DIGEST está activo, el parámetro $6 (contraseña) siempre se devuelve vacío en el Método de base On Web Authentication. De hecho, cuando se utiliza este modo, esta información no pasa por la red como texto claro (no encriptado). Por lo tanto es imperativo en este caso evaluar la petición de conexión con la ayuda del comando WEB Validate digest.

El funcionamiento del sistema de acceso al servidor web 4D se resume en el siguiente diagrama:

Algunos robots (motores de búsqueda, arañas...) recorren los servidores Web y las páginas estáticas. Si quiere que los robots puedan acceder a todo su sitio, puede definir cuáles URLs no pueden acceder.
Para esto, ponga el archivo ROBOTS.TXT en la raíz del servidor Web. Este archivo debe estar estructurado de la siguiente manera:

User-Agent: <nombre>
Disallow: <URL> o <comienzo del URL>

Por ejemplo:

User-Agent: *
Disallow: /4D
Disallow: /%23%23
Disallow: /GIFS/

“User-Agent: *” significa que todos los robots están afectados.
“Disallow: /4D” significa que los robots no deben acceder a los URLs que comienzan por /4D.
“Disallow: /%23%23” significa que los robots no deben acceder a los URLs que comienzan por /%23%23.
“Disallow: /GIFS/’ significa que los robots no deben acceder a la carpeta /GIFS/ ni a las subcarpetas.

Otro ejemplo:

User-Agent: *
Disallow: /

En este caso, los robots no tienen acceso a todo el sitio.

Puede designar un usuario, previamente definido en la tabla de contraseñas de 4D, como “Usuario Web Genérico.” En este caso, cada navegador que se conecta a la base puede utilizar las autorizaciones de acceso y las restricciones asociadas con este usuario. De esta forma puede controlar fácilmente el acceso de los navegadores a las diferentes partes de la base.

Nota: no hay que confundir esta opción, la cual permite restringir los accesos de los navegadores a las diferentes partes de la aplicación (métodos, formularios, etc.), con el sistema de control de conexiones al servidor web, administrado por el sistema de contraseñas y el Método de base On Web Authentication.

Para definir un Usuario web genérico:

1. En modo Diseño, cree al menos un usuario con el editor de usuarios de la caja de herramientas.
    Si quiere puede asociar una contraseña con el usuario.
2. En los diferentes editores de 4D, autorice o restrinja el acceso a este usuario.
3. En la caja de diálogo de Propiedades, elija el tema Web, página Opciones (I).
    El área “Contraseñas Web” contiene la lista desplegable Usuario web genérico. Por defecto, el Usuario web genérico es el Diseñador y los navegadores tienen acceso completo a 
   todas las partes de la base.
4. Elija un usuario en la lista desplegable y valide la caja de diálogo.

Todos los navegadores web autorizados a conectarse a la base se beneficiarán de las autorizaciones de acceso asociadas al Usuario web genérico (excepto cuando el modo BASIC y la opción
“Incluir contraseñas 4D” están seleccionados y el usuario que se conecta no existe en la tabla de contraseñas 4D, ver a continuación).

La opción "Contraseñas con protocolo BASIC" no influye en cómo funciona el Usuario Web genérico. Sin importar el estado de esta opción, los privilegios y las restricciones de acceso asociados al “Usuario Web genérico” se aplicarán a todos los navegadores Web que están autorizados para conectarse a la base.

Sin embargo, cuando la opción "Incluir contraseñas 4D" está seleccionada pueden presentarse dos posibles resultados:

• El nombre y la contraseña del usuario no existen en la tabla de contraseñas de 4D. En este caso, si la conexión ha sido aceptada por el Método de base On Web Authentication, los derechos de acceso del usuario Web genérico serán aplicados al navegador.

• Si el nombre de usuario y contraseña existen la tabla de contraseñas de 4D, el parámetro “Usuario Web genérico” se ignora. El usuario se conecta con sus propios derechos de acceso.

Esta opción de las Propiedades de la base permite definir la carpeta en la cual 4D buscará las páginas HTML estáticas y semidinámicas, las imágenes, etc., a enviar a los navegadores.

Además, la carpeta raíz HTML define, en el disco duro del servidor web, el nivel jerárquico sobre el cual los archivos no serán accesibles. Esta restricción de acceso aplica a los URLs enviados a los navegadores web como también a los comandos del servidor web tal como WEB SEND FILE. Si un URL enviado a la base por un navegador o si un comando 4D intenta acceder a un archivo ubicado sobre la carpeta raíz HTML, se devuelve un error indicando que el archivo no ha sido encontrado.

Por defecto, 4D define una carpeta raíz HTML llamada WebFolder. Si esta carpeta no existe, la carpeta raíz HTML se crea en el disco en el momento en que se lanza el servidor web por primera vez.

Si conserva la ubicación por defecto, la carpeta raíz se crea:

• con 4D in modo local y 4D Server, al mismo nivel que el archivo de estructura de la base.
  Nota: como parte de una aplicación compilada y fusionada, el archivo de estructura se ubica en la subcarpeta Database. 

• con 4D en modo remoto, en la carpeta local de la base 4D (ver el comando Get 4D folder ).

Puede modificar el nombre y la ubicación de la carpeta raíz HTML por defecto en la caja de diálogo de Propiedades (tema Web, página Configuración):

En el área “Raíz HTML por defecto”, introduzca la nueva ruta de acceso de la carpeta que quiere utilizar.

La ruta de acceso introducida en esta caja de diálogo es relativa: está establecida a partir de la carpeta que contiene la estructura de la base (4D en modo local o 4D Server) o la carpeta que contiene la aplicación o el software 4D (4D in modo remoto).

Con el fin de asegurar la compatibilidad multiplataforma de sus bases, el servidor Web 4D utiliza convenciones de escritura particulares para describir rutas de acceso. Las reglas de sintaxis son las siguientes:

• Las carpetas están separadas por una barra oblicua (“/”)

• La ruta de acceso no debe terminar con una barra oblicua (“/”)

• Para “subir” un nivel en la jerarquía de las carpetas, introduzca “..” (dos puntos) antes del nombre de la carpeta
• La ruta de acceso no debe comenzar con una barra oblicua (“/”) (excepto si quiere que la carpeta raíz HTML sea la carpeta de la base o de 4D Client, ver a continuación).

Por ejemplo, si quiere que la carpeta raíz HTML sea la subcarpeta “Web”, ubicada en la carpeta “Base4D", introduzca Base4D/Web.

Si quiere que la carpeta raíz HTML sea la carpeta de la base o de 4D Client, pero que el acceso a las carpetas de los niveles superiores esté prohibido, introduzca “/” en el área. Para que el acceso a los volúmenes sea total, deje el área “Raíz HTML por defecto” vacía.

Advertencia: si no define ninguna carpeta raíz HTML por defecto, se utilizará la carpeta que contiene el archivo de estructura de la base o de la aplicación 4D Client. Tenga cuidado porque en este caso, no hay restricciones de acceso (los usuarios pueden acceder a todos los volúmenes).

Notas:

• Cuando la carpeta raíz HTML se modifica en las Propiedades de la base, la caché se borra para no conservar archivos cuyo acceso esté restringido.

• También es posible definir dinámicamente la carpeta raíz HTML utilizando el comando WEB SET ROOT FOLDER. En este caso, la modificación aplica a todos los procesos web actuales para la sesión de trabajo. La caché de las páginas HTML se borra.

El URL especial 4DACTION, las etiquetas 4DSCRIPT, 4DEVAL, 4DTEXT, 4DHTML (así como también las antiguas etiquetas 4DVAR y 4DHTMLVAR) permiten activar la ejecución de todo método proyecto de una base 4D publicada en la Web. Por ejemplo, la petición http://www.server.com/4DACTION/Erase_All provoca la ejecución del método proyecto Erase_All, si existe.

Este mecanismo presenta un riesgo para la seguridad de la base, en particular si un internauta intencionalmente o por error dispara un método no destinado para ejecución vía Web. Puede evitar este riesgo de tres formas:

• Restringiendo el acceso a los métodos proyecto utilizando el sistema de contraseñas 4D. Inconvenientes: este sistema necesita utilizar las contraseñas 4D y prohíbe todo tipo de ejecución del método (incluyendo utilizando las etiquetas HTML).
• Filtrando los métodos llamados vía los URLS utilizando el Método de base On Web Authentication. Inconvenientes: si la base incluye un gran número de métodos, este sistema puede ser difícil de administrar.
• Usar la opción Disponible a través de las etiquetas y los URLs 4D (4DACTION.) mostrada en la caja de diálogo de Propiedades de los métodos proyecto:

Esta opción permite designar individualmente cada método proyecto que puede llamarse utilizando el URL especial 4DACTION y las etiquetas 4DSCRIPT, 4DEVAL, 4DTEXT y 4DHTML (así como también 4DVAR y 4DHTMLVAR). Cuando está deseleccionada, el método proyecto concerniente no puede ejecutarse utilizando una petición HTTP que contenga un URL o etiqueta especial. Por el contrario, puede ejecutarse utilizando otro tipo de llamadas (fórmulas, otros métodos, etc.).

Esta opción está deseleccionada por defecto al crear una base. Los métodos que pueden ejecutarse utilizando el URL 4DACTION y las etiquetas 4D deben indicarse expresamente.

En el Explorador, los métodos proyecto con esta propiedad tienen un icono específico:

Esta opción de la página "Web/Configuración" de las Propiedades de la base permite controlar el soporte de peticiones que contienen los URLs /4DSYNC. Estos URLs se utilizan para la sincronización de datos a través de HTTP (para obtener más información sobre este mecanismo, consulte el párrafo URL 4DSYNC/).

Esta opción habilita o deshabilita el procesamiento especifico de las peticiones que contienen /4DSYNC:

• Cuando no está seleccionada, las peticiones /4DSYNC son considerados como peticiones estándar y no permiten el procesamiento específico (el uso de una petición de sincronización provoca el envío de la respuesta tipo "404 - recurso no disponible").
• Cuando se activa, el mecanismo de sincronización está activado; las peticiones /4DSYNC se consideran como peticiones especiales y son procesadas por el servidor HTTP de 4D.

Por defecto:

• esta opción no está seleccionada en bases de datos creadas con 4D a partir de la versión 13.
• esta opción está seleccionada en las bases de datos convertidas de una versión anterior a 4D v13, razones de compatibilidad. Le recomendamos que la desactive si su aplicación no utiliza la función de replicación  HTTP.

El alcance de esta opción es local a la aplicación y el servidor web se debe reiniciar para tenerla en cuenta.