Los valores de atributos de los componentes de Oracle ADF Faces solo se pueden establecer normalmente en el servidor. Sin embargo, diversos componentes permiten al desarrollador definir una lista de atributos que se puede establecer en el cliente. El atributo unsecure de estos componentes puede especificar una lista de este tipo.

El único atributo que puede aparecer actualmente dentro del atributo unsecure es disabled; este permite que el cliente defina los componentes que se habilitarán y aquellos que no. Nunca es recomendable dejar que el cliente controle los valores de los atributos que solo deben establecerse en el servidor.

Ejemplo 1: El siguiente código muestra un componente inputText que recopila información de contraseñas del usuario y utiliza el atributo unsecure.

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

Las cookies son un mecanismo exclusivo de HTTP según RFC 2109. No se debe pretender que funcionen con protocolos diferentes de HTTP, incluido file://. No está claro cuál debería ser su comportamiento, ni qué reglas se deben aplicar para compartimentar la seguridad. Por ejemplo, ¿los archivos HTML que se descargan en el disco local desde Internet deben compartir las mismas cookies que cualquier código HTML instalado localmente?

Las aplicaciones para Android se pueden configurar para producir archivos binarios de depuración. Estos binarios proporcionan mensajes de depuración detallados y no deben usarse en entornos de producción. El atributo debuggable de la etiqueta <application> define si los binarios compilados deben incluir información de depuración.

El uso de binarios de depuración hace que una aplicación proporcione al usuario tanta información sobre sí misma como sea posible. Los binarios de depuración están diseñados para usarse en un entorno de desarrollo o prueba y pueden suponer un riesgo de seguridad si se implementan en producción. Los atacantes pueden valerse de información adicional que obtengan del resultado de seguimiento para planear ataques contra el marco de trabajo, la base de datos o cualquier otro recurso que la aplicación utilice.

El middleware ASP.NET Core que no se agrega a la canalización de middleware en el orden correcto no funcionará según lo previsto, dejando la aplicación expuesta a una variedad de problemas de seguridad.

Ejemplo 1: El método UseCookiePolicy() agrega el middleware de política de cookies a la canalización de middleware, lo que permite políticas de cookies personalizadas. Cuando se especifica en el orden incorrecto, como se muestra, se ignorará cualquier política de cookies establecida por el programador.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

El middleware ASP.NET Core que no se agrega a la canalización de middleware en el orden correcto no funcionará según lo previsto, dejando la aplicación expuesta a una variedad de problemas de seguridad.

Ejemplo 1: El método UseHttpsRedirection() agrega middleware de redirección HTTPS a la canalización de middleware, lo que permite la redirección de solicitudes HTTP no seguras a una solicitud HTTPS segura. Cuando se especifica en el orden incorrecto, como se muestra, no se producirá una redirección HTTPS significativa antes de procesar la solicitud a través del middleware que se muestra antes de la redirección. Esto permitirá que la aplicación procese las solicitudes HTTP antes de redirigirlas a la conexión HTTPS segura.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

El middleware ASP.NET Core que no se agrega a la canalización de middleware en el orden correcto no funcionará según lo previsto, dejando la aplicación expuesta a una variedad de problemas de seguridad.

Ejemplo 1: El método UseHttpLogging() agrega middleware de registro HTTP a la canalización de middleware que permite que los componentes de middleware se registren. Cuando se especifica en el orden incorrecto, como se muestra, no se agrega ningún middleware a la canalización antes de que se registre la llamada a UseHttpLogging().

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

Ejemplo 2: El método UseWC3Logging() agrega el middleware de registro W3C a la canalización de middleware que permite que los componentes de middleware se registren. Cuando se especifica en el orden incorrecto, como se muestra, no se agrega ningún middleware a la canalización antes de que se registre la llamada a UseWC3Logging().

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

Configurar el modo de validación del certificado en None desactiva todo el proceso de validación de la certificación, lo que expone la aplicación a ataques de tipo "man-in-the-middle". Este modo no debe utilizarse en entornos de producción.

