Aunque la especificación de lenguaje Java permite que un método finalize() de objeto sea llamado desde fuera del finalizador, se trata de una mala idea. Por ejemplo, llamar finalize() explícitamente indica que finalize() se llamará más de una vez: la primera vez será la llamada explícita y la última vez será la llamada que se hace después de que el objeto sea recolectado.

Ejemplo 1: el fragmento de código siguiente llama finalize() explícitamente:

// time to clean up
widget.finalize();

El atributo dangerouslySetInnerHTML en React reemplaza el uso de innerHTML en el DOM del navegador, pero se ha cambiado el nombre de la API para transmitir los peligros potenciales de su uso. En general, configurar HTML desde el código es arriesgado porque es fácil exponer inadvertidamente a los usuarios a un ataque de Cross-Site Scripting (XSS).
Ejemplo 1: El siguiente código establece HTML desde el código al atributo dangerouslySetInnerHTML:

      function MyComponent(data) {
        return (
          <div
            dangerouslySetInnerHTML={{__html: data.innerHTML}}
          />
        );
      }
    

Las operaciones de escritura de Direct Open SQL (Insertar/Actualizar/Modificar/Eliminar) son, en general, poco recomendables y deben evitarse. porque minan la integridad y seguridad del sistema.



Además, las operaciones de escritura de Direct Open SQL son propensas a errores y pueden provocar comportamientos inesperados del sistema. Algunos de los problemas a los que se debe prestar atención en SAP son:

- SAP recomienda el uso de las técnicas "update bundling" (unión de actualizaciones) para asegurar la integridad de los datos dentro de una LUW (unidad lógica de trabajo) que tal vez abarque varias LUW de bases de datos. Las modificaciones directas en las entradas de tabla sin "update bundling" (unión de actualizaciones) pueden dejar la transacción SAP en un estado incoherente.

- Las operaciones de escritura de Direct Open SQL solo establecen los bloqueos de nivel de base de datos y omiten los bloqueos de la aplicación SAP. Esto puede dar lugar a interbloqueos y datos dañados.

- Las operaciones de escritura de Direct Open SQL omiten las comprobaciones de autorización SAP dentro del programa de aplicación.

- Cuando se usan mecanismos estándar para escribir entradas de tablas, comprobaciones de edición, pistas de auditoría, actualizaciones de dependientes (como cambiar documentos, por ejemplo) se ejecutan todas correctamente. Esto no sucede así cuando se utilizan operaciones de escritura Direct Open SQL.

En los derechos de un invocador, o paquete AUTHID CURRENT_USER, los identificadores se solucionan en primer lugar según el esquema del usuario actual. Esto puede provocar un comportamiento inesperado si el definidor del código no expresa explícitamente a qué esquema pertenece un identificador.

Ejemplo: el siguiente código comprueba si un usuario tiene permisos para realizar una acción mediante la búsqueda del usuario en una tabla de permisos. La mayoría de los usuarios solo tendrán acceso de lectura a SYS.PERMISSIONS y no podrá modificar los permisos definidos.

CREATE or REPLACE FUNCTION check_permissions(
  p_name IN VARCHAR2, p_action IN VARCHAR2)
  RETURN BOOLEAN
  AUTHID CURRENT_USER
IS
  r_count NUMBER;
  perm BOOLEAN := FALSE;
BEGIN
  SELECT count(*) INTO r_count FROM PERMISSIONS
    WHERE name = p_name AND action = p_action;
  IF r_count > 0 THEN
    perm := TRUE;
  END IF;
  RETURN perm;
END check_permissions

Si el usuario que llama la función check_permissions define una tabla PERMISSIONS en su esquema, la base de datos decidirá que el identificador haga referencia a la tabla local. El usuario podría tener acceso de escritura a la nueva tabla y podría modificarla para obtener los permisos que de otro modo no tendría.

