Reino: Input Validation and Representation
Problemas de validação e representação da entrada são causados por metacaracteres, codificações alternativas e representações numéricas. Confiar na entrada resulta em problemas de segurança. Os problemas incluem: “Buffer Overflows”, ataques de “Cross-Site Scripting”, “SQL Injection”, entre outros.
XQuery Injection
Abstract
A construção de uma expressão XQuery dinâmica com uma entrada de usuário pode permitir que um invasor modifique o significado da instrução.
Explanation
Uma injeção de XQuery ocorre quando:
1. Os dados entram em um programa por uma fonte não confiável.
2. Os dados utilizados para construir dinamicamente uma expressão XQuery.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma expressão XQuery que recupera uma conta de usuário para uma determinada combinação de nome de usuário e senha. O nome de usuário e a senha são lidos de uma solicitação HTTP e, portanto, não são confiáveis.
Em condições normais, tais como ao procurar uma conta de usuário com o nome de usuário e a senha apropriados, a expressão que esse código executa terá a seguinte aparência:
No entanto, como a expressão é construída dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, ela se comportará corretamente somente se
A adição da condição
Essa simplificação da consulta permite que o invasor ignore a exigência de que a consulta deva corresponder à senha. Agora, ela retorna o usuário administrador armazenado no documento, independentemente da senha inserida.
1. Os dados entram em um programa por uma fonte não confiável.
2. Os dados utilizados para construir dinamicamente uma expressão XQuery.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma expressão XQuery que recupera uma conta de usuário para uma determinada combinação de nome de usuário e senha. O nome de usuário e a senha são lidos de uma solicitação HTTP e, portanto, não são confiáveis.
...
String squery = "for \$user in doc(users.xml)//user[username='" + Request["username"] + "'and pass='" + Request["password"] + "'] return \$user";
Processor processor = new Processor();
XdmNode indoc = processor.NewDocumentBuilder().Build(new Uri(Server.MapPath("users.xml")));
StreamReader query = new StreamReader(squery);
XQueryCompiler compiler = processor.NewXQueryCompiler();
XQueryExecutable exp = compiler.Compile(query.ReadToEnd());
XQueryEvaluator eval = exp.Load();
eval.ContextItem = indoc;
Serializer qout = new Serializer();
qout.SetOutputProperty(Serializer.METHOD, "xml");
qout.SetOutputProperty(Serializer.DOCTYPE_PUBLIC, "-//W3C//DTD XHTML 1.0 Strict//EN");
qout.SetOutputProperty(Serializer.DOCTYPE_SYSTEM, "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd");
qout.SetOutputProperty(Serializer.INDENT, "yes");
qout.SetOutputProperty(Serializer.OMIT_XML_DECLARATION, "no");
qout.SetOutputWriter(Response.Output);
eval.Run(qout);
...
Em condições normais, tais como ao procurar uma conta de usuário com o nome de usuário e a senha apropriados, a expressão que esse código executa terá a seguinte aparência:
for \$user in doc(users.xml)//user[username='test_user' and pass='pass123'] return \$user
No entanto, como a expressão é construída dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, ela se comportará corretamente somente se
username
ou password
não contiver um caractere de aspas simples. Se um invasor inserir a string admin' or 1=1 or ''='
para username
, a consulta se tornará a seguinte:for \$user in doc(users.xml)//user[username='admin' or 1=1 or ''='' and password='x' or ''=''] return \$user
A adição da condição
admin' or 1=1 or ''='
faz com que a expressão XQuery sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples://user[username='admin']
Essa simplificação da consulta permite que o invasor ignore a exigência de que a consulta deva corresponder à senha. Agora, ela retorna o usuário administrador armazenado no documento, independentemente da senha inserida.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 652
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[10] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 XQuery Injection (WASC-46)
desc.dataflow.dotnet.xquery_injection
Abstract
A construção de uma expressão XQuery dinâmica com uma entrada de usuário pode permitir que um invasor modifique o significado da instrução.
Explanation
Uma injeção de XQuery ocorre quando:
1. Os dados entram em um programa por uma fonte não confiável.
2. Os dados utilizados para construir dinamicamente uma expressão XQuery.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma expressão XQuery que recupera uma conta de usuário para uma determinada combinação de nome de usuário e senha. O nome de usuário e a senha são lidos de uma solicitação HTTP e, portanto, não são confiáveis.
Em condições normais, tais como ao procurar uma conta de usuário com o nome de usuário e a senha apropriados, a expressão que esse código executa terá a seguinte aparência:
No entanto, como a expressão é construída dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, seu comportamento só será correto se
A adição da condição
Essa simplificação da consulta permite que o invasor ignore a exigência de que a consulta deve corresponder à senha. Agora, ela retorna o usuário administrador armazenado no documento, independentemente da senha inserida.
1. Os dados entram em um programa por uma fonte não confiável.
2. Os dados utilizados para construir dinamicamente uma expressão XQuery.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma expressão XQuery que recupera uma conta de usuário para uma determinada combinação de nome de usuário e senha. O nome de usuário e a senha são lidos de uma solicitação HTTP e, portanto, não são confiáveis.
...
XQDataSource xqs = new XQDataSource();
XQConnection conn = xqs.getConnection();
String query = "for \$user in doc(users.xml)//user[username='" + request.getParameter("username") + "'and pass='" + request.getParameter("password") + "'] return \$user";
XQPreparedExpression xqpe = conn.prepareExpression(query);
XQResultSequence rs = xqpe.executeQuery();
...
Em condições normais, tais como ao procurar uma conta de usuário com o nome de usuário e a senha apropriados, a expressão que esse código executa terá a seguinte aparência:
for \$user in doc(users.xml)//user[username='test_user' and pass='pass123'] return \$user
No entanto, como a expressão é construída dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, seu comportamento só será correto se
username
ou password
não contiver um caractere de aspas simples. Se um invasor inserir a string admin' or 1=1 or ''='
para username
, a consulta se tornará a seguinte:for \$user in doc(users.xml)//user[username='admin' or 1=1 or ''='' and password='x' or ''=''] return \$user
A adição da condição
admin' or 1=1 or ''='
faz com que a expressão XQuery sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples://user[username='admin']
Essa simplificação da consulta permite que o invasor ignore a exigência de que a consulta deve corresponder à senha. Agora, ela retorna o usuário administrador armazenado no documento, independentemente da senha inserida.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 652
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[10] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 XQuery Injection (WASC-46)
desc.dataflow.java.xquery_injection
Abstract
A construção de uma expressão XQuery dinâmica com uma entrada de usuário pode permitir que um invasor modifique o significado da instrução.
Explanation
Uma injeção de XQuery ocorre quando:
1. Os dados entram em um programa por uma fonte não confiável.
2. Os dados são usados para construir dinamicamente uma consulta XQuery.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma expressão XQuery que recupera uma conta de usuário para uma determinada combinação de nome de usuário e senha. O nome de usuário e a senha são lidos de uma solicitação HTTP e, portanto, não são confiáveis.
Em condições normais, tais como ao procurar uma conta de usuário com o nome de usuário e a senha apropriados, a expressão que esse código executa terá a seguinte aparência:
No entanto, como a expressão é construída dinamicamente pela concatenação de uma cadeia de caracteres de consulta constante e uma cadeia de caracteres de entrada de usuário, a consulta só se comportará corretamente se
A adição da condição
Essa simplificação da consulta permite que o invasor ignore a exigência de que a consulta deve corresponder à senha. Agora, ela retorna o usuário administrador armazenado no documento, independentemente da senha inserida.
1. Os dados entram em um programa por uma fonte não confiável.
2. Os dados são usados para construir dinamicamente uma consulta XQuery.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma expressão XQuery que recupera uma conta de usuário para uma determinada combinação de nome de usuário e senha. O nome de usuário e a senha são lidos de uma solicitação HTTP e, portanto, não são confiáveis.
...
$memstor = InMemoryStore::getInstance();
$z = Zorba::getInstance($memstor);
try {
// get data manager
$dataman = $z->getXmlDataManager();
// load external XML document
$dataman->loadDocument('users.xml', file_get_contents('users.xml'));
// create and compile query
$express =
"for \$user in doc(users.xml)//user[username='" . $_GET["username"] . "'and pass='" . $_GET["password"] . "'] return \$user"
$query = $zorba->compileQuery($express);
// execute query
$result = $query->execute();
?>
...
Em condições normais, tais como ao procurar uma conta de usuário com o nome de usuário e a senha apropriados, a expressão que esse código executa terá a seguinte aparência:
for \$user in doc(users.xml)//user[username='test_user' and pass='pass123'] return \$user
No entanto, como a expressão é construída dinamicamente pela concatenação de uma cadeia de caracteres de consulta constante e uma cadeia de caracteres de entrada de usuário, a consulta só se comportará corretamente se
username
ou password
não tiver um caractere de aspas simples. Se um invasor inserir a string admin' or 1=1 or ''='
para username
, a consulta se tornará a seguinte:for \$user in doc(users.xml)//user[username='admin' or 1=1 or ''='' and password='x' or ''=''] return \$user
A adição da condição
admin' or 1=1 or ''='
faz com que a expressão XQuery sempre seja avaliada como "true" e, portanto, a consulta torna-se logicamente equivalente à seguinte consulta muito mais simples://user[username='admin']
Essa simplificação da consulta permite que o invasor ignore a exigência de que a consulta deve corresponder à senha. Agora, ela retorna o usuário administrador armazenado no documento, independentemente da senha inserida.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 652
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[10] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] 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
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Web Application Security Consortium Version 2.00 XQuery Injection (WASC-46)
desc.dataflow.php.xquery_injection