Embora a especificação da linguagem Java permita que o método finalize() de um objeto seja chamado de fora do finalizador, fazer isso é normalmente uma má ideia. Por exemplo, chamar finalize() explicitamente significa que finalize() será chamado mais de uma vez: a primeira vez será a chamada explícita e a última vez será a chamada que é feita depois que o objeto é coletado como lixo.

Exemplo 1: O fragmento de código a seguir chama finalize() explicitamente:

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

O atributo dangerouslySetInnerHTML no React substitui o uso de innerHTML no DOM do navegador, mas a API foi renomeada para transmitir os possíveis perigos de usá-lo. Em geral, definir o HTML com base no código é arriscado porque é fácil expor inadvertidamente seus usuários a um ataque de script entre sites (XSS).
Exemplo 1: O seguinte código define o HTML com base no código para o atributo dangerouslySetInnerHTML:

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

Em geral, operações de gravação Open SQL diretas (Insert/Update/Modify/Delete) são uma prática imprópria e devem ser evitadas. Elas prejudicam a integridade e a segurança do sistema e não devem ser permitidas.



As operações de gravação Open SQL diretas também são propensas a erros e podem provocar o comportamento inesperado do sistema. Alguns dos problemas que devem ser observados no SAP incluem:

- A SAP recomenda o uso de técnicas de "agrupamento de atualizações" para garantir a integridade dos dados em uma LUW (unidade lógica de trabalho) SAP que pode propagar várias LUWs de banco de dados. Modificações diretas em entradas de tabelas sem o agrupamento de atualizações podem deixar a transação SAP em um estado inconsistente.

- Operações de gravação Open SQL diretas apenas definem bloqueios no nível do banco de dados e ignoram os bloqueios de aplicativos SAP. Isso pode resultar em deadlocks e dados corrompidos.

- Operações de gravação Open SQL diretas ignoram verificações de autorização SAP dentro do programa aplicativo.

- Quando mecanismos padrão são utilizados para gravar entradas de tabela, editar verificações e realizar trilhas de auditoria, todas as atualizações dependentes (como documentos de alteração, por exemplo) são realizadas corretamente. Este não é o caso quando operações de gravação Open SQL diretas são utilizadas.

Nos direitos de um chamador, ou no pacote AUTHID CURRENT_USER, os identificadores são primeiro resolvidos de acordo com o esquema atual do usuário. Isso pode causar um comportamento inesperado se o definidor do código não disser explicitamente a qual esquema um identificador pertence.

Exemplo: Este código verifica se o usuário tem permissões para executar uma ação ao buscar o usuário em uma tabela de permissões. A maioria dos usuários terá apenas o acesso de leitura a SYS.PERMISSIONS e não poderá modificar as permissões definidas.

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

Se o usuário que está chamando a função check_permissions definir uma tabela de PERMISSIONS no esquema dele, o banco de dados resolverá o identificador para consultar a tabela local. O usuário teria acesso de gravação à nova tabela e poderia modificá-la para obter permissões que não teria de outra maneira.

O Apache Struts 2.x inclui as novas interfaces Aware para permitir que desenvolvedores injetem mapas facilmente com informações de tempo de execução relevantes em seus códigos de Ações. Essas interfaces incluem: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware e org.apache.struts2.interceptor.RequestAware. Para que qualquer um desses mapas de dados seja injetado em seus códigos de Ações, os desenvolvedores precisam implementar o setter especificado na interface (por exemplo: setSession para a Interface 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 outro lado, o Struts 2.x associa automaticamente os dados de solicitações provenientes do usuário às propriedades da Ação por meio de assessores públicos definidos na Ação. Como as interfaces Aware exigem a implementação do setter público definido na interface Aware, esse setter também será automaticamente associado a qualquer parâmetro de solicitação que corresponder ao nome do setter da interface Aware, o que pode permitir que invasores remotos modifiquem valores de dados em tempo de execução através de um parâmetro trabalhado para um aplicativo que implementa uma interface afetada, conforme demonstrado pelas interfaces SessionAware, RequestAware e ApplicationAware.

A URL a seguir permitirá que um atacante substitua o atributo "roles" no mapa de sessão. Isso pode acabar permitindo que o invasor se torne um administrador.

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


Embora essas interfaces só exijam a implementação dos assessores setter, se o getter correspondente também for implementado, as alterações nessas coleções de mapas terão o escopo definido para a sessão, em vez de somente afetarem o escopo da solicitação atual.

O Struts 2 introduziu um recurso chamado “Invocação de método dinâmico", que permite que uma Ação exponha métodos diferentes de execute(). O caractere ! (exclamação) ou o prefixo method: pode ser usado na URL da Ação para invocar qualquer método público nessa Ação quando a “Invocação de método dinâmico" está habilitada. Os desenvolvedores que não estiverem cientes desse recurso poderão inadvertidamente expor a lógica de negócios interna aos invasores.

Como exemplo, se a Ação contiver um método público chamado getUserPassword(), que não usa argumentos e não consegue desabilitar o recurso "Invocação de Métodos Dinâmica", um invasor será capaz de tirar proveito disso visitando a seguinte URL: http://server/app/recoverpassword!getPassword.action

O Apache Struts 2.x inclui as novas interfaces Aware para permitir que desenvolvedores injetem mapas facilmente com informações de tempo de execução relevantes em seus códigos de Ações. Essas interfaces incluem: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware e org.apache.struts2.interceptor.RequestAware. Para que qualquer um desses mapas de dados seja injetado em seus códigos de Ações, os desenvolvedores precisam implementar o setter especificado na interface (por exemplo: setSession para a Interface 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 outro lado, o Struts 2.x associa automaticamente os dados de solicitações provenientes do usuário às propriedades da Ação por meio de assessores públicos definidos na Ação. Como as interfaces Aware exigem a implementação do setter público definido na interface Aware, esse setter também será automaticamente associado a qualquer parâmetro de solicitação que corresponder ao nome do setter da interface Aware, o que pode permitir que invasores remotos modifiquem valores de dados em tempo de execução através de um parâmetro trabalhado para um aplicativo que implementa uma interface afetada, conforme demonstrado pelas interfaces SessionAware, RequestAware e ApplicationAware.

A URL a seguir permitirá que um atacante substitua o atributo "roles" no mapa de sessão. Isso pode acabar permitindo que o invasor se torne um administrador.

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


Embora essas interfaces só exijam a implementação dos assessores setter, se o getter correspondente também for implementado, as alterações nessas coleções de mapas terão o escopo definido para a sessão, em vez de somente afetarem o escopo da solicitação atual.