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: 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?

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

Cuando se trata de comparar objetos, los desarrolladores normalmente quieren comparar propiedades de objetos. No obstante, llamar a equals() en una clase (o una superclase/interfaz) que no implemente explícitamente equals() resulta en una llamada al método equals() heredado de java.lang.Object. En lugar de comparar campos de miembros de objetos u otras propiedades, Object.equals() compara dos instancias de objetos para ver si son las mismas. Aunque estos son usos legítimos de Object.equals(), a menudo es indicativo de que el código contiene errores.

Ejemplo 1:

public class AccountGroup
{
	private int gid;

	public int getGid()
	{
		return gid;
	}

	public void setGid(int newGid)
	{
		gid = newGid;
	}
}
...
public class CompareGroup
{
	public boolean compareGroups(AccountGroup group1, AccountGroup group2)
	{
		return group1.equals(group2);   //equals() is not implemented in AccountGroup
	}
}

Java Language Specification indica que es recomendable que un método finalize() llame a super.finalize() [1].

Ejemplo 1: el siguiente método omite la llamada a super.finalize().

protected void finalize() {
  discardNative();
}

Corrección del código: se producen problemas de firma incorrecta del método serializable cuando una clase serializable crea una función de serialización o deserialización pero no sigue las firmas correctas:

  private void writeObject(java.io.ObjectOutputStream out) throws IOException;
  private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;
  private void readObjectNoData() throws ObjectStreamException;

Una desviación de las firmas del método que requiere la serialización puede provocar que nunca se llame al método durante la serialización o deserialización. Esto supondría una serialización o deserialización incompleta o podría permitir que un código que no es de confianza obtenga acceso a los objetos.
En el caso de que se produzcan excepciones no arrojadas, puede significar que la serialización o deserialización está fallando y bloqueando la aplicación o que podría incluso fallar discretamente. En tal caso, los objetos se crearían correctamente solo en parte y se producirían errores muy difíciles de depurar. El autor de la llamada deberá filtrar estas excepciones de manera que la serialización o deserialización incorrectas puedan tratarse correctamente sin la presencia de bloqueos o de objetos creados parcialmente.

Enviar una HttpServletRequest, redirigir una HttpServletResponse o vaciar el flujo de salida del servlet provoca la confirmación del flujo asociado. Todo restablecimiento de búfer o confirmación de flujo, como los vaciados o los redireccionamientos adicionales, provocarán una IllegalStateExceptions.

Además, los servlets de Java permiten que los datos se escriban en el flujo de respuesta empleando ServletOutputStream o PrintWriter, pero no ambos. Llamar getWriter() después de haber llamado getOutputStream(), o viceversa, también provocará una IllegalStateException.



En tiempo de ejecución, una IllegalStateException impide que el controlador de respuesta se ejecute hasta la finalización, entregando la respuesta de forma eficaz. Esto puede causar inestabilidad en el servidor, señal de que un servlet se ha implementado incorrectamente.

Ejemplo 1: el código siguiente redirige la respuesta del servlet después de que su búfer de flujo de salida se haya vaciado.

public class RedirectServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        OutputStream out = res.getOutputStream();
        ...
        // flushes, and thereby commits, the output stream
        out.flush();
        out.close();        // redirecting the response causes an IllegalStateException
        res.sendRedirect("http://www.acme.com");
    }
}

Ejemplo 2: por otra parte, el código siguiente intenta escribir en el búfer de PrintWriter y vaciarlo después de que la solicitud se haya enviado.

public class FlushServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        // forwards the request, implicitly committing the stream
        getServletConfig().getServletContext().getRequestDispatcher("/jsp/boom.jsp").forward(req, res);
        ...

        // IllegalStateException; cannot redirect after forwarding
        res.sendRedirect("http://www.acme.com/jsp/boomboom.jsp");

        PrintWriter out = res.getWriter();

        // writing to an already-committed stream will not cause an exception,
        // but will not apply these changes to the final output, either
        out.print("Writing here does nothing");

        // IllegalStateException; cannot flush a response's buffer after forwarding the request
        out.flush();
        out.close();
    }
}

En la mayoría de los casos, la configuración del encabezado Content-Length de una solicitud indica que el desarrollador está interesado en
comunicar la longitud de los datos POST enviados al servidor. No obstante, este encabezado debe ser 0 o un
número entero positivo.

Ejemplo 1: el siguiente código establecerá un encabezado Content-Length incorrecto.

  URL url = new URL("http://www.example.com");
  HttpURLConnection huc = (HttpURLConnection)url.openConnection();
  huc.setRequestProperty("Content-Length", "-1000");

En la mayoría de los casos, una llamada a toString() en una matriz indica que un desarrollador está interesado en devolver el contenido de la matriz como cadena. Sin embargo, una llamada directa para toString() en una matriz devolverá un valor de cadena que contiene el tipo de matriz y el código hash en memoria.
Ejemplo 1: el siguiente código proporcionará como salida [Ljava.lang.String;@1232121.

String[] strList = new String[5];
...
System.out.println(strList);