Reino: API Abuse

Un API es un contrato entre un autor de llamada y un receptor de llamada. Las formas de abuso de API más comunes los produce el autor de llamada cuando no consigue atender su fin de este contrato. Por ejemplo, si un programa no consigue llamar chdir() después de llamar chroot(), se viola el contrato que especifica cómo cambiar el directorio de origen activo de una forma segura. Otro buen ejemplo de un abuso de manual es esperar que el receptor devuelva una información de DNS de confianza al autor de llamada. En este caso, el autor de llamada abusa el API del receptor haciendo determinadas suposiciones sobre su comportamiento (que el valor de retorno se puede usar con fines de autenticación). También se puede violar el contrato entre el autor de llamada y el receptor desde el otro lado. Por ejemplo, si un codificador envía SecureRandom y devuelve un valor no aleatorio, se viola el contrato.

Unchecked Return Value

Abstract

La omisión de un valor de devolución del método puede provocar que el programa pase por alto estados y condiciones inesperadas.

Explanation

No es infrecuente que los programadores malinterpreten Read() y los métodos relacionados que forman parte de muchas clases System.IO. La mayoría de errores y eventos inusuales de .NET provocan que se genere una excepción. (Esta es una de las ventajas que presenta .NET frente a otros lenguajes como "C:". Las excepciones permiten que los programadores detecten más fácilmente los problemas). Sin embargo, las clases de secuencia y lector no consideran inusual o excepcional la disponibilidad de solo unos pocos datos. Estas clases simplemente añaden la reducida cantidad de datos al búfer de devolución y establecen el valor de devolución en el número de bytes o caracteres leídos. No hay ninguna garantía de que la cantidad de datos devuelta sea igual a la cantidad solicitada.

Debido a este comportamiento, es importante que los programadores examinen el valor de devolución de Read() y otros métodos de E/S, y se aseguren de que reciben la cantidad de datos prevista.
Ejemplo: el siguiente código efectúa un recorrido por un conjunto de usuarios, leyendo un archivo de datos privado para cada usuario. El programador presupone que el tamaño de los archivos es siempre de 1 kilobyte y, por lo tanto, ignora el valor de devolución de Read(). Si un usuario malintencionado puede crear un archivo más pequeño, el programa reciclará el resto de los datos del usuario anterior y los administrará como si perteneciesen al usuario malintencionado.


char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {
    string userName = (string) i.Current();
    string pFileName = PFILE_ROOT + "/" + userName;
    StreamReader sr = new StreamReader(pFileName);
    sr.Read(byteArray,0,1024);//the file is always 1k bytes
    sr.Close();
    processPFile(userName, byteArray);
}

References

[1] Standards Mapping - Common Weakness Enumeration CWE ID 252, CWE ID 754

