Seguridad para Kentico

El objetivo de este documento es proporcionar comprensión genérica de los controles de seguridad de Kentico, debido a que es uno de los manejadores de contenido que utiliza la tecnología ASP.NET y Microsoft SQL Server. Kentico, es tan segura como casi cualquier otra aplicación de Microsoft, se establecen de seguridad para fortificar las aplicaciones.
 
En este artículo les dejo algunas recomendaciones de seguridad que ayudarán a fortificar los proyectos en Kentico. Entendemos que la seguridad absoluta no existe y menos en este tipo de plataformas tan ampliamente utilizadas, sin embargo, comencemos a dar pasos para mejorar nuestros productos y a tomar mayor conciencia de la ciberseguridad, lo que redundará positivamente en un robustecimiento de nuestros desarrollos y un aumento en la calidad de nuestro trabajo. 
 
Kentico no anuncia públicamente los problemas de seguridad. Con el fin de no facilitar a los atacantes determinados problemas, que aún no están actualizados, por lo que si desean conocer los problemas de seguridad deben suscribirse al boletín a través de este enlace. Esta guía se ha desarrollado obteniendo toda la información de la página principal de Kentico añadiendo la experiencia que tenemos con él, por lo que la información contenida está actualizada hasta el momento.
 
Debido a que Kentico se ejecuta sobre IIS, en la entrada anterior se dieron pautas para fortalecer el servidor IIS en cuanto al uso de cabeceras de seguridad, lo podéis ver en el siguiente enlace.
 
Se recomienda seguir esta serie de pautas para garantizar, para añadir capas adicionales de seguridad.
 

Configurar SSL

El protocolo Secure Sockets Layer se usa para cifrar la comunicación de Internet. Esto es importante para proteger la privacidad de sus usuarios y para proteger la información confidencial que se envía, para ello basta con hacer uso de un certificado autofirmado o de una entidad certificadora.
 

Crear un certificado autofirmado en IIS

Desde el Administrador de IIS.
Haga clic en el nombre de su servidor en la columna Conexiones a la izquierda.
Haga doble clic en los certificados del servidor.
 

 
En el panel Acciones, haga clic en Crear certificado autofirmado.
 

 
Escriba un nombre descriptivo para el certificado en el cuadro especificar un nombre descriptivo para el certificado y haga clic en Aceptar.



Si ya tiene un certificado SSL (autofirmado o de una autoridad de certificación), debe configurarlo en el servidor IIS para que pueda usarlo para realizar conexiones seguras.
 
Desde el Administrador de IIS.
Seleccione el sitio web al que desee vincular el certificado en la columna Conexiones a la izquierda.
Haga clic en Enlaces en la columna Acciones.


 
Haga clic en Agregar, cambie el tipo a https y seleccione el certificado de la lista.


 
Haga clic en Aceptar y cierre el cuadro de diálogo Enlaces de sitios.
El servidor IIS ahora está listo para usar el certificado asignado con protocolo de enlace SSL para las conexiones entrantes.
 

No Revelar Información

El siguiente paso para fortalecer los encabezados de respuesta HTTP y no dar pistas a los atacantes, es mirar las respuestas de las peticiones web que se pueden eliminar para reducir la cantidad de información que está divulgando sobre su servidor y lo que se está ejecutando en él. Lo primero que se necesita es la extensión URL-Rewrite. Una vez instalada, dirígete al administrador de IIS y selecciona tu sitio, luego ingresar en el icono reescribe URL.
 

 
Selecciona variables de servidor y luego agregue una nueva variable de servidor llamada RESPONSE_SERVER.
 

 




