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 acuerdo con las directivas de Apple, la aplicación siempre debe explicar a los usuarios por qué se requieren sus huellas digitales. En caso contrario, puede confundirse al usuario o incluso hacer que la aplicación se rechace en AppStore.

Ejemplo 1: el siguiente código usa Touch ID para autenticar al usuario, pero no proporciona un motivo localizado que explique por qué se requiere la autenticación:

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

Incluso aunque Castor cree un bloqueo en un objeto, eso no impide que otros subprocesos lean o escriban en él. Las consultas de solo lectura son también unas siete veces más rápidas en comparación con el modo compartido predeterminado.

Ejemplo 1: el ejemplo siguiente especifica el modo de consulta como SHARED, que permite tener acceso de lectura y escritura.

results = query.execute(Database.SHARED);

De forma predeterminada, Castor ejecuta consultas en modo compartido. Como el modo compartido permite acceso de lectura y escritura, no está claro para qué tipo de operación está destinada la consulta. Si el objeto se va a usar en un contexto de solo lectura, el acceso compartido agrega una sobrecarga de rendimiento innecesaria.

Ejemplo 1: el ejemplo siguiente no especifica un modo de consulta.

results = query.execute();    //missing query mode

En algún momento de la carrera profesional del desarrollador de .NET, surge un problema para parece tan misterioso, impenetrable e inmune a la depuración que no queda otra opción que culpar al recopilador de elementos no utilizados. Sobre todo, cuando el error está relacionado con el tiempo y el estado, existe un indicio de prueba empírica que apoya esta teoría: la inserción de una llamada a GC.Collect() a menudo parece lograr que el problema desaparezca.

En casi todos los casos que hemos visto, la llamada a GC.Collect() es el método incorrecto. De hecho, llamar a GC.Collect() puede provocar problemas de rendimiento si se realiza con demasiada frecuencia.

En algún momento de la vida profesional de todos los desarrolladores de Java, surge un problema que parece tan misterioso, impenetrable e inmune a la depuración que parece que no hay otra alternativa que culpar al recopilador de elementos no utilizados. Sobre todo, cuando el error está relacionado con el tiempo y el estado, existe un indicio de prueba empírica que apoya esta teoría: la inserción de una llamada a System.gc() a menudo parece lograr que el problema desaparezca.

En casi todos los casos que hemos visto, la llamada a System.gc() es el método incorrecto. De hecho, llamar a System.gc() puede provocar problemas de rendimiento si se realiza con demasiada frecuencia.