Al añadir enlaces personalizados al contenido, evite siempre cualquier personalización en la parte del nombre de host de la dirección URL para evitar posibles lagunas de seguridad. Los siguientes ejemplos nunca deben utilizarse en todos los atributos de URL <a href="">
o <img src="">
:
<%= url >
https://<%= url >
https://<%= domain >/path
https://<%= sub-domain >.domain.tld/path
https://sub.domain<%= main domain %>/path
Para validar y asegurarse de que no está utilizando lo anterior, ejecute una consulta en la tabla URL de seguimiento mediante Editor de consultas genérico de campaña o crear un flujo de trabajo con criterios de filtro en la variable actividad de consulta.
Ejemplo:
Creación de un flujo de trabajo y adición de Consulta actividad. Más información.
Abra el Consulta y cree un filtro en la nmsTrackingUrl
como se indica a continuación:
source URL starts with http://<% or source URL starts with https://<%
Ejecute el flujo de trabajo y compruebe si hay resultados.
Si es así, abra la transición de salida para ver la lista de las direcciones URL.
Para mejorar la seguridad, se ha introducido un mecanismo de firma para el seguimiento de vínculos en correos electrónicos. Está disponible a partir de las versiones 19.1.4 (9032@3a9dc9c) y 20.2. Esta función está habilitada de forma predeterminada.
Cuando se hace clic en una dirección URL firmada con formato incorrecto, se devuelve este error: Requested URL '…' was not found.
Además, puede utilizar una mejora para deshabilitar las direcciones URL generadas en versiones anteriores. Esta función está deshabilitada de forma predeterminada. Puede ponerse en contacto con Servicio de atención al cliente para activar esta función.
Si se ejecuta en la versión 19.1.4, es posible que se produzcan problemas con las entregas de notificaciones push mediante vínculos de seguimiento o con las entregas que utilizan etiquetas de anclaje. Si es así, se recomienda desactivar la firma de URL.
Como cliente alojado en una campaña, Cloud Services administrados o híbrido, debe ponerse en contacto con Servicio de atención al cliente para que la firma URL esté deshabilitada.
Si está ejecutando Campaign en una arquitectura híbrida, antes de habilitar la firma de URL, asegúrese de que la instancia de mid-sourcing alojada se haya actualizado de la siguiente manera:
De lo contrario, podrían producirse algunos de estos problemas:
Para deshabilitar las direcciones URL que se han generado en versiones anteriores, siga estos pasos en todos los servidores de Campaign al mismo tiempo:
serverConf.xml
), cambie la variable blockRedirectForUnsignedTrackingLink a true.nlserver
servicio.tracking
servidor, reinicie el web
servidor (apache2 en Debian, httpd en CentOS/RedHat, IIS en Windows).Para habilitar la firma de URL, siga estos pasos en todos los servidores de Campaign al mismo tiempo:
serverConf.xml
), cambiar signEmailLinks para true.tracking
servidor, reinicie el web
servidor (apache2 en Debian, httpd en CentOS/RedHat, IIS en Windows).Debe asegurarse de que un usuario autenticado con privilegios bajos no pueda acceder a las contraseñas cifradas. Para ello, restrinja el acceso solo a los campos de contraseña o a toda la entidad (necesita una compilación >= 8770).
Esta restricción permite eliminar los campos con contraseñas, pero permite a la cuenta externa acceder a ella desde la interfaz de todos los usuarios. Más información.
Para ello, siga los pasos a continuación:
Vaya a la Administration > Configuration > Data schemas carpeta del explorador de Campaign.
Cree un esquema de datos como Extension of a schema.
Choose External Account (extAccount).
En la última pantalla del asistente, edite el nuevo "srcSchema" para restringir el acceso a todos los campos de contraseña:
Puede reemplazar el elemento principal (<element name="extAccount" ... >
) de:
<element name="extAccount">
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
<element name="s3Account">
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="awsSecret"/>
</element>
<element name="wapPush">
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
</element>
<element name="mms">
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
</element>
</element>
Por lo tanto, el srcSchema extendido puede tener el siguiente aspecto:
<srcSchema _cs="External Accounts (cus)" created="2017-05-12 07:53:49.691Z" createdBy-id="0"
desc="Definition of external accounts (Email, SMS...) used by the modules"
entitySchema="xtk:srcSchema" extendedSchema="nms:extAccount" img="" label="External Accounts"
labelSingular="External account" lastModified="2017-05-12 08:33:49.365Z"
mappingType="sql" md5="E9BB0CD6A4375F500027C86EA854E101" modifiedBy-id="0"
name="extAccount" namespace="cus" xtkschema="xtk:srcSchema">
<createdBy _cs="Administrator (admin)"/>
<modifiedBy _cs="Administrator (admin)"/>
<element name="extAccount">
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
<element name="s3Account">
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="awsSecret"/>
</element>
<element name="wapPush">
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
</element>
<element name="mms">
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
<attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
</element>
</element>
</srcSchema>
Puede reemplazar $(loginId) = 0 or $(login) = 'admin'
con hasNamedRight('admin')
para permitir que todos los usuarios con derechos de administrador vean estas contraseñas.
Recomendamos encarecidamente a los clientes locales que protejan las páginas que puedan contener información personal (API), como páginas espejo, aplicaciones web, etc.
El objetivo de este procedimiento es evitar que estas páginas se indexen, evitando así un posible riesgo de seguridad. A continuación se muestran algunos artículos útiles:
Para proteger sus páginas, siga estos pasos:
Agregue un robots.txt
en la raíz del servidor web (Apache o IIS). Aquí está el contenido del archivo:
# Make changes for all web spiders
User-agent:
*Disallow: /
Para IIS, consulte esta página.
Para Apache, puede colocar el archivo en /var/www/robots.txt (Debian).
A veces, añadir un robots.txt no es suficiente en términos de seguridad. Por ejemplo, si otro sitio web contiene un vínculo a la página, puede aparecer en un resultado de búsqueda.
Además del robots.txt , se recomienda añadir un X-Robots-Tag encabezado. Puede hacerlo en Apache o IIS y en la serverConf.xml archivo de configuración.
Para obtener más información, consulte este artículo.
Consulte esta página para obtener información general sobre qué es la administración de privacidad y los pasos de implementación en Adobe Campaign. También encontrará recomendaciones e información general del proceso y de los perfiles del usuario.