Una vez que tengamos la nueva variable de servidor, regrese a la página de reglas, agregue una nueva regla y seleccione una regla de salida en blanco.
 





 
Asigne un nombre a la regla, establezca el alcance de coincidencia en la variable del servidor, el nombre de la variable es RESPONSE_SERVER y configure el pattern en. *Para que coincida con cualquier contenido, y crear cualquier entrada que se desee mostrar en el campo del servidor añadiendo el parámetro en value, si se deja en blanco la respuesta será en la respuesta del server en blanco. Otra forma es iniciar el administrador de IIS, luego en el panel izquierdo de la ventana, haga clic en el sitio web al que desea modificar el encabezado y haga doble clic en encabezados de respuesta HTTP. Se debe modificar el encabezado “X-Powered-By” o simplemente eliminarlo. De esta forma garantizamos que en la respuesta del servidor no se enviara información del mismo.
 

Restrinja el acceso a directorios

Solo permita que los usuarios accedan a los directorios del sistema de archivos que realmente necesitan. Esto significa que debe prohibir el acceso a los directorios a todos los usuarios que no los necesitan.
Puede configurar restricciones de directorio en el archivo web.config del proyecto. El siguiente ejemplo prohíbe el acceso al directorio CMSSiteUtils de acuerdo con la configuración del elemento <authorization>.
 

<location path="CMSSiteUtils">
    <system.webServer>
        <security>
            <authorization>
                <remove users="*" roles="" verbs="" />
             <add accessType="Allow” users="" roles=""/>
            </authorization>
        </security>
    </system.webServer>
</location>

 
El directorio CMSSiteUtils contiene archivos de exportación y, por lo tanto, es el más vulnerable y debe protegerse adecuadamente.
 

Deshabilitar la exploración de directorios

Se recomienda deshabilitar la lista de directorios para todo el sitio web, aunque también puede deshabilitar esta función solo para directorios individuales. En tal caso, no olvide deshabilitar la exploración de directorios para el directorio CMSSiteUtils.
 



 
Una vez deshabilitado no será posible enumerar archivos en directorios en su sitio web.
 

Deshabilitar los Métodos Innecesarios

Iniciar el administrador de IIS, se debe abrir la carpeta de Filtrado de solicitudes, en el panel izquierdo seleccionar los verbos y denegar los siguientes (OPTIONS, PUT, DELETE, TRACER)
 



 

Asegurar las Cookies

Los datos pueden estar expuestos a terceros no autorizados durante la transmisión de cookies y esto aumenta el riesgo de robo de sesión a través de ataques intermedios o de detección de tráfico, por lo que se recomienda habilitar las Flags HttpOnly y Secure como se explica a continuación.
 

Habilitar Flag HttpOnly en el IIS

Edite el archivo web.config de su aplicación web y agregue lo siguiente:
 

<system.web>
           <httpCookies httpOnlyCookies= "true" requireSSL= "true" />
</system.web>

 

Habilitar Flag Secure en el IIS

Para habilitar el indicador seguro en IIS, es mejor usar URL Rewrite y agregar lo siguiente a su archivo web.config:
 

<system.webServer>
  <rewrite>
    <outboundRules>
      <rule name="Use only secure cookies" preCondition= "Unsecured cookie">
        <match serverVariable="RESPONSE_SET_COOKIE" pattern=".*" negate="false" />
        <action type="Rewrite" value="{R:0}; secure" />
      </rule>
      <preConditions>
        <preCondition name="Unsecured cookie">
          <add input="{RESPONSE_SET_COOKIE}" pattern="." />
          <add input="{RESPONSE_SET_COOKIE}" pattern="; secure" negate="true" />
        </preCondition>
      </preConditions>
    </outboundRules>
  </rewrite>
...
</system.webServer>

 

Control de Autenticación

Se recomienda utilizar cookies de sesión (no usar autenticación cookieless) para evitar el secuestro de sesión. Esto se puede hacer cambiando el atributo cookieless del elemento de formulario. También puede establecer estos atributos:
 

