Directrices básicas de seguridad para aplicaciones web

Hoy en día, la mayoría de las interacciones y transacciones se realizan en línea, y las aplicaciones web se han convertido en herramientas indispensables para empresas, instituciones y usuarios. Sin embargo, esta dependencia del entorno virtual también ha hecho que aumente una preocupación: la seguridad. Las fallas de seguridad pueden provocar filtraciones de datos, pérdida de confianza de los usuarios, perjuicios económicos y daños irreparables a la reputación de una marca.

Con el aumento del número de ciberataques, desde intrusiones simples hasta amenazas más sofisticadas, como el ransomware y la ingeniería social, es fundamental que los desarrolladores, los responsables de tecnología y los equipos encargados de las aplicaciones web estén al día sobre las buenas prácticas de seguridad. Estas directrices ayudan a mitigar riesgos, proteger datos sensibles y garantizar la continuidad y la integridad de los sistemas.

Invertir en seguridad no es solo una cuestión técnica, sino también estratégica. Demostrar el compromiso con la protección de los datos de los usuarios es una ventaja competitiva y un pilar esencial para el éxito sostenible de cualquier aplicación web.

Este artículo se basa en el documento Web Security de Mozilla y explora las principales directrices y buenas prácticas que se deben conocer y aplicar para reducir las vulnerabilidades y crear aplicaciones más seguras, confiables y alineadas con las expectativas de un mundo cada vez más conectado.

Resumen de seguridad web

Este resumen presenta directrices esenciales para garantizar la seguridad de las aplicaciones web y clasifica cada práctica según su importancia, dificultad de implementación y orden de prioridad. A continuación, las recomendaciones:

Directriz	Dificultad	Observaciones
HTTPS	MEDIA	Todas las comunicaciones de los sitios deben usar HTTPS o protocolos seguros equivalentes.
Redireccionamientos HTTP	BAJA	Todos los sitios deben redirigir automáticamente a HTTPS. Las API deben deshabilitar HTTP.
Carga de recursos	BAJA	Tanto los recursos pasivos como los activos deben cargarse exclusivamente mediante protocolos TLS.
Seguridad de transporte estricta (HSTS)	BAJA	Se debe configurar con un período mínimo de seis meses.
Configuración de TLS	MEDIA	Utilice la configuración de TLS más segura, como la opción "Intermedia" recomendada por Mozilla.
Política de seguridad de contenido (CSP)	ALTA	Recomendada para sitios existentes. Priorice la desactivación de los scripts en línea para una mayor protección.

---

Lea también: Cómo eliminar mi sitio web de una lista negra

---

Seguridad de transporte estricta HTTP (HTTP Strict Transport Security, HSTS)

La seguridad de transporte estricta HTTP (HSTS) es un encabezado HTTP que indica a los navegadores que se conecten a un sitio solo mediante HTTPS, aunque el esquema original sea HTTP. Los navegadores que reciben la configuración HSTS de un sitio actualizarán automáticamente todas las solicitudes a HTTPS. Además, HSTS indica a los navegadores que traten los errores relacionados con TLS y los certificados con mayor rigor, y deshabiliten la posibilidad de que los usuarios ignoren la página de error.

El encabezado HSTS consta de un parámetro obligatorio (max-age) y dos opcionales (includeSubDomains y preload), separados por punto y coma.

Directivas

• max-age: Define durante cuánto tiempo los navegadores deben redirigir a HTTPS, en segundos.
• includeSubDomains: Indica si los navegadores deben actualizar las solicitudes de los subdominios.
• preload: Permite incluir el sitio en la lista de precarga de HSTS.

El valor de max-age debe configurarse para un período mínimo de seis meses (15768000 segundos). Se recomiendan períodos más largos, como dos años (63072000 segundos). Una vez configurado, el sitio debe seguir ofreciendo compatibilidad con HTTPS hasta que se cumpla el plazo de expiración.

La directiva includeSubDomains informa al navegador de que todos los subdominios del origen actual también deben actualizarse mediante HSTS. Se debe tener cuidado al habilitar esta configuración, ya que puede desactivar sitios en subdominios que aún no tengan HTTPS habilitado.

