Reino: API Abuse

Uma API é um contrato entre quem chama e o que se chama. As formas mais comuns de abuso de API ocorrem quando o responsável pela chamada não respeita sua parte do contrato. Por exemplo, se um programa não chama chdir() após chamar chroot(), ele viola o contrato que especifica como alterar o diretório raiz ativo de forma segura. Outro bom exemplo de abuso de biblioteca é esperar que o elemento chamado retorne informações confiáveis de DNS ao responsável pela chamada. Nesse caso, o responsável pela chamada abusa a API do elemento chamado ao fazer certas suposições sobre seu comportamento (isto é, que o valor de retorno pode ser usado para fins de autenticação). A outra parte também pode violar o contrato entre quem chama e o que se chama. Por exemplo, se um programador definir SecureRandom como subclasse e retornar um valor não aleatório, o contrato será violado.

Struts 2 Bad Practices: Session Map Tampering

Abstract
Uma Ação do Struts 2.x implementa uma classe que permite a um invasor modificar a lógica de negócios do aplicativo associando dados arbitrários a objetos de sessão, de aplicativo ou de solicitação no lado do servidor
Explanation
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.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 20
[2] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[3] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-2 Application Partitioning (P1), SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-2 Separation of System and User Functionality, SI-10 Information Input Validation
[10] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[13] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[14] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[15] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[16] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[17] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40)
desc.structural.java.struts2_bad_practices_session_map_tampering