<authentication mode="Forms">
<forms loginUrl="CMSPages/logon.aspx" name=".ASPXFORMSAUTH" cookieless="UseCookies" requireSSL="true" timeout="15" slidingExpiration="false" />
</authentication>

 
La solución más segura es establecer un intervalo de tiempo de espera corto (por ejemplo, 15 minutos). De esta manera, si los atacantes robaran la sesión, solo tendrían un tiempo limitado para abusar de ella. Sin embargo, los usuarios deberán enviar sus credenciales y autenticarse cada vez que caduque la sesión (establecida por el atributo de tiempo de espera).
 
Para su configuración en .NET
 

Protección de la sesión

Se recomienda usar cookies en lugar de cadenas de consulta para pasar la ID de sesión. Esto evitará el robo de sesiones, ya que es más fácil robar el ID de sesión de las cadenas de consulta que las cookies. Para proteger las sesiones contra ataques, debe establecer los siguientes atributos del elemento sessionState:

• Mode: Especifica dónde almacenar los valores de estado de la sesión.
• Cookieless: Especifica cómo se utilizan las cookies para una aplicación web.
• Timeout: Especifica el número de minutos que una sesión puede estar inactiva antes de que se abandone.

 <sessionState mode="InProc" cookieless="false" timeout="15" />

Para su configuración en .NET
 

Cifrar secciones individuales del archivo web.config

Puede encriptar las secciones elegidas del archivo web.config, lo que puede evitar que los atacantes obtengan información confidencial. El cifrado se puede hacer usando RSAProtectedConfigurationProvider esta herramienta es adecuada para proteger los archivos web.config en granjas web. Tenga en cuenta que ASP.NET descifra automáticamente las secciones de configuración cuando las procesa; por lo tanto, no necesita escribir ningún código de descifrado adicional. Para cifrar las secciones de configuración utilizando el proveedor de configuración protegido por RSA, realice lo que se indica en este enlace.

 

Evitar la fijación de la sesión

La mejor práctica para proteger su aplicación contra la fijación de la sesión es regenerar la ID de la sesión después de que un usuario la inicie. Puede lograrlo cambiando la ID de sesión a una cadena vacía y dejando que ASP.NET genere una nueva. Sin embargo, esta acción provoca la pérdida de datos de sesión.
Se puede incluir la clave CMSRenewSessionAuthChange en la sección AppSettings de su archivo web.config, que impone un cambio en la ID de la sesión cuando un usuario inicia o cierra sesión. Si habilita esta configuración, los usuarios no podrán conservar sus datos de sesión después de iniciar o cerrar sesión.
<add key="CMSRenewSessionAuthChange" value="true" />
 

Controlar los mensajes de error

Se debe configurar el manejo de todo tipo de errores y excepciones a través del elemento <customErrors> en la sección <system.web> de su archivo web.config.

Debe ingresar el código de respuesta HTTP del error dado en el atributo statusCode y la URL de la página de error apropiada como el valor de redireccionamiento.

Se recomienda agregar páginas de error general directamente en su proyecto web como archivos .aspx, por ejemplo, en la carpeta CMSMessages.

Tenga en cuenta que sus páginas de error personalizadas siempre deben devolver el código de estado HTTPResponse apropiado.
 

<system.web>
...
    <customErrors mode="RemoteOnly">
           <error statusCode="500" redirect="~/CMSMessages/CustomError.aspx" />
           <error statusCode="503" redirect="~/CMSMessages/CustomError.aspx" />
    </customErrors>
...
</system.web>

 
Al usar <customErrors>, se recomienda deshabilitar el manejo de errores en servidor IIS agregando un elemento httpErrors bajo el elemento principal <system.webServer> de la aplicación, con el atributo existenteResponse establecido en PassThrough:
 

<system.webServer>
...
    <httpErrors existingResponse="PassThrough" />
...
</system.webServer>

 
Realice los siguientes pasos para asegurarse de que el sistema devuelva su página de error de “Página No Encontrada” personalizada para solicitudes no válidas que se dirigen a todo tipo de contenido del sitio, no solo a las páginas procesadas por el motor Kentico:
 