Las cookies se utilizan a menudo para almacenar información importante sobre los usuarios, como información personal, tokens de autenticación y un historial de su actividad. Si esta información se almacena en texto sin formato, cualquier persona con acceso a las máquinas utilizadas para interactuar con la aplicación tendrá acceso a la información almacenada en la cookie. Peor aún, si pueden modificar arbitrariamente los datos almacenados en las cookies, los atacantes también pueden falsificar la información proporcionada a la aplicación y potencialmente alterar su comportamiento en su beneficio.

En muchos casos, una aplicación puede validar la entrada de las cookies mediante programación de acuerdo con el contexto en el que se utiliza, pero el marco de validación ASP.NET ofrece una manera excelente de proteger el contenido de la cookie y de verificar que la cookie no se haya modificado inesperadamente. Sin este método, es difícil, y a menudo imposible, establecer con un alto nivel de confianza que todas las entradas están validadas.

Las aplicaciones ASP .NET se pueden configurar para producir binarios de depuración. Estos binarios proporcionan mensajes de depuración detallados y no deben usarse en entornos de producción. El atributo debug de la etiqueta <compilation> define si los binarios compilados deben incluir información de depuración.

El uso de binarios de depuración hace que una aplicación proporcione al usuario tanta información sobre sí misma como sea posible. Los binarios de depuración están diseñados para usarse en un entorno de desarrollo o prueba y pueden suponer un riesgo de seguridad si se implementan en producción. Los atacantes pueden valerse de información adicional que obtengan del resultado de seguimiento para planear ataques contra el marco de trabajo, la base de datos o cualquier otro recurso que la aplicación utilice.

Cuanto más tiempo permanece abierta una sesión, mayor es la ventana de oportunidad que tiene un atacante para comprometer las cuentas de usuario. Mientras una sesión permanece activa, un atacante puede forzar la contraseña de un usuario, descifrar su clave de cifrado inalámbrica o controlar una sesión desde un explorador abierto. Los tiempos de espera de autenticación más prolongados también pueden evitar que se libere la memoria y acabar en una denegación de servicio si se crea una cantidad suficientemente grande de sesiones.

Ejemplo 1: El siguiente ejemplo muestra ASP.NET MVC configurado con un tiempo de espera de autenticación de una hora.

...
<configuration>
  <system.web>
  <authentication>
    <forms
      timeout="60" />
  </authentication>
  </system.web>
</configuration>
...

Si no se especifica el atributo de tiempo de espera, el tiempo de espera de autenticación predeterminado es de 30 minutos.

Los programas se pueden configurar para validar certificados X.509 de una de estas tres formas. De forma predeterminada, los certificados se validan mediante su cadena de confianza con una entidad de certificación raíz de confianza. Esta configuración se conoce como ChainTrust y proporciona el máximo nivel de seguridad de que el certificado es válido. De forma predeterminada, todos los certificados se validan mediante ChainTrust.

Para hacer uso de un certificado que una entidad de certificación raíz de confianza no haya emitido, se puede configurar un programa para que confíe en certificados emitidos por sus pares estableciendo PeerTrust o PeerOrChainTrust. Estas configuraciones no deben usarse en entornos de producción porque reducen significativamente el nivel de seguridad otorgado por los certificados.

Las cookies se utilizan a menudo para almacenar información importante sobre los usuarios, como información personal, tokens de autenticación y un historial de su actividad. Si esta información se almacena en texto sin formato, cualquier persona con acceso a las máquinas utilizadas para interactuar con la aplicación tendrá acceso a la información almacenada en la cookie. Peor aún, si pueden modificar arbitrariamente los datos almacenados en las cookies, los atacantes también pueden falsificar la información proporcionada a la aplicación y potencialmente alterar su comportamiento en su beneficio.