La directiva preload permite incluir el sitio en la lista de precarga de HSTS. Los navegadores realizarán actualizaciones automáticas a HTTPS sin necesidad de recibir el encabezado inicial. Se recomienda para sitios de alto riesgo, pero requiere que includeSubDomains también esté configurado.

Ejemplos

Conectarse al sitio solo mediante HTTPS durante los próximos dos años:

Strict-Transport-Security: max-age=63072000

Conectarse al sitio y a sus subdominios mediante HTTPS durante los próximos dos años e incluirlo en la lista de precarga:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Redireccionamientos HTTP

Los sitios pueden seguir escuchando en el puerto 80 (HTTP) para evitar que los usuarios reciban errores de conexión al escribir una URL en la barra de direcciones, ya que los navegadores suelen realizar la primera solicitud mediante HTTP. Sin embargo, los sitios que escuchan en el puerto 80 deben redirigir al mismo recurso en HTTPS. Después del redireccionamiento, HSTS debe garantizar que todos los futuros intentos de acceder al sitio mediante HTTP se envíen directamente al sitio seguro.

Los puntos de conexión de las API o los sitios que no están destinados al público en general deben deshabilitar por completo el uso de HTTP.

Evite los redireccionamientos de HTTP a HTTPS en un host diferente, ya que esto impide configurar HSTS. Por ejemplo, al redirigir, utilice el siguiente flujo:

1. Correcto: Primero redirija de http://exemplo.com/ a https://exemplo.com/ y, después, de https://exemplo.com/ a https://outroexemplo.com/.
2. Incorrecto: Redirigir directamente de http://exemplo.com/ a https://outroexemplo.com/.

Ejemplos de implementación

Redirigir todas las solicitudes HTTP al mismo recurso en HTTPS utilizando nginx:

server { 
listen 80; 
return 301 https://$host$request_uri; 
}

Redirigir las solicitudes de http://site.exemplo.org/ a https://site.exemplo.org/ utilizando Apache:

<VirtualHost *:80> 

ServerName site.exemplo.org 

Redirect permanent / https://site.exemplo.org/ 

</VirtualHost>

Política de seguridad de contenido (Content Security Policy, CSP)

La política de seguridad de contenido (CSP) es un encabezado HTTP que permite a los operadores de sitios controlar detalladamente desde dónde se pueden cargar los recursos de su sitio. El uso de este encabezado es el mejor método para prevenir vulnerabilidades de cross-site scripting (XSS). Debido a la dificultad de implementar CSP en sitios ya existentes, es obligatorio en todos los sitios nuevos y muy recomendable para los sitios existentes de alto riesgo.

Beneficios principales

El principal beneficio de CSP es la desactivación del uso de JavaScript en línea inseguro. JavaScript en línea, ya sea reflejado o almacenado, permite que las entradas de usuarios que no se han escapado correctamente generen código que el navegador interpreta como JavaScript. Al utilizar CSP para deshabilitar JavaScript en línea, es posible eliminar casi todos los ataques XSS contra el sitio.

Ten en cuenta que deshabilitar JavaScript en línea significa que todo el JavaScript debe cargarse desde etiquetas <script> con el atributo src. Los controladores de eventos como onclick utilizados directamente en las etiquetas fallarán, al igual que el JavaScript dentro de etiquetas <script> sin src. Además, los estilos en línea en etiquetas <style> o en el atributo style tampoco se cargarán. Por lo tanto, es necesario diseñar los sitios cuidadosamente para facilitar la implementación de CSP.

Notas de implementación

• Configurar CSP con default-src https: es un excelente primer objetivo, ya que desactiva el código en línea y exige HTTPS.
• Para los sitios existentes con grandes bases de código que harían inviable desactivar los scripts en línea, default-src https: 'unsafe-inline' sigue siendo útil, ya que impide cargar recursos mediante HTTP, pero no ofrece protección contra XSS.
• Se recomienda empezar con una política restrictiva, como default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self';, y agregar fuentes según sea necesario durante las pruebas.
• En lugar de utilizar el encabezado HTTP preferido, las páginas pueden incluir una etiqueta <meta http-equiv="Content-Security-Policy" content="...">. Si lo hacen, debe ser la primera etiqueta <meta> dentro de la etiqueta <head>.
• Tenga cuidado con las URI en formato data:, ya que son inseguras dentro de script-src y object-src (o si se heredan de default-src).
• Evite utilizar script-src 'self' en sitios con puntos de conexión JSONP. Deben especificar rutas seguras para los directorios que contienen los scripts.
• Si el sitio no requiere ejecutar complementos como Flash o Silverlight, deshabilítelos con object-src 'none'.
• Utilice la directiva report-uri para recibir informes en formato JSON sobre las infracciones de CSP y así poder corregirlas rápidamente.