Edite el archivo web.config de su aplicación.

Busque la sección system.webServer directamente debajo de la raíz (es decir, no debajo de un elemento <location> específico).

Establezca el atributo runAllManagedModulesForAllRequests en verdadero para la etiqueta de apertura del elemento <modules>:
 

<system.webServer>
            <modules runAllManagedModulesForAllRequests="true">
</modules>

 
Alternativamente, el manejo de errores también se puede configurar en el nivel IIS a través del elemento <httpErrors> bajo el elemento principal <system. webServer> de su web.config. Al iniciar el panel de administración del IIS, seleccionar páginas de error.


 
En el panel acciones, haga clic en agregar, en el cuadro de diálogo agregar página de error personalizada, en código de estado, escriba el número del código de estado HTTP para el que desea crear un mensaje de error personalizado y elegir el método que desea asignar para cuando se genere el error, ya sea mostrar una página con el error genérico en .HTML, redireccionar a una URL.
 

 
Para la configuración en .NET
 

Mensajes de error e inhabilitación de depuración y rastreo

Debe unificar el manejo de todo tipo de errores y excepciones en su aplicación agregando el elemento <httpErrors> en la sección <system.webServer> de su archivo web.config.

Deshabilitar la depuración en su aplicación incluyendo este código en la sección <system.web>:
 

<system.web>
    <compilation debug="false"/>
</system.web>

 
Deshabilitar el rastreo en su aplicación incluyendo este código en la sección <microsoft.web.services3> de su archivo web.config:
 

<microsoft.web.services3>
    <diagnostics>
        <trace enabled="false"/>
    </diagnostics>
</microsoft.web.services3>

 

Eliminar el acceso al panel de administración

Prohibir el acceso a la interfaz de administración. Puede configurar esto agregando la clave CMSDisableAdministrationInterface en la sección <appSettings> del archivo web.config:
 

<add key="CMSDisableAdministrationInterface" value="true"/>

 

Cross Site Request Forgery (CSRF/XSRF)

Un atacante puede crear un enlace para una determinada acción y enviarlo al usuario. Luego, el usuario hace clic en el enlace y la acción se realiza sin que el usuario se dé cuenta. Esto se llama falsificación de solicitud de sitios cruzados.

Si ViewState está habilitado, no puede enviar solicitudes POST alteradas a una aplicación ASP.NET porque la validación de ViewState falla. Por lo que se recomienda mantener activado el ViewState.

Kentico también proporciona un mecanismo de token de seguridad por defecto para protección adicional contra solicitudes POST falsificadas:

• Cada vez que un usuario inicia una nueva sesión, se guarda una cookie de sesión en el navegador. La cookie almacena un token generado aleatoriamente.
• Cuando el usuario carga una página que contiene un formulario HTML, Kentico agrega automáticamente un campo oculto a los datos del formulario, que contiene un valor cifrado que coincide con el token del usuario.
• Después de enviar los datos del formulario a través de POST, el sistema valida el valor del campo oculto contra el token del usuario.
• Si un atacante intenta falsificar un formulario, no puede generar un valor válido para el campo de token oculto. Si los tokens no coinciden cuando se envía el formulario, el sistema genera un error y el ataque se bloquea.

Se debe especificar una clave correspondiente al usuario actual a través de la propiedad de página ViewStateUserKey. El valor recomendado es el ID de sesión de un usuario. Todas las páginas de Kentico deben heredar de AbstractCMSPage, que establece el ViewStateUserKey en un valor único para cada usuario y, por lo tanto, evita ataques con un clic.
 

<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1" decryption="Auto" compatibilityMode="Framework20SP1" />
<pages buffer="true" enableSessionState="true" enableViewState="true" enableViewStateMac="true" viewStateEncryptionMode="Auto">

 
Esto significa que el machineKey se genera automáticamente y se valida ViewState, incluida la codificación de ViewState basada en machineKeys. Si un control lo solicita, ViewState se cifra con SHA1.
 

