Solo se utilizan API destinadas a fines de depuración.

De forma predeterminada, los flujos de tareas en una aplicación Fusion no son directamente accesibles desde una solicitud GET: cada vez que una URL intenta invocar el flujo de tareas, recibe un código de estado HTTP 403. Sin embargo, confiar en una configuración implícita siempre carece de claridad y puede conducir a comportamientos no deseados si la configuración predeterminada cambia de forma inesperada.

Ejemplo 1: El siguiente fragmento de un archivo de definición de flujo de tarea muestra un ejemplo de flujo de tarea configurado con el ajuste implícito predeterminado url-invoke-disallowed.

...
    <task-flow-definition id="password">
        <default-activity>PasswordPrompt</default-activity>
        <view id="PasswordPrompt">
            <page>/PasswordPrompt.jsff</page>
        </view>
        <use-page-fragments/>
    </task-flow-definition>
...

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"/>
...

El almacenamiento de claves de cifrado en campos de clase estáticos permite que estas se puedan obtener con facilidad por parte de entidades con acceso a la memoria de procesamiento (por ejemplo, un dispositivo con acceso root) o a los volcados de memoria de procesamiento (por ejemplo, los volcados de memoria).

Un procedimiento habitual de desarrollo consiste en añadir un código de "puerta trasera" diseñado específicamente para fines de depuración o pruebas que no se vaya a enviar o implementar con la aplicación. Cuando este tipo de código de depuración se deja accidentalmente en la aplicación, este se abre en modos de interacción no previstos. Estos puntos de entrada de "puerta trasera" conllevan riesgos de seguridad porque no se tienen en cuenta durante las fases de diseño y pruebas, y no se incluyen en las condiciones de funcionamiento previstas de la aplicación.

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?

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();
...

Las acciones del controlador de ASP.NET MVC que modifican datos escribiendo, actualizando o eliminando podrían beneficiarse de estar limitado a aceptar uno de los siguientes verbos HTTP: Post, Put, Patch o Delete. Esto aumenta la dificultad de forgery de solicitudes entre sitios, ya que el clic accidental de vínculos no hará que la acción se ejecute.

La siguiente acción del controlador acepta de manera predeterminada cualquier verbo y puede ser susceptible de falsificación de solicitud entre sitios:

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

El uso de una clase de modelo que tiene propiedades requeridas (marcadas con el atributo [Required]) y propiedades opcionales (no marcadas con el atributo [Required]) pueden dar lugar a problemas si un usuario malintencionado comunica una solicitud que contiene más datos de los esperados.

El marco ASP.NET MVC intentará enlazar parámetros de solicitud en las propiedades del modelo.

El hecho de tener requisitos mixtos sin comunicar explícitamente qué parámetros se van a enlazar con modelos puede indicar que hay propiedades de modelos para el uso interno, pero pueden estar controlados por un usuario malintencionado.

El siguiente código define una posible clase de modelos que tiene propiedades con [Required] y propiedades sin [Required]:

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

Si algún parámetro opcional puede cambiar el comportamiento de una aplicación, un usuario malintencionado podría cambiar ese comportamiento comunicando un parámetro opcional en una solicitud.

El uso de una clase de modelos con propiedades requeridas que no admiten valores NULL (marcadas con el atributo [Required]) pueden dar lugar a problemas si un usuario malintencionado comunica una solicitud que contiene menos datos de los esperados.

El marco ASP.NET MVC intentará enlazar parámetros de solicitud en las propiedades del modelo.

Si un modelo tiene un parámetro requerido que no admite valores NULL y un usuario malintencionado no comunica ese parámetro requerido en una solicitud, es decir, el usuario malintencionado usa un ataque con cantidad reducida de operaciones POST, la propiedad tendrá el valor predeterminado (normalmente cero), que cumplirá con el atributo de validación [Required]. Esto podría producir un comportamiento inesperado de la aplicación.

El código siguiente define una posible clase de modelos que tiene una enumeración requerida que no admite valores NULL:

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

