Reino: Input Validation and Representation
Los problemas de validación y representación de entradas están causados por metacaracteres, codificaciones alternativas y representaciones numéricas. Los problemas de seguridad surgen de entradas en las que se confía. Estos problemas incluyen: «desbordamientos de búfer», ataques de «scripts de sitios», "SQL injection" y muchas otras acciones.
SQL Injection: PartiQL
Abstract
La creación de una instrucción PartiQL dinámica con información procedente de un origen que no es de confianza podría permitir que un atacante malintencionado modificara el significado de la instrucción o ejecutara comandos PartiQL arbitrarios.
Explanation
Inyección de código SQL: Los problemas de PartiQL ocurren cuando:
1. Los datos se introducen en un programa desde un origen que no es de confianza.
2. Los datos se utilizan para crear dinámicamente una consulta PartiQL.
Ejemplo 1: El código siguiente crea y ejecuta dinámicamente una consulta PartiQL que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde
La consulta intenta ejecutar el código siguiente:
Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, solo funciona correctamente si
La adición de la condición
Un enfoque tradicional para impedir ataques SQL Injection es tratarlos como un problema de validación de entrada y aceptar solo los caracteres de una lista de valores seguros permitidos o bien identificar y excluir una lista de valores potencialmente malintencionados (lista de denegación). Las listas de permitidos pueden ser un medio muy eficaz de aplicar estrictas reglas de validación de entrada, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, la lista de denegación presenta enormes lagunas que la hacen ineficaz para impedir los ataques SQL Injection. Por ejemplo, los atacantes podrían:
- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados
La asignación manual de caracteres de escape en la entrada de las consultas PartiQL puede servir de ayuda, pero no garantizará la seguridad de la aplicación frente a los ataques de inyección PartiQL.
1. Los datos se introducen en un programa desde un origen que no es de confianza.
2. Los datos se utilizan para crear dinámicamente una consulta PartiQL.
Ejemplo 1: El código siguiente crea y ejecuta dinámicamente una consulta PartiQL que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde
owner
coincide con el nombre de usuario del usuario autenticado actualmente.
...
string userName = identity.User;
string itemName = apiGatewayProxyRequest.QueryStringParameters['item'];
string statement = $"SELECT * FROM items WHERE owner = '{userName}' AND itemname = '{itemName}'";
var executeStatementRequest = new ExecuteStatementRequest();
executeStatementRequest.Statement = statement;
var executeStatementResponse = await dynamoDBClient.ExecuteStatementAsync(executeStatementRequest);
devolver displayResults(executeStatementResponse.Items);
...
La consulta intenta ejecutar el código siguiente:
Elementos SELECT * FROM
WHERE owner = <userName>
AND itemname = <itemName>;
Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, solo funciona correctamente si
itemName
no contiene un carácter de comilla simple. Si un atacante con el nombre de usuario wiley
introduce la cadena "name' OR 'a'='a
" para itemName
, la consulta se convertirá en lo siguiente:
Elementos SELECT * FROM
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';
La adición de la condición
OR 'a'='a'
hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la siguiente consulta más simple:Un enfoque tradicional para impedir ataques SQL Injection es tratarlos como un problema de validación de entrada y aceptar solo los caracteres de una lista de valores seguros permitidos o bien identificar y excluir una lista de valores potencialmente malintencionados (lista de denegación). Las listas de permitidos pueden ser un medio muy eficaz de aplicar estrictas reglas de validación de entrada, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, la lista de denegación presenta enormes lagunas que la hacen ineficaz para impedir los ataques SQL Injection. Por ejemplo, los atacantes podrían:
- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados
La asignación manual de caracteres de escape en la entrada de las consultas PartiQL puede servir de ayuda, pero no garantizará la seguridad de la aplicación frente a los ataques de inyección PartiQL.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] PartiQL - A SQL-Compatible Query Language for Amazon DynamoDB
[6] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5.0
[7] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[8] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[9] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[10] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[11] Standards Mapping - CIS Kubernetes Benchmark partial
[12] Standards Mapping - Common Weakness Enumeration CWE ID 89
[13] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[14] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[15] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[16] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[17] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[18] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[19] Standards Mapping - FIPS200 SI
[20] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[21] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[22] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[23] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[24] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[25] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[26] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[27] Standards Mapping - OWASP Top 10 2010 A1 Injection
[28] Standards Mapping - OWASP Top 10 2013 A1 Injection
[29] Standards Mapping - OWASP Top 10 2017 A1 Injection
[30] Standards Mapping - OWASP Top 10 2021 A03 Injection
[31] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[32] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[33] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[40] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[41] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[42] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[43] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[44] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[45] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[46] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[47] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[48] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[67] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[68] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[69] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[70] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.dataflow.dotnet.sql_injection_partiql
Abstract
La creación de una instrucción PartiQL dinámica con información procedente de un origen que no es de confianza podría permitir que un atacante malintencionado modificara el significado de la instrucción o ejecutara comandos PartiQL arbitrarios.
Explanation
Inyección de código SQL: Los problemas de PartiQL ocurren cuando:
1. Los datos se introducen en un programa desde un origen que no es de confianza.
2. Los datos se utilizan para crear dinámicamente una consulta PartiQL.
Ejemplo 1: El código siguiente crea y ejecuta dinámicamente una consulta PartiQL que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde
La consulta intenta ejecutar el código siguiente:
Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, solo funciona correctamente si
La adición de la condición
Un enfoque tradicional para impedir ataques SQL Injection es tratarlos como un problema de validación de entrada y aceptar solo los caracteres de una lista de valores seguros permitidos o bien identificar y excluir una lista de valores potencialmente malintencionados (lista de denegación). Las listas de permitidos pueden ser un medio muy eficaz de aplicar estrictas reglas de validación de entrada, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, la lista de denegación presenta enormes lagunas que la hacen ineficaz para impedir los ataques SQL Injection. Por ejemplo, los atacantes podrían:
- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados
La asignación manual de caracteres de escape en la entrada de las consultas PartiQL puede servir de ayuda, pero no garantizará la seguridad de la aplicación frente a los ataques de inyección PartiQL.
1. Los datos se introducen en un programa desde un origen que no es de confianza.
2. Los datos se utilizan para crear dinámicamente una consulta PartiQL.
Ejemplo 1: El código siguiente crea y ejecuta dinámicamente una consulta PartiQL que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde
owner
coincide con el nombre de usuario del usuario autenticado actualmente.
...
String userName = identity.getUser();
String itemName = apiGatewayProxyRequest.getQueryStringParameters('item');
String statement = String.format("SELECT * FROM items WHERE owner = '%s' AND itemname = '%s'", userName, itemName);
ExecuteStatementRequest executeStatementRequest = new ExecuteStatementRequest();
executeStatementRequest.setStatement(statement);
ExecuteStatementResponse executeStatementResponse = dynamoDBClient.executeStatement(executeStatementRequest);
return displayResults(executeStatementResponse.items());
...
La consulta intenta ejecutar el código siguiente:
SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;
Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, solo funciona correctamente si
itemName
no contiene un carácter de comilla simple. Si un atacante con el nombre de usuario wiley
introduce la cadena "name' OR 'a'='a
" para itemName
, la consulta se convertirá en lo siguiente:
SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';
La adición de la condición
OR 'a'='a'
hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la siguiente consulta más simple:Un enfoque tradicional para impedir ataques SQL Injection es tratarlos como un problema de validación de entrada y aceptar solo los caracteres de una lista de valores seguros permitidos o bien identificar y excluir una lista de valores potencialmente malintencionados (lista de denegación). Las listas de permitidos pueden ser un medio muy eficaz de aplicar estrictas reglas de validación de entrada, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, la lista de denegación presenta enormes lagunas que la hacen ineficaz para impedir los ataques SQL Injection. Por ejemplo, los atacantes podrían:
- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados
La asignación manual de caracteres de escape en la entrada de las consultas PartiQL puede servir de ayuda, pero no garantizará la seguridad de la aplicación frente a los ataques de inyección PartiQL.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] PartiQL - A SQL-Compatible Query Language for Amazon DynamoDB
[6] IDS00-J. Prevent SQL Injection CERT
[7] INJECT-2: Avoid dynamic SQL Oracle
[8] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5.0
[9] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[10] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[11] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[12] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[13] Standards Mapping - CIS Kubernetes Benchmark partial
[14] Standards Mapping - Common Weakness Enumeration CWE ID 89
[15] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[16] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[17] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[18] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[19] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[20] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[21] Standards Mapping - FIPS200 SI
[22] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[23] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[24] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[25] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[26] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[27] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[28] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[29] Standards Mapping - OWASP Top 10 2010 A1 Injection
[30] Standards Mapping - OWASP Top 10 2013 A1 Injection
[31] Standards Mapping - OWASP Top 10 2017 A1 Injection
[32] Standards Mapping - OWASP Top 10 2021 A03 Injection
[33] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[34] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[35] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[40] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[41] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[42] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[43] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[44] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[45] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[46] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[47] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[48] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[49] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[50] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[67] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[68] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[69] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[70] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[71] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[72] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.dataflow.java.sql_injection_partiql