Evitar automatización de peticiones

Haciendo uso de captchas, captcha midiendo el tiempo para identificar si se trata de un usuario o una máquina. Proteger su sitio web de robots de spam automatizados. Puede proteger todos los formularios donde los usuarios ingresan datos, al solicitarles que escriban un código de seguridad llamado captcha.
 
El tipo CAPTCHA predeterminado es Simple. Para cambiar el tipo predeterminado:

• Abre la aplicación de configuración.
• Vaya a la categoría Seguridad y membresía -> Configuración de protección.
• En la configuración de captcha, seleccione un Control para usar.
• Guarda la configuración.

 
Uso de ReCAPTCHA es un servicio en línea que permite que su aplicación separe humanos y computadoras.

• Debe registrar su sitio aquí para usar la API ReCAPTCHA y obtener un par de claves API.
• ​Seleccione el tipo de recaptcha.
• Complete todos los detalles requeridos, incluido el dominio donde se ejecuta su sitio.
• Copie la clave del sitio y la clave secreta.

 
Luego, ingrese las claves API recaptcha de su sitio en Kentico:

• Abre la aplicación de configuración.
• Vaya a la categoría Seguridad y membresía -> Configuración de protección.
• En la configuración de captcha, pegue la clave del sitio y la clave secreta en la clave de API pública recaptcha y la configuración de clave de API privada recaptcha respectivamente.

 
Con las claves API ingresadas en el sistema, puede crear campos de verificación en tipos de página, formularios o tablas personalizadas utilizando el control de formulario recaptcha importado.
 

Evitar el Autocompletar

Autocompletar es una función que recuerda los nombres de usuario enviados en los formularios de inicio de sesión y también todas las palabras enviadas a través de cualquier formulario en el sistema.

La funcionalidad de autocompletar se puede deshabilitar para la entrada de nombre de usuario en formularios de inicio de sesión utilizando el atributo HTML de autocompletar:
 

<input name="Login1$UserName" class="LogonTextBox" id="Login1_UserName" type="text" maxlength="100" autocomplete="Off" />

 
Para deshabilitar el autocompletado en los formularios de inicio de sesión:

• Abre la aplicación de configuración.
• Seleccione el elemento de árbol.
• Configuración de seguridad y membresía -> protección.
• Desactive la casilla de verificación de autocompletar.

 

Autenticación de solicitudes REST

Toda solicitud dirigida al servicio REST Kentico debe ser autenticada. De lo contrario, el servicio responde con un código de estado HTTP 403 prohibido.

Debe especificar el nombre de usuario y la contraseña a través de la línea de Autorización en el encabezado HTTP de cada solicitud REST. La línea de encabezado consta de:

• El tipo de autenticación (Básico)
• El nombre de usuario y la contraseña conectados por dos puntos (nombre de usuario: contraseña), codificados utilizando el algoritmo Base64.

Por ejemplo, la siguiente línea de encabezado usa RestClient: MyPassword como credenciales de autenticación:

Authorization: Basic UmVzdENsaWVudDpNeVBhc3N3b3Jk

Las credenciales deben pertenecer a un usuario estándar creado en Kentico. Si su sitio web utiliza la autenticación de Windows Active Directory, debe crear manualmente un usuario que no sea de AD para fines de autenticación REST, con las propiedades de usuario externo. Una vez autenticado, el sistema permite que la solicitud REST realice operaciones dependiendo del nivel de privilegio y los permisos del usuario especificado.
 

Codificación de salida de macros

La codificación de macros es una protección esencial contra XSS. Debe codificar las macros de salida correctamente, a menos que desee mostrar algún código HTML utilizando la macro particular. Hay varios métodos para codificar macros en Kentico:
 