En muchos casos, una aplicación puede validar la entrada de las cookies mediante programación de acuerdo con el contexto en el que se utiliza, pero el marco de validación ASP.NET ofrece una manera excelente de proteger el contenido de la cookie y de verificar que la cookie no se haya modificado inesperadamente. Sin este método, es difícil, y a menudo imposible, establecer con un alto nivel de confianza que todas las entradas están validadas.

Si el atributo cacheRolesInCookie del elemento configuration/system.web/authentication/forms enweb.config se establece entrue , las funciones de cada usuario se almacenan en caché en una cookie. Si esta información se almacena en texto sin formato, cualquier persona con acceso a las máquinas utilizadas para interactuar con la aplicación tendrá acceso a la información almacenada en la cookie. Peor aún, si pueden modificar arbitrariamente los datos almacenados en las cookies, los atacantes también pueden falsificar la información proporcionada a la aplicación y potencialmente alterar su comportamiento en su beneficio.

En muchos casos, una aplicación puede validar la entrada de las cookies mediante programación de acuerdo con el contexto en el que se utiliza, pero el marco de validación ASP.NET ofrece una manera excelente de verificar que la cookie no se haya modificado inesperadamente. Sin este método, es difícil, y a menudo imposible, establecer con un alto nivel de confianza que todas las entradas están validadas.

Los servicios web ASP.NET facilitan el desarrollo de clientes de servicios web al generar automáticamente documentación que describe cómo comunicarse con el servicio web.

Los servicios web que tienen habilitado el protocolo de documentación generan una página con formato HTML al recibir una solicitud del navegador.

Esta página con formato HTML describe la información siguiente:
1. Las operaciones admitidas
2. Los parámetros que cada operación acepta
3. El tipo de datos que se deben pasar en esos parámetros.

El protocolo de documentación también genera un archivo de lenguaje de descripción de servicios web (WSDL) con formato XML. Este archivo está diseñado para permitir que las aplicaciones comprendan cómo estructurar las solicitudes al servicio web. Esta información puede resultar muy útil para los desarrolladores, especialmente para los desarrolladores que crean clientes para servicios web públicos. Sin embargo, revelar información detallada sobre la funcionalidad de los servicios web privados aumenta el riesgo de que un atacante malintencionado utilice el servicio web indebidamente. El protocolo de documentación siempre describe todas las funciones y parámetros de un servicio web, incluso si solo un subconjunto de esas funciones está destinado a ser de acceso público.

Las aplicaciones ASP .NET deben configurarse para usar páginas de error personalizadas en lugar de la página predeterminada del marco de trabajo. La página de error predeterminada brinda información detallada sobre el error que se produjo y no debe utilizarse en entornos de producción. El atributo mode de la etiqueta <customErrors> define si se utilizan páginas de error personalizadas o predeterminadas.

Los atacantes pueden valerse de información adicional que obtengan de una página de error predeterminada para planear ataques contra el marco de trabajo, la base de datos o cualquier otro recurso que la aplicación utilice.

De forma predeterminada, ASP.NET valida internamente las firmas criptográficas antes de descifrar las cargas útiles, como las direcciones URL ViewState ,FormsAuth cookies y ScriptResource.axd y pasa esos valores a la aplicación para procesarlos posteriormente. Sin embargo, esta funcionalidad se puede modificar utilizando el parámetro aspnet:UseLegacyEncryption para deshabilitar la comprobación de la firma criptográfica antes de descifrar las cargas útiles. Esta alteración puede permitir que un cliente malintencionado descifre, falsifique o altere de otro modo los datos cifrados.

Ejemplo 1: en el siguiente ejemplo, aspnet:UseLegacyEncryption está definido como true.

...
  <appSettings>
    <add key="aspnet:UseLegacyEncryption" value="true" />
  </appSettings>
...

Las aplicaciones ASP.NET pueden almacenar parejas de nombre de usuario y contraseña en elementos <credentials> en el archivo web.config para una aplicación ASP.NET, que admite texto sin formato, formatos de contraseña MD5 y SHA1.