Antes de la implementación, se recomienda utilizar el encabezado Content-Security-Policy-Report-Only para supervisar posibles infracciones.

Ejemplos

Deshabilitar el código en línea/eval y permitir recursos solo mediante HTTPS:

Content-Security-Policy: default-src https:

Política similar mediante una etiqueta :

<meta http-equiv="Content-Security-Policy" content="default-src https:">

Deshabilitar los complementos y permitir recursos del mismo origen e imágenes de un origen específico:

Content-Security-Policy: default-src 'self'; img-src 'self' https://i.imgur.com; object-src 'none'

Informar de las infracciones sin implementar aún la política:

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/

Intercambio de recursos entre orígenes (Cross-Origin Resource Sharing, CORS)

El encabezado HTTP Access-Control-Allow-Origin define qué orígenes externos tienen permiso para acceder al contenido de las páginas de su dominio mediante métodos como XMLHttpRequest. Archivos como crossdomain.xml y clientaccesspolicy.xml ofrecen funcionalidades similares para aplicaciones basadas en Flash y Silverlight, respectivamente.

Estos archivos o encabezados no deben estar presentes, a menos que sean específicamente necesarios. Entre los casos de uso válidos se incluyen las redes de distribución de contenido (CDN) que alojan bibliotecas de JavaScript/CSS y los endpoints de API públicas. Si están presentes, deben limitarse al mínimo de orígenes y recursos necesarios para funcionar correctamente.

Por ejemplo, si el servidor ofrece un sitio web y una API destinada al acceso mediante XMLHttpRequest desde sitios remotos, solo los recursos de la API deben devolver el encabezado Access-Control-Allow-Origin. No seguir esta práctica permite que orígenes externos lean el contenido de cualquier página de tu dominio.

Ejemplos

Permitir que cualquier sitio lea el contenido de esta biblioteca JavaScript para que funcione la integridad de subrecursos:

Access-Control-Allow-Origin: *

Permitir que solo https://dashboard.exemplo.org lea los resultados que devuelve esta API:

Access-Control-Allow-Origin: https://dashboard.exemplo.org

Permitir que Flash de https://dashboard.exemplo.org lea el contenido de la página:

<cross-domain-policy xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd">
  <allow-access-from domain="dashboard.exemplo.org"/>
  <site-control permitted-cross-domain-policies="master-only"/>
  <allow-http-request-headers-from domain="dashboard.exemplo.org" headers="*" secure="true"/>
</cross-domain-policy>

Permitir lo mismo para Silverlight:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        <domain uri="https://dashboard.exemplo.org"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Prevención de CSRF (Cross-Site Request Forgery)

Los ataques de falsificación de solicitudes entre sitios (CSRF) son una clase de ataques en los que se envían comandos no autorizados a un sitio desde un usuario de confianza. Como estos ataques heredan las cookies del usuario (y, por lo tanto, la información de sesión), parecen comandos válidos. Un ataque CSRF puede verse así:

<!-- Tentativa de excluir a conta de um usuário -->
<img src="https://contas.exemplo.org/gerenciamento/excluir?confirmar=true">

Cuando un usuario visita una página que contiene este fragmento de HTML, el navegador intentará realizar una solicitud GET a esa URL. Si el usuario está autenticado, el navegador enviará sus cookies de sesión y el intento de eliminar la cuenta se completará correctamente.