• {% UrlEncode (CurrentUser.FullName)|(user)daniel.llorenzo|(hash)d3f4c1761f5e52262ef08cc6f4d45f3f5a9193d312ceed249df0e6dd6fe124ad%}: la macro se codifica en la URL de la consulta.
• {% HTMLEncode (CurrentUser.FullName)|(user)daniel.llorenzo|(hash)22c1f9aa48a044e4aa74ffeaabefe7165edbf7064c70dc307d9ac1a7a2dccbb9%}: la macro es una parte del texto de salida de página estándar y el texto entre etiquetas HTML.
• {% JSEscape (CurrentUser.FullName)|(user)daniel.llorenzo|(hash)50faec03f0b0a7c83903a547a6a3dcd7c175a4bacb7ac62335e5604a8c3693b3%}: la macro es parte del código JS.

 

Solicitar validación

La validación de solicitudes es un mecanismo que garantiza que la aplicación no procese solicitudes potencialmente peligrosas (posibles ataques XSS). En Kentico, la validación de la solicitud está deshabilitada de forma predeterminada, porque algunas partes del sistema (por ejemplo, el editor WYSIWYG) envían dichas solicitudes, lo que sería sospechoso para el validador. Sin embargo, puede cambiar esta configuración individualmente y habilitar la validación de solicitud solo para las páginas activas seleccionadas en la directiva @Page:
 

<@ Page validateRequest="false" %>

Evitar XSS en Kentico

Kentico proporciona los siguientes métodos para evitar ataques XSS:

• HTMLHelper.HTMLEncode(): Codifica etiquetas HTML, reemplaza los caracteres <y> con sus entidades HTML.
• QueryHelper.GetText(): Obtiene una cadena codificada en HTML de la cadena de consulta.
• ScriptHelper.GetString(): Reemplaza caracteres especiales como apóstrofes (alt + 39).
• Mantenga correctamente el tipo, utilizando, por ejemplo, QueryHelper.GetInteger().
• Use la función de transformación HTMLEncode().

 

Evitar inyección SQL

La inyección SQL es una vulnerabilidad de aplicación web bien conocida. El objetivo del atacante es ejecutar su propio código SQL en la base de datos de la víctima a través de una aplicación web. El ataque es similar a XSS. El atacante envía una cadena a la aplicación web a través de un formulario o parámetro de URL.
 
Kentico proporciona varias formas de protección contra la inyección SQL
 

DataQuery

La mejor manera de evitar la inyección de SQL es utilizar los métodos predeterminados del proveedor de la API de Kentico al cargar datos (ObjectQuery / DataQuery). El aspecto clave de seguridad de DataQuery está en el procesamiento de consultas controladas por parámetros.

Para crear condiciones WHERE, recomendamos utilizar métodos Where específicos para el propósito dado, tales como:

• WhereContains
• ​WhereNull
• WhereEquals
• WhereStartsWith

 

Consultar objetos

Si necesita ejecutar consultas manualmente, use las clases de objeto de consulta apropiadas del espacio de nombres Kentico CMS.DataEngine para construir partes de la consulta:

• WhereCondition
• ​Columns
• OrderBy

Parámetros SQL

Para las condiciones WHERE en los tipos de consulta INSERT, UPDATE y DELETE y los procedimientos almacenados, maneje los parámetros a través de objetos QueryDataParameters.
 

using CMS.DataEngine;
QueryDataParameters parameters = new QueryDataParameters();
parameters.Add("@param", param);

 
El servidor SQL reemplaza @param con su valor. El valor se trata como un literal, lo que significa que incluso si su valor contiene un fragmento de código SQL, el servidor SQL no ejecuta el código.
 

Escapando apóstrofe

La última técnica de protección es reemplazar manualmente el carácter peligroso del apóstrofe con una secuencia de escape de dos apóstrofes. En el código, a menudo construye condiciones WHERE para consultas SELECT. Cuando una parte de la condición es una cadena obtenida dinámicamente (p. Ej., De la base de datos, entrada de un usuario, etc.), debe encerrarla con apóstrofos y reemplazarla.
 