Si un clase de modelos tiene una propiedad requerida y el tipo de un miembro opcional de una clase de modelos principal, puede ser susceptible a ataques con cantidad reducida de operaciones POST si un usuario malintencionado comunica una solicitud que contiene menos de los que se esperan.

El marco ASP.NET MVC intentará enlazar parámetros de solicitud en las propiedades del modelo, incluidos los submodelos.

Si un submodelo es opcional, es decir, el modelo principal tiene una propiedad sin el atributo [Required], y si un usuario malintencionado no comunica ese submodelo, la propiedad principal tendrá un valor null y los campos requeridos del modelo secundario no estarán confirmados por la validación del modelo. Esta es una forma de ataque con cantidad reducida de operaciones POST.

Tenga en cuenta las siguientes definiciones de clases de modelos:

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

Si un usuario malintencionado no comunica un valor para la propiedad ParentModel.Child, la propiedad ChildModel.RequiredProperty tendrá un [Required] no confirmado. Esto puede producir resultados no esperados y no deseados.

De forma predeterminada, los volúmenes de EBS no están cifrados.
Ejemplo 1: La siguiente plantilla de ejemplo expone los datos a posible robo y acceso no autorizados.

	Resources:
  	  EBSVOLExample:
    	Type: AWS::EC2::Volume
    	Properties:
      	  Encrypted: false
	

De forma predeterminada, las instancias de RDS de Amazon no están cifradas. Esto expone los datos a posible robo y acceso no autorizados.

De forma predeterminada, los clústeres de Amazon Redshift no están cifrados. Esto expone los datos al acceso no autorizado y posible robo.

Se crea un contenedor de Amazon S3 sin cifrado del lado del servidor. El cifrado mitiga las vulneraciones de datos al hacer que los datos sean ilegibles para cualquier persona sin las credenciales adecuadas. El cifrado en reposo puede ayudar a satisfacer algunos requisitos de cumplimiento industriales y gubernamentales, como RGPD, HIPAA y PCI.

Los métodos de AWS API Gateway que son de acceso público pueden exponer a la organización a ataques.

Ejemplo 1: La siguiente plantilla de ejemplo define los métodos de AWS API Gateway de acceso público.

{
    "AWSTemplateFormatVersion": "2010-09-09",
    "Resources": {
        "MyMethod0": {
            "Type": "AWS::ApiGateway::Method",
            "Properties": {
                "RestApiId": "MyAPIID",
                "ResourceId": "MyResourceID",
                "HttpMethod": "GET",
                "AuthorizationType": "NONE"
            }
        },
        "MyMethod1": {
            "Type": "AWS::ApiGateway::Method",
            "Properties": {
                "RestApiId": "MyAPIID",
                "ResourceId": "MyResourceID",
                "HttpMethod": "POST",
                "AuthorizationType": "NONE",
                "ApiKeyRequired": false
            }
        }
    }
}

Una configuración comodín para los principales lambda infringe el principio de privilegios mínimos y permite que un atacante invoque el lambda desde cualquier cuenta.

Ejemplo 1: La siguiente plantilla de ejemplo define un principal lambda comodín.

{
    "Resources": {
        "LambdaPerm": {
            "Type": "AWS::Lambda::Permission",
            "Properties": {
            "SourceAccount": "AWS::AccountId",
            "SourceArn": "bucket.Arn",
            "FunctionName": "function.Arn",
            "Action": "lambda:InvokeFunction",
            "Principal": "*"
            }
        }
    },
    "AWSTemplateFormatVersion": "2010-09-09",
    "Description": "Lambda Permission"
}

De forma predeterminada, las instancias de Amazon DocumentDB no están cifradas. Esto expone los datos al acceso no autorizado y posible robo.

Ejemplo 1: El siguiente ejemplo muestra una plantilla que define una Amazon DocumentDB con el cifrado deshabilitado.

"Resources": {
    "DocDBDefault": {
        "Type": "AWS::DocDB::DBCluster",
        "Properties": {
            "MasterUsername": "name",
            "MasterUserPassword": "password"
        }
    }