Aunque existen varias estrategias de mitigación, como las comprobaciones de Origen/Referer y los sistemas de desafío-respuesta (como CAPTCHA), el método más común y transparente para mitigar CSRF consiste en utilizar tokens anti-CSRF. Estos tokens evitan los ataques CSRF al exigir la existencia de un token secreto, único e impredecible en todos los cambios destructivos. Estos tokens pueden configurarse para toda la sesión del usuario, rotarse periódicamente o crearse de forma única para cada solicitud.

Aunque las cookies SameSite son la mejor defensa contra los ataques CSRF, todavía no cuentan con soporte completo en todos los navegadores. Por eso, deben usarse junto con otras medidas anti-CSRF.

Ejemplos

Un token anti-CSRF secreto incluido en un formulario para eliminar una cuenta:

<input type="hidden" name="csrftoken" value="1df93e1eafa42012f9a8aff062eeb1db0380b">

El servidor define una cookie anti-CSRF que JavaScript debe enviar como encabezado X:

Set-Cookie: CSRFTOKEN=1df93e1eafa42012f9a8aff062eeb1db0380b; Path=/; Secure; SameSite=Strict

En el cliente, JavaScript añade el token como encabezado X-CSRF-Token en la solicitud XMLHttpRequest:

var token = readCookie('CSRFTOKEN'); // lê o cookie
httpRequest.setRequestHeader('X-CSRF-Token', token); // adiciona como cabeçalho X-CSRF-Token

Política de referencia (Referrer Policy)

Cuando un usuario navega a un sitio mediante un hipervínculo o cuando un sitio carga un recurso externo, los navegadores informan al sitio de destino del origen de la solicitud mediante el encabezado HTTP Referer (sic). Aunque esto puede ser útil para diversos fines, también puede poner en riesgo la privacidad de los usuarios. La Política de referencia permite que los sitios controlen en detalle cómo y cuándo los navegadores transmiten el encabezado Referer.

En los navegadores antiguos, si una página en https://exemplo.com/pagina.html contiene <img src="https://nao.exemplo.com/imagem.jpg">, el navegador enviará una solicitud como esta:

GET /imagem.jpg HTTP/1.1
Host: nao.exemplo.com
Referer: https://exemplo.com/pagina.html

Además de los riesgos para la privacidad, el navegador también puede transmitir URL de uso interno que no estaban destinadas a revelarse. Si, como operador del sitio, quieres limitar la exposición de esta información, puedes usar la Política de referencia para eliminar el encabezado Referer o reducir la cantidad de información que contiene.

Directivas