Puede usar dos opciones diferentes:

Para escapar de valores en patrones de consulta iguales, use el método.
 
SqlHelper.EscapeQuotes:

string text = txtAvatarname.Text;
string where = "AvatarName = N'" + SqlHelper.EscapeQuotes(text) + "'";

Para escapar de los valores en los patrones de consulta LIKE, use los métodos SqlHelper.EscapeQuotes y SqlHelper.EscapeLikeValue:

string text = txtAvatarname.Text;
string where = "AvatarName LIKE N'%" + SqlHelper.EscapeLikeText(SqlHelper.EscapeQuotes(text)) + "%'";

El método Sqlhelper.EscapeQuotes asegura que se escapen todos los apóstrofes para evitar ataques de inyección SQL. El segundo método SqlHelper.EscapeLikeText escapa a los comodines utilizados en la sintaxis LIKE de SQL: corchetes, porcentajes y símbolos de subrayado.
 
Consejos para evitar Inyecciones de código

• No use valores de cadena de consulta si no es necesario. En su lugar, use los valores de contexto Kentico.
• Si tiene que usar valores de cadena de consulta, use GUID en lugar de ID o nombres.
• Parámetros de cadena de consulta seguros con validación de código hash.
• Nunca cargue los controles dinámicamente cuando su ruta se toma de una fuente externa.
• Nunca use ProcessStartInfo y otras clases que ejecutan comandos o ejecutan código .NET.

 

Validación hash personalizada

Recomendamos usar funciones de hash al desarrollar cuadros de diálogo personalizados. Los siguientes métodos están disponibles en la API de Kentico:
Cálculo de hash:

QueryHelper.BuildQueryWithHash: Construye la cadena de consulta completa con cualquier número de parámetros, calcula automáticamente y agrega un parámetro hash (con todos los parámetros como entrada).

using CMS.Helpers;
// Sample URL parameter values
string urlParamValue1 = "value1";
string urlParamValue2 = "value2";
// Sample base URL
string url = "base";
// Creates a query string containing the sample parameters and the hash
string queryString = QueryHelper.BuildQueryWithHash("parameter1", urlParamValue1, "parameter2", urlParamValue2);
// Adds the query string parameters to the URL, including the hash
url += queryString;

ValidationHelper.GetHashString: Crea un hash SHA2 de un valor especificado. Se puede usar para crear valores hash para cualquier valor, no solo cadenas de consulta. El parámetro opcional HashSettings le permite especificar si el hash es específico del usuario y también agregar una sal personalizada.

using CMS.Helpers;
// Sample string value
string customValue = "value";
// Creates a hash for the custom value
string hash = ValidationHelper.GetHashString(urlParameterValue);

Validación de hash:

• QueryHelper.ValidateHash: Funciona directamente con la cadena de consulta y puede excluir parámetros individuales de la validación hash. 
• ​ValidationHelper.ValidateHash: Método de validación hash general, se puede utilizar para firmas de macros.

 

Registrar los eventos

El registro de eventos almacena información sobre todos los eventos que ocurren en el sistema. Es útil ver la información registrada si se produce un comportamiento no deseado en el sistema y desea averiguar dónde se origina el problema u obtener detalles adicionales.
 

 
Se pueden personalizar los eventos y crear notificaciones automáticas por correo electrónico siempre que se produzcan errores en la aplicación.

• Abre la aplicación de configuración.
• Seleccione la categoría del sistema.
• Ingrese las direcciones de correo electrónico de destino para las notificaciones en la configuración de la dirección de correo electrónico de notificación de error.
• Use punto y coma para separar varias direcciones.
• Escriba una dirección del remitente en la configuración de la dirección de correo electrónico sin respuesta.
• Los correos electrónicos de notificación utilizan la dirección del remitente en su campo De.