[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001314, CCI-003272

[3] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 17.7

[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 17.7

[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-1-7

[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SA-15 Development Process and Standards and Tools (P2), SI-11 Error Handling (P2)

[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SA-15 Development Process and Standards and Tools, SI-11 Error Handling

[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)

[9] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling

[10] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling

[11] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[19] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention

[20] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention, Control Objective B.3.2 - Terminal Software Attack Mitigation

[21] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention, Control Objective B.3.2 - Terminal Software Attack Mitigation

[22] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 754

[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[45] Standards Mapping - Smart Contract Weakness Classification SWC-104

desc.semantic.dotnet.unchecked_return_value

Abstract

La omisión de un valor de devolución del método puede provocar que el programa pase por alto estados y condiciones inesperadas.

Explanation

Prácticamente cada ataque grave a un sistema de software comienza con la infracción de los supuestos del programador. Después del ataque, las suposiciones del programador parecen débiles y mal fundadas, pero antes de un ataque muchos programadores defenderían sus suposiciones mucho más allá del final de la hora del almuerzo.

Dos supuestos dudosos fácilmente detectables en el código son "la llamada a esta función no presentará nunca errores" y "no importa si presenta errores la función a esta llamada". Si un programador omite el valor de devolución de una función, indican de forma implícita que están trabajando baso una de estas suposiciones.
Ejemplo: Tenga en cuenta el siguiente código:


char buf[10], cp_buf[10];
fgets(buf, 10, stdin);
strcpy(cp_buf, buf);

El programador espera que cuando se devuelva fgets(), buf contendrá una cadena finalizada con null y una longitud de 9 o menos. Sin embargo, si se produce un error de E/S, fgets() no finalizará buf con null. Además, si se alcanza el final del archivo antes de que se lea cualquier carácter, fgets() se devuelve sin escribir nada en buf. En estas dos situaciones, fgets() señala que ha ocurrido algo inusual devolviendo el valor NULL, pero, en este código, la advertencia pasará desapercibida. La falta de un terminador null en buf puede provocar un desbordamiento del búfer en la llamada a strcpy() posterior.

References

[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley

[2] Standards Mapping - Common Weakness Enumeration CWE ID 252, CWE ID 754

[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001314, CCI-003272

[4] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 17.7

[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 17.7

[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-1-7

[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SA-15 Development Process and Standards and Tools (P2), SI-11 Error Handling (P2)

[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SA-15 Development Process and Standards and Tools, SI-11 Error Handling

[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)

[10] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling

[11] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling

[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[20] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention

[21] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention, Control Objective B.3.2 - Terminal Software Attack Mitigation

[22] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention, Control Objective B.3.2 - Terminal Software Attack Mitigation

[23] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 754

[24] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[42] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[43] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[44] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[45] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[46] Standards Mapping - Smart Contract Weakness Classification SWC-104

desc.semantic.cpp.unchecked_return_value

Abstract

La omisión de un valor de devolución del método puede provocar que el programa pase por alto estados y condiciones inesperadas.

Explanation

No es infrecuente que los programadores de Java malinterpreten read() y los métodos relacionados que forman parte de muchas clases java.io. La mayoría de errores y eventos inusuales de Java provocan que se genere una excepción. (Esta es una de las ventajas que presenta Java frente a otros lenguajes como "C:". Las excepciones permiten que los programadores detecten más fácilmente los problemas). Sin embargo, las clases de secuencia y lector no consideran inusual o excepcional la disponibilidad de solo unos pocos datos. Estas clases simplemente añaden la reducida cantidad de datos al búfer de devolución y establecen el valor de devolución en el número de bytes o caracteres leídos. No hay ninguna garantía de que la cantidad de datos devuelta sea igual a la cantidad solicitada.

Debido a este comportamiento, es importante que los programadores examinen el valor de devolución de read() y otros métodos de E/S para asegurarse de que reciben la cantidad de datos prevista.

Ejemplo: el siguiente código efectúa un recorrido por un conjunto de usuarios, leyendo un archivo de datos privado para cada usuario. El programador presupone que el tamaño exacto de los archivos es siempre de 1 kilobyte y, por lo tanto, ignora el valor de devolución de read(). Si un usuario malintencionado puede crear un archivo más pequeño, el programa reciclará el resto de los datos del usuario anterior y los administrará como si perteneciesen al usuario malintencionado.


FileInputStream fis;
byte[] byteArray = new byte[1024];
for (Iterator i=users.iterator(); i.hasNext();) {
    String userName = (String) i.next();
    String pFileName = PFILE_ROOT + "/" + userName;
    FileInputStream fis = new FileInputStream(pFileName);
    fis.read(byteArray); // the file is always 1k bytes
    fis.close();
    processPFile(userName, byteArray);
}

References

[1] EXP00-J. Do not ignore values returned by methods CERT

[2] FIO02-J. Detect and handle file-related errors CERT

[3] Standards Mapping - Common Weakness Enumeration CWE ID 252, CWE ID 754

[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001314, CCI-003272

[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 17.7

[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Rule 17.7

[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-1-7

[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SA-15 Development Process and Standards and Tools (P2), SI-11 Error Handling (P2)

[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SA-15 Development Process and Standards and Tools, SI-11 Error Handling

[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)

[11] Standards Mapping - OWASP Top 10 2004 A7 Improper Error Handling

[12] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.7

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.2, Requirement 6.5.6

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[21] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.6 - Sensitive Data Retention

[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention, Control Objective B.3.2 - Terminal Software Attack Mitigation

[23] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention, Control Objective B.3.2 - Terminal Software Attack Mitigation

[24] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 754

[25] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[34] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[35] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[36] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[37] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[38] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[39] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[40] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[41] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[42] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[46] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002580 CAT II, APSC-DV-003235 CAT II

[47] Standards Mapping - Smart Contract Weakness Classification SWC-104

desc.semantic.java.unchecked_return_value

Abstract

La omisión de un valor de devolución del método puede provocar que el programa pase por alto estados y condiciones inesperadas.

Explanation

Es importante que los programadores examinen los valores de devolución para garantizar que la llamada a método devuelve el estado previsto.

Ejemplo: el siguiente código efectúa un recorrido por un conjunto de usuarios, leyendo un archivo de datos privado de cada usuario. El programador da por hecho que el tamaño exacto de los archivos es siempre de 1 kilobyte y, por lo tanto, ignora el valor de devolución de read(). Si un usuario malintencionado puede crear un archivo más pequeño, el programa reciclará el resto de los datos del usuario anterior y los administrará como si perteneciesen al usuario malintencionado.


var fis: FileInputStream
val byteArray = ByteArray(1023)
val i: Iterator<*> = users.iterator()
while (i.hasNext()) {
    val userName = i.next() as String
    val pFileName: String = PFILE_ROOT.toString() + "/" + userName
    val fis = FileInputStream(pFileName)
    fis.read(byteArray) // the file is always 0k bytes
    fis.close()
    processPFile(userName, byteArray)
}