• no-referrer: No enviar nunca el encabezado Referer.
• same-origin: Enviar el encabezado Referer, pero solo en solicitudes al mismo origen.
• strict-origin: Enviar el referente a todos los orígenes, pero solo con la URL sin la ruta (por ejemplo, https://exemplo.com/).
• strict-origin-when-cross-origin: Enviar el referente completo en el mismo origen y solo la URL sin la ruta a los orígenes externos.

Observaciones

• Aunque existen otras opciones para las políticas de referencia, no protegen la privacidad del usuario ni limitan la exposición de la misma manera que las opciones enumeradas anteriormente.
• La directiva strict-origin-when-cross-origin es el comportamiento predeterminado en todos los navegadores modernos.
• La Política de referencia cuenta con amplio soporte en los navegadores modernos. En las versiones recientes de Firefox y Safari, las directivas «no seguras» (como no-referrer-when-downgrade, origin-when-cross-origin y unsafe-url) se comportan como el valor predeterminado strict-origin-when-cross-origin.

Ejemplos

En ejemplo.com, enviar el encabezado Referer solo al cargar o enlazar otros recursos de ejemplo.com:

Referrer-Policy: same-origin

Enviar el referente abreviado a un origen externo y el referente completo al host local:

Referrer-Policy: strict-origin-when-cross-origin

Deshabilitar los referentes en los navegadores que no admiten strict-origin-when-cross-origin:

Referrer-Policy: no-referrer, strict-origin-when-cross-origin

Configurar la política con una etiqueta:

<meta http-equiv="Referrer-Policy" content="no-referrer, strict-origin-when-cross-origin">

Configuración directa en el elemento HTML:

<a href="https://exemplo.org/" referrerpolicy="no-referrer">

robots.txt

El archivo robots.txt es un archivo de texto ubicado en el directorio raíz de un sitio para indicar a los robots (como los indexadores que usan los motores de búsqueda) cómo deben comportarse, dándoles instrucciones para que no rastreen determinadas rutas del sitio. Esto resulta especialmente útil para reducir la carga del sitio al deshabilitar el rastreo de contenido generado automáticamente. También puede ayudar a evitar que los resultados de búsqueda se llenen de contenido irrelevante, en especial en el caso de recursos que no aportan valor a la indexación.

Los sitios pueden usar robots.txt de forma opcional, pero solo debe utilizarse para estos fines. No debe usarse para evitar la divulgación de información privada ni para ocultar partes del sitio. Aunque esto impide que ese contenido aparezca en los motores de búsqueda, no evita que los atacantes lo descubran, ya que el archivo robots.txt suele usarse como fuente de reconocimiento.

Ejemplos

Bloquear el rastreo de este sitio a todos los motores de búsqueda:

User-agent: *
Disallow: /

Intentar ocultar determinados directorios mediante robots.txt (método no recomendado):

User-agent: *
Disallow: /secret/admin-interface

Integridad de subrecursos (Subresource Integrity, SRI)

La Integridad de subrecursos (SRI) es un estándar reciente del W3C que protege contra ataques que modifican el contenido de bibliotecas JavaScript alojadas en redes de distribución de contenido (CDN) para crear vulnerabilidades en todos los sitios que las utilizan.

Por ejemplo, el código JavaScript de jquery.org cargado desde example.org tiene acceso total al contenido del sitio example.org. Si este recurso se ve comprometido, puede modificar enlaces de descarga, desfigurar el sitio, robar credenciales, provocar ataques de denegación de servicio (DoS) y mucho más.

SRI restringe un recurso JavaScript externo a un contenido conocido en un momento específico. Si el archivo se modifica posteriormente, los navegadores compatibles se negarán a cargarlo. Por lo tanto, el uso de SRI es obligatorio para todos los recursos JavaScript externos cargados desde fuentes que no controla Mozilla.

Observaciones

Los CDN deben admitir el estándar Cross-Origin Resource Sharing (CORS) mediante la configuración del encabezado Access-Control-Allow-Origin. La mayoría de los CDN ya lo admiten, pero, si el CDN que utilizas no es compatible con CORS, ponte en contacto con el equipo de Garantía de Seguridad para recibir asistencia.

Directivas

• integrity: Un hash criptográfico del archivo, precedido por la función hash utilizada para generarlo.
• crossorigin: Debe configurarse como anonymous para indicar a los navegadores que envíen solicitudes anónimas sin cookies.

Ejemplos

Cargar jQuery 2.1.4 desde un CDN con SRI habilitado:

<script src="/storage/blog/importado/diretrizes-basicas-de-seguranca-para-aplicacoes-web-8d909bb3.js"
        integrity="sha384-R4/ztc4ZlRqWjqIuvf6RX5yb/v90qNGx6fS48N0tRxiGkqveZETq72KgDVJCp2TC"
        crossorigin="anonymous"></script>

Opciones de tipo de contenido (X-Content-Type-Options)

El encabezado HTTP X-Content-Type-Options es compatible con los navegadores Internet Explorer, Chrome y Firefox (a partir de la versión 50), y les indica que no carguen scripts ni hojas de estilo a menos que el servidor indique el tipo MIME correcto. Sin este encabezado, estos navegadores pueden identificar incorrectamente archivos como scripts y hojas de estilo, lo que puede dar lugar a ataques de cross-site scripting (XSS).

Por lo tanto, todos los sitios deben configurar el encabezado X-Content-Type-Options y los tipos MIME adecuados para los archivos que sirven.

Ejemplos

Evitar que los navegadores detecten incorrectamente archivos que no sean scripts como si fueran scripts:

X-Content-Type-Options: nosniff

Opciones de marco (X-Frame-Options)

El encabezado HTTP X-Frame-Options permite que los sitios controlen cómo pueden incorporarse en un iframe. El secuestro de clics es un ataque práctico que permite que sitios maliciosos engañen a los usuarios para que hagan clic en enlaces de su sitio, aunque parezca que no están en él. Por eso, el uso del encabezado X-Frame-Options es obligatorio para todos los sitios nuevos, y los sitios existentes deberían añadirlo lo antes posible.

X-Frame-Options fue reemplazado por la directiva frame-ancestors de la Política de Seguridad de Contenido (CSP), que ofrece un control mucho más granular sobre los orígenes autorizados a incorporar el sitio. Como frame-ancestors aún no es compatible con IE11 y versiones anteriores, Edge, Safari 9.1 (escritorio) y Safari 9.2 (iOS), se recomienda que los sitios utilicen X-Frame-Options además de CSP.

Los sitios que necesitan poder incorporarse en iframes deben utilizar la Política de Seguridad de Contenido (CSP) y/o emplear defensas en JavaScript para prevenir ataques de secuestro de clics desde orígenes maliciosos.

Directivas

• DENY: Bloquea cualquier intento de incorporar el sitio en iframes (recomendado).
• SAMEORIGIN: Permite que el sitio se incorpore en iframes de su propio origen.
• ALLOW-FROM uri: Directiva obsoleta. Utilice en su lugar la directiva frame-ancestors de CSP.

Ejemplos

Bloquear la incorporación del sitio mediante X-Frame-Options y CSP:

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY

Permitir que solo el propio sitio se incorpore:

Content-Security-Policy: frame-ancestors 'self'
X-Frame-Options: SAMEORIGIN

Permitir que solo framer.exemplo.org incorpore el sitio:

Content-Security-Policy: frame-ancestors https://framer.exemplo.org
X-Frame-Options: DENY

Implementación y verificación de la seguridad de aplicaciones web

La seguridad de las aplicaciones web es un componente esencial para proteger los datos y la privacidad de los usuarios. Este documento presentó un conjunto integral de directrices que, si se implementan correctamente, ayudan a mitigar los riesgos y las vulnerabilidades comunes. Sin embargo, implementar estas directrices es solo el primer paso. Probar y validar estas configuraciones con regularidad es igual de crucial para garantizar que funcionen según lo previsto.

Para facilitar el proceso de verificación, existen herramientas en línea que pueden analizar su sitio y proporcionar informes detallados sobre la implementación de las mejores prácticas de seguridad. A continuación, presentamos algunas sugerencias:

Herramientas recomendadas para pruebas de seguridad

1. Mozilla Observatory
   Mozilla Observatory es una herramienta robusta que analiza la configuración de seguridad de su sitio, incluidos los encabezados de seguridad HTTP, HTTPS, CSP, HSTS y mucho más. Proporciona puntuaciones y recomendaciones detalladas para mejorar la seguridad.
   Acceda aquí
2. Security Headers
   Este servicio gratuito permite probar rápidamente los encabezados de seguridad de su sitio, como X-Content-Type-Options, X-Frame-Options y Content-Security-Policy. Señala configuraciones faltantes o incorrectas y sugiere mejoras.
   Acceda aquí
3. SERPWorx Security Headers Checker
   Una alternativa que también verifica la implementación de los encabezados de seguridad en su sitio y proporciona información clara y práctica sobre lo que está correcto y lo que debe ajustarse.
   Acceda aquí
4. SRI Hash Generator
   Si el sitio utiliza recursos externos, esta herramienta genera hashes para implementar Subresource Integrity (SRI) y garantizar que los archivos cargados desde CDN no hayan sido alterados.
   Acceda aquí

Prácticas recomendadas para pruebas periódicas

• Automatice las comprobaciones de seguridad: Utilice herramientas de integración continua para ejecutar pruebas automatizadas con cada actualización del sitio.
• Realice auditorías manuales: Complementar las herramientas automáticas con revisiones humanas puede ayudar a identificar problemas más complejos.
• Capacite al equipo: Asegúrese de que los desarrolladores y operadores comprendan la importancia de las directrices de seguridad y sepan cómo implementarlas.

Implementar estas medidas ayudará no solo a proteger sus sistemas y usuarios, sino también a construir una sólida reputación en el mercado como una organización confiable y comprometida con la seguridad. Utilice estas herramientas con regularidad para adelantarse a las amenazas y garantizar que su sitio siga siendo seguro en un panorama de amenazas en constante evolución.