Apache Struts 2.x incluía las nuevas interfaces de Aware para que los desarrolladores pudiesen introducir fácilmente en su código de Actions mapas con información de tiempo de ejecución importante. Estas interfaces incluyen: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware y org.apache.struts2.interceptor.RequestAware. Con el fin de incorporar cualquiera de estos mapas de datos en el código de Actions, los desarrolladores deben implementar el marco que se especifica en la interfaz (por ejemplo: setSession para la interfaz SessionAware):

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

Por otro lado, Struts 2.x enlaza automáticamente los datos de la solicitud del usuario con las propiedad de la acción a través de descriptores de acceso definidos en la acción. Dado que las interfaces de Aware requieren que se implemente el setter público definido en la interfaz de Aware, este setter se enlazará también de forma automática con cualquier parámetro de solicitud que sea coincidente con el nombre de la interfaz de Aware que pueda permitir a los usuarios malintencionados remotos modificar los valores del tiempo de ejecución a través de un parámetro proporcionado a una aplicación que implemente una interfaz afectada, como demuestran las interfaces SessionAware, RequestAware, ApplicationAware.

La siguiente URL permitirá a un usuario malintencionado sobrescribir el atributo de "roles" en el mapa de la sesión, lo que potencialmente puede permitirle convertirse en administrador.

http://server/VulnerableAction?session.roles=admin


Mientras que estas interfaces sólo requieren la implementación de los descriptores de acceso del setter, si el correspondiente getter también está implementado, los cambios en estas colecciones de mapas se almacenarán en la sesión en lugar de afectar únicamente a la solicitud actual.

Struts 2 introdujo una función denominada "invocación de método dinámico" que permite que una acción se exponga a otros métodos que no sean execute(). El carácter ! (bang) o el prefijo method: se pueden utilizar en la URL de la acción para invocar a cualquier método público de la acción si se ha habilitado la "invocación de método dinámico". Los desarrolladores que no conocen la existencia de esta función pueden exponer a los atacantes la lógica empresarial interna de forma involuntaria.

Por ejemplo, si la acción contiene un método público llamado getUserPassword() que no utiliza ningún argumento y no puede deshabilitar la función de "invocación de método dinámico", los usuarios malintencionados podrían aprovecharse de esta situación visitando la siguiente URL: http://server/app/recoverpassword!getPassword.action

Apache Struts 2.x incluía las nuevas interfaces de Aware para que los desarrolladores pudiesen introducir fácilmente en su código de Actions mapas con información de tiempo de ejecución importante. Estas interfaces incluyen: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware y org.apache.struts2.interceptor.RequestAware. Con el fin de incorporar cualquiera de estos mapas de datos en el código de Actions, los desarrolladores deben implementar el marco que se especifica en la interfaz (por ejemplo: setSession para la interfaz SessionAware):

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

Por otro lado, Struts 2.x enlaza automáticamente los datos de la solicitud del usuario con las propiedad de la acción a través de descriptores de acceso definidos en la acción. Dado que las interfaces de Aware requieren que se implemente el setter público definido en la interfaz de Aware, este setter se enlazará también de forma automática con cualquier parámetro de solicitud que sea coincidente con el nombre de la interfaz de Aware que pueda permitir a los usuarios malintencionados remotos modificar los valores del tiempo de ejecución a través de un parámetro proporcionado a una aplicación que implemente una interfaz afectada, como demuestran las interfaces SessionAware, RequestAware, ApplicationAware.

La siguiente URL permitirá a un usuario malintencionado sobrescribir el atributo de "roles" en el mapa de la sesión, lo que potencialmente puede permitirle convertirse en administrador.

http://server/VulnerableAction?session.roles=admin


Mientras que estas interfaces sólo requieren la implementación de los descriptores de acceso del setter, si el correspondiente getter también está implementado, los cambios en estas colecciones de mapas se almacenarán en la sesión en lugar de afectar únicamente a la solicitud actual.