Impedir la adquisición de subdominios en Azure App Service

Las adquisicións de subdominios son una amenaza común para las organizaciones que crean y eliminan muchos recursos con regularidad. Una adquisición de subdominio puede producirse cuando tiene un registro DNS que apunta a un recurso de Azure desaprovisionado. Estos registros DNS también se conocen como entradas "DNS pendientes". Las adquisicións de subdominios permiten a los actores malintencionados redirigir el tráfico destinado al dominio de una organización a un sitio que realiza actividades malintencionadas.

Los riesgos de la adquisición de subdominios incluyen:

• Pérdida de control sobre el contenido del subdominio
• Captura de cookies de visitantes desprevenidos
• Campañas de phishing
• Riesgos adicionales de ataques clásicos, como XSS, CSRF o omisión de CORS

Para más información sobre la adquisición de subdominios, consulte Prevención de entradas DNS pendientes y evitar la adquisición de subdominios.

Azure App Service proporciona reserva de nombres, tokens de verificación de dominio y nombres de host predeterminados únicos y seguros para evitar el secuestro de subdominios.

Protección de nombres de host predeterminados únicos (recomendado)

La manera más eficaz de proteger los recursos de App Service de la adquisición de subdominios es usar nombres de host predeterminados seguros. Esta característica está disponible con carácter general para Web Apps, Function Apps y Logic Apps (Estándar).

Al habilitar nombres de host predeterminados únicos seguros, la aplicación recibe un nombre de host predeterminado que incluye un hash aleatorio y un identificador de región, lo que lo convierte en único para su organización. Este formato garantiza que nadie fuera de la organización pueda crear un recurso con el mismo nombre de host predeterminado, lo que elimina el riesgo de adquisición de subdominios a través de entradas DNS pendientes.

Cómo funciona

Los recursos tradicionales de App Service usan un formato de nombre de host predeterminado que es predecible globalmente:

Por ejemplo, una aplicación web denominada contoso implementada en este de EE. UU. podría recibir:

contoso-a6gqaeashthkhkeu.eastus-01.azurewebsites.net

El hash de 16 caracteres es determinista dentro de un ámbito configurable, por lo que puede garantizar nombres de host coherentes entre entornos cuando sea necesario.

Opciones de ámbito de hash

Al crear un recurso con un nombre de host predeterminado único, elija un ámbito que determine cómo se genera el hash:

Espacios de despliegue

Las ranuras de implementación siguen el mismo formato que el sitio de producción, pero cada ranura recibe su propio hash distinto:

Siempre se crean ranuras con el mismo ámbito que el sitio de producción.

Cómo habilitar

Configuras nombres de host únicos y seguros por defecto cuando creas el recurso. No puedes aplicarlos retroactivamente a recursos existentes. La forma en que los activas depende del cliente que utilices:

• Portal Azure: Las nuevas Web Apps, Function Apps y Logic Apps (Estándar) creadas en el portal de Azure utilizan nombres de host únicos y seguros por defecto automáticamente en todos los SKUs compatibles. No se requiere ninguna configuración adicional.
• CLI de Azure, plantillas ARM y API REST: Debes optar explícitamente estableciendo el alcance del nombre de host en la solicitud de creación. Establece este valor para cada nuevo despliegue para que los recursos creados fuera del portal usen el mismo formato de nombre de host predeterminado que los recursos creados en el portal.

{
    "location": "Central US",
    "kind": "app",
    "properties": {
        "serverFarmId": "<AppServicePlanResourceId>",
        "AutoGeneratedDomainNameLabelScope": "TenantReuse"
    }
}

Migración de recursos existentes

Puesto que esta característica solo se puede habilitar en el momento de la creación, tiene dos opciones para los recursos existentes:

• Clone una aplicación preexistente en una nueva aplicación con nombres de host predeterminados únicos y seguros habilitados.
• Restaurar a partir de una copia de seguridad en una nueva aplicación con nombres de host predeterminados únicos y seguros activados.

Ambas opciones están disponibles en el portal de Azure.

¿Por qué adoptar esto ahora?

Los nombres de host predeterminados seguros proporcionan protección de forma predeterminada. A diferencia de otras estrategias de mitigación que requieren la higiene continua de DNS y la intervención manual, este enfoque crea la seguridad directamente en la estructura del nombre de host. Cuando esté habilitado:

• Ningún actor externo puede volver a crear el nombre de host predeterminado.
• Las entradas de DNS pendientes no se pueden aprovechar para la adquisición de subdominios.
• No se necesitan pasos de configuración adicionales más allá de habilitar la característica en el momento de la creación.

Utiliza nombres de host únicos y seguros por defecto para cada nuevo despliegue de Servicio de Aplicaciones. El portal de Azure ya aplica esta configuración automáticamente para nuevos recursos en SKUs compatibles. Alinear tus despliegues de CLI de Azure, plantilla ARM y API REST con el mismo formato predeterminado de nombre de host mantiene tu aprovisionamiento coherente con la configuración recomendada de App Service.

Contenido relacionado

• Versión preliminar pública: creación de una aplicación web con un nombre de host predeterminado único
• Nombres de host predeterminados únicos y seguros: disponibilidad general en App Service Web Apps y versión preliminar pública en Functions
• Nombres de host predeterminados únicos protegidos, ahora disponibles con carácter general para Functions y Logic Apps

Cómo App Service impide la adquisición de subdominios

Tras la eliminación de una aplicación de App Service o App Service Environment (ASE), el DNS correspondiente no se puede reutilizar excepto por las suscripciones que pertenecen al inquilino de la suscripción que originalmente posee el DNS. Por lo tanto, el cliente tiene algún tiempo para limpiar las asociaciones o punteros a dicho DNS o reclamar el DNS en Azure mediante la recreación del recurso con el mismo nombre. Este comportamiento está habilitado de forma predeterminada en Azure App Service para *.azurewebsites.net los recursos y *.appserviceenvironment.net , por lo que no requiere ninguna configuración del cliente.

Escenario de ejemplo

La suscripción A y la suscripción B son las únicas suscripciones que pertenecen al inquilino AB. La suscripción A contiene una aplicación web de App Service test con el nombre DNS test.azurewebsites.net. Tras la eliminación de la aplicación, solo las suscripciones A o B pueden reutilizar inmediatamente el nombre test.azurewebsites.net DNS mediante la creación de una aplicación web denominada test. No se permite a ninguna otra suscripción reclamar el nombre justo después de la eliminación del recurso.

Cómo puede evitar la adquisición de subdominios

Al crear entradas DNS para Azure App Service, cree un asuid.{subdomain} registro TXT con la ID de verificación del dominio. Cuando existe un registro TXT de este tipo, ninguna otra suscripción de Azure puede validar el dominio personalizado o asumirlo a menos que agreguen su identificador de verificación de token a las entradas DNS.

Estos registros impiden la creación de otra aplicación de App Service con el mismo nombre de la entrada CNAME. Sin la capacidad de demostrar la propiedad del nombre de dominio, los actores de amenazas no pueden recibir tráfico ni controlar el contenido.

Los registros DNS deben actualizarse antes de la eliminación del sitio para asegurarse de que los actores incorrectos no pueden asumir el dominio entre el período de eliminación y la nueva creación.

Para obtener un identificador de comprobación de dominio, consulte Configuración de un dominio personalizado existente en Azure App Service.