Las contraseñas almacenadas en texto sin formato o que utilizan un algoritmo de cifrado débil son accesibles para cualquier persona con acceso a los archivos de configuración de la aplicación. Esto puede incluir la máquina donde se alojan la aplicación o el repositorio de código fuente donde reside la aplicación.

Ejemplo 1: La siguiente entrada de web.config almacena incorrectamente sus contraseñas en texto sin formato.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET admite contraseñas de credenciales almacenadas en tres formatos, especificados por el atributo passwordFormat del elemento configuration/system.web/authentication/forms/credentials. Los posibles valores de este atributo son:

Clear- indica que la contraseña se almacena en texto sin formato (menos segura)
MD5- indica que el hash MD5 de la contraseña está almacenado
SHA1- indica que el hash SHA1 de la contraseña está almacenado (más seguro)

Si bien un hash MD5 es más seguro que el texto sin formato, los investigadores han encontrado ataques de fuerza bruta contra el algoritmo de hash MD5. En este momento, un hash SHA1 todavía proporciona una protección razonable contra tales ataques.

Las entradas no comprobadas son la causa principal de vulnerabilidades en aplicaciones ASP.NET. Las entradas no comprobadas pueden provocar gran cantidad de vulnerabilidades, como Cross-Site Scripting, Process Control y SQL Injection.

Para evitar tales ataques, utilice el marco de validación de ASP.NET para comprobar todas las entradas del programa antes de que la aplicación las procese.

Entre los ejemplos de uso del marco de trabajo de validación se incluye la comprobación para asegurarse de que:

- Los campos de números de teléfono contienen solo caracteres válidos de números de teléfono.
- Los valores booleanos son solo "T" o "F".
- Las cadenas de formato libre son de una longitud y composición razonables.

Si el atributo cacheRolesInCookie del elemento configuration/system.web/authentication/forms enweb.config se establece entrue , las funciones de cada usuario se almacenan en caché en una cookie. Si esta información se almacena en texto sin formato, cualquier persona con acceso a las máquinas utilizadas para interactuar con la aplicación tendrá acceso a la información almacenada en la cookie. Peor aún, si pueden modificar arbitrariamente los datos almacenados en las cookies, los atacantes también pueden falsificar la información proporcionada a la aplicación y potencialmente alterar su comportamiento en su beneficio.

En muchos casos, una aplicación puede validar la entrada de las cookies mediante programación de acuerdo con el contexto en el que se utiliza, pero el marco de validación ASP.NET ofrece una manera excelente de verificar que la cookie no se haya modificado inesperadamente. Sin este método, es difícil, y a menudo imposible, establecer con un alto nivel de confianza que todas las entradas están validadas.

La mayoría de las aplicaciones web utilizan un identificador de sesión para identificar de forma exclusiva a los usuarios, que normalmente se almacena en una cookie y se transmite de forma transparente entre el servidor y el explorador web.


Cuando el valor del atributo se establece en true o UseUri, la aplicación no utiliza cookies independientemente de si el explorador o el dispositivo las admite. Cuando el valor del atributo se establece en AutoDetect o UseDeviceProfile, las cookies no se utilizan, según la configuración del explorador o el dispositivo solicitante.

Las aplicaciones que no almacenan identificadores de sesión en cookies a veces los transmiten como un parámetro de solicitud HTTP o como parte de la dirección URL. La aceptación de identificadores de sesión especificados en las direcciones URL facilita que los atacantes realicen ataques de fijación de sesión.

La colocación de identificadores de sesión en las direcciones URL también puede aumentar las posibilidades de que se produzcan ataques de suplantación de sesión con éxito contra la aplicación. La suplantación de sesión ocurre cuando un atacante toma el control de la sesión activa o del identificador de sesión de una víctima. Es una práctica común que los servidores web, los servidores de aplicaciones y los servidores proxy web almacenen las direcciones URL solicitadas. Si se incluyen identificadores de sesión en las direcciones URL, también se registran. Aumentar el número de lugares en los que se ven y almacenan los identificadores de sesión aumenta las posibilidades de que un atacante los ponga en peligro.