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.

175 itens encontrados
Vulnerabilidades
Abstract
O aplicativo é implantado no modo de desenvolvimento (devMode), permitindo a execução arbitrária de comandos no servidor e o vazamento de informações detalhadas sobre como o aplicativo é codificado.
Explanation
O Struts 2 tem uma configuração chamada devMode (modo de desenvolvimento). Quando essa configuração está habilitada, o Struts 2 fornecerá informações adicionais de registro e depuração, que podem acelerar significativamente o desenvolvimento ao custo de um alto impacto no desempenho e na segurança. O devMode aumentará o nível de depuração ou problemas normalmente ignoráveis para exceções que normalmente não seriam lançadas no modo normal.

O devMode também permite alguns recursos de depuração que permitem aos desenvolvedores verificar as variáveis armazenadas na pilha de valores. Esses recursos podem ser acionados usando o parâmetro de solicitação debug:
- debug = console irá exibir um console de avaliação OGNL, permitindo que os desenvolvedores avaliem qualquer expressão OGNL arbitrária no servidor.
- debug = command permitirá que os desenvolvedores enviem expressões OGNL arbitrárias para serem avaliadas usando o parâmetro de solicitação expression.
- debug=xml despejará os parâmetros, o contexto, a sessão e a pilha de valores como um documento XML.
- debug=browser despejará os parâmetros, o contexto, a sessão e a pilha de valores como um documento HTML navegável.
References
[1] Apache Struts 2 Documentation - devMode
[2] Apache Struts 2 Documentation - Debugging
[3] Meder Kydyraliev Milking a horse or executing remote code in modern Java frameworks
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 94, CWE ID 95
[12] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[13] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[14] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[15] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[16] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[17] Standards Mapping - FIPS200 SI
[18] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[19] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[20] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[21] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[22] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[23] Standards Mapping - OWASP Top 10 2010 A1 Injection
[24] Standards Mapping - OWASP Top 10 2013 A1 Injection
[25] Standards Mapping - OWASP Top 10 2017 A1 Injection
[26] Standards Mapping - OWASP Top 10 2021 A03 Injection
[27] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.4 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[28] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[29] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[39] 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
[40] 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
[41] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.config.java.ognl_expression_injection_struts2_devmode
Abstract
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
Explanation
Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O seguinte código ABAP instrui o navegador do usuário a abrir uma URL analisada a partir do parâmetro de solicitação dest quando esse usuário clica no link.


...
DATA: str_dest TYPE c.

str_dest = request->get_form_field( 'dest' ).
response->redirect( str_dest ).
...


Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.
desc.dataflow.abap.open_redirect
Abstract
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
Explanation
Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O seguinte código ActionScript instrui o navegador do usuário a abrir uma URL lida a partir do parâmetro de solicitação dest quando esse usuário clica no link.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var strDest:String = String(params["dest"]);
host.updateLocation(strDest);
...


Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.
desc.dataflow.actionscript.open_redirect
Abstract
Um arquivo transmite dados não validados para um redirecionamento HTTP.
Explanation
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing. Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos usam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. As vulnerabilidades de Open Redirect ocorrem quando um aplicativo Web redireciona clientes para qualquer URL arbitrária que um invasor possa controlar.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O método de ação a seguir do Visualforce retorna um objeto PageReference que consiste em uma URL do parâmetro de solicitação dest.


public PageReference pageAction() {
...
PageReference ref = ApexPages.currentPage();
Map<String,String> params = ref.getParameters();
return new PageReference(params.get('dest'));
}


Se a vítima receber um email instruindo o usuário a seguir um link para "http://trusted.vf.force.com/apex/vfpage?dest=www.wilyhacker.com", esse usuário poderá clicar no link acreditando que acessará um site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails e garantir que o link especifica um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final mais experiente poderá ser levado a clicar no link.
desc.dataflow.apex.open_redirect
Abstract
O aplicativo define uma propriedade que permite a entrada não validada para controlar o URL usado em um redirecionamento automatizado e pode ajudar no ataque de phishing.
Explanation
Por padrão, a página de login do ASP.NET não permitirá o redirecionamento do URL para fora do domínio hospedado durante o processo de autenticação do usuário. No entanto, essa funcionalidade pode ser modificada usando a configuração aspnet:AllowRelaxedRelativeUrl para permitir o redirecionamento irrestrito do URL. Um invasor que explorar com êxito esta vulnerabilidade poderá redirecionar um usuário a um site da escolha do invasor sem o consentimento do usuário. O invasor pode então realizar um ataque de phishing para obter informações do usuário que ele não pretendia divulgar.

Exemplo 1: No exemplo a seguir, aspnet:AllowRelaxedRelativeUrl está definido como true.

...
<appSettings>
<add key="aspnet:AllowRelaxedRelativeUrl" value="true" />
</appSettings>
...
References
[1] ASP.NET appSettings Element Microsoft
[2] Microsoft Security Bulletin MS11-100 - Critical Microsoft
desc.configuration.dotnet.open_redirect
Abstract
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
Explanation
Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. As vulnerabilidades de Open Redirect ocorrem quando um aplicativo Web redireciona clientes para qualquer URL arbitrária que pode ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O código JSP a seguir instrui o navegador do usuário a abrir uma URL analisada com base no parâmetro de solicitação dest quando esse usuário clica no link.


...
final server = await HttpServer.bind(host, port);
await for (HttpRequest request in server) {
final response = request.response;
final headers = request.headers;
final strDest = headers.value('strDest');
response.headers.contentType = ContentType.text;
response.redirect(Uri.parse(strDest!));
await response.close();
}
...


Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifica um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final mais experiente poderá ser levado a clicar no link.
desc.dataflow.dart.open_redirect
Abstract
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
Explanation
Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. As vulnerabilidades de Open Redirect ocorrem quando um aplicativo Web redireciona clientes para qualquer URL arbitrária que um invasor possa controlar.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo: O código a seguir instrui o navegador do usuário a abrir uma URL analisada com base no parâmetro de solicitação dest quando esse usuário clica no link.


...
strDest := r.Form.Get("dest")
http.Redirect(w, r, strDest, http.StatusSeeOther)
...


Se uma vítima receber um email instruindo-a a seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", o usuário provavelmente clicará no link, acreditando que será transferido para o site confiável. No entanto, quando ele clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifica um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final mais experiente poderá ser levado a clicar no link.
desc.dataflow.golang.open_redirect
Abstract
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
Explanation
Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. As vulnerabilidades de Open Redirect ocorrem quando um aplicativo Web redireciona clientes para qualquer URL arbitrária que pode ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: A seguinte definição de estado de fluxo Spring WebFlow instrui o navegador do usuário a abrir um URL analisado com base no parâmetro de solicitação dest quando esse usuário clica no link.


<end-state id="redirectView" view="externalRedirect:#{requestParameters.dest}" />


Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifica um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final mais experiente poderá ser levado a clicar no link.
desc.configuration.java.open_redirect
Abstract
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
Explanation
Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: Esse código JavaScript instrui o navegador do usuário a abrir uma URL lida a partir do parâmetro de solicitação dest quando um usuário clica no link.


...
strDest = form.dest.value;
window.open(strDest,"myresults");
...


Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.
desc.dataflow.javascript.open_redirect
Abstract
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
Explanation
Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O código PHP a seguir instrui o navegador do usuário a abrir uma URL analisada do parâmetro de solicitação dest quando um usuário clica no link.


<%
...
$strDest = $_GET["dest"];
header("Location: " . $strDest);
...
%>


Se o usuário tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.php?dest=www.wilyhacker.com", ele provavelmente clicará nesse link acreditando que será transferido ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.php?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

e até mesmo um usuário experiente poderia ser enganado a clicar no link.
desc.dataflow.php.open_redirect
Abstract
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
Explanation
Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: Este procedimento instrui o navegador do usuário a abrir uma URL analisada a partir do parâmetro da solicitação dest quando um usuário clica no link.


...
-- Assume QUERY_STRING looks like dest=http://www.wilyhacker.com
dest := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 6);
OWA_UTIL.redirect_url('dest');
...


Se o usuário tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/pls/hr/showemps?dest=www.wilyhacker.com", ele provavelmente clicará nesse link acreditando que será transferido ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/pls/hr/showemps?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.
desc.dataflow.sql.open_redirect
Abstract
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
Explanation
Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: Este código Python instrui o navegador do usuário a abrir uma URL analisada a partir do parâmetro da solicitação dest quando um usuário clica no link.


...
strDest = request.field("dest")
redirect(strDest)
...


Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.
desc.dataflow.python.open_redirect
Abstract
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
Explanation
Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: Este código Ruby instrui o navegador do usuário a abrir uma URL analisada a partir do parâmetro da solicitação dest:


...
str_dest = req.params['dest']
...
res = Rack::Response.new
...
res.redirect("http://#{dest}")
...


Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.
desc.dataflow.ruby.open_redirect
Abstract
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
Explanation
Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O seguinte método do controlador Play instrui o navegador do usuário a abrir uma URL analisada a partir do parâmetro da solicitação dest.


def myAction = Action { implicit request =>
...
request.getQueryString("dest") match {
case Some(location) => Redirect(location)
case None => Ok("No url found!")
}
...
}


Se a vítima tiver recebido um email com instruções para seguir um link para "http://trusted.example.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ela provavelmente clicará nesse link acreditando que será transferida ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido.No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://trusted.example.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final experiente poderá ser enganado e convencido a seguir o link.
desc.dataflow.scala.open_redirect
Abstract
Permitir que uma entrada não validada controle a URL usada em um redirecionamento pode auxiliar ataques de phishing.
Explanation
Redirecionamentos permitem que aplicativos Web direcionem os usuários para páginas diferentes no mesmo aplicativo ou para sites externos. Os aplicativos utilizam redirecionamentos para auxiliar na navegação do site e, em alguns casos, para controlar como os usuários saem do site. Vulnerabilidades de redirecionamento aberto ocorrem quando um aplicativo Web redireciona os clientes para qualquer URL arbitrária que possa ser controlada por um invasor.

Os invasores podem utilizar open redirects para convencer os usuários a visitar uma URL para um site confiável, mas depois redirecioná-los para um site mal-intencionado. Ao codificar a URL, um invasor pode tornar difícil para os usuários finais perceberem o destino mal-intencionado do redirecionamento, mesmo quando ele é transmitido como um parâmetro de URL ao site confiável. Redirecionamentos abertos são muitas vezes mal utilizados como parte de esquemas de phishing para coletar dados confidenciais dos usuários finais.

Exemplo 1: O seguinte código VB instrui o navegador do usuário para abrir uma URL analisada do parâmetro de solicitação dest quando um usuário clica no link.


...
strDest = Request.Form('dest')
HyperLink.NavigateTo strDest
...


Se o usuário tiver recebido um email com instruções para seguir um link para ""http://www.trustedsite.com/ecommerce/redirect.asp?dest=www.wilyhacker.com", ele provavelmente clicará nesse link acreditando que será transferido ao site confiável. No entanto, quando ela clicar no link, o código no Example 1 redirecionará o navegador para "http://www.wilyhacker.com".

Muitos usuários foram instruídos a sempre inspecionarem URLs que eles recebem em emails, para garantir que o link especifique um site confiável conhecido. No entanto, se o invasor tiver codificado a URL de destino em formato hexadecimal, da seguinte maneira:
"http://www.trustedsite.com/ecommerce/redirect.asp?dest=%77%69%6C%79%68%61%63%6B%65%72%2E%63%6F%6D"

até mesmo um usuário final mais experiente pode ser levado a clicar no link.
References
[1] Phishers use IRS tax refund as bait CNet News
desc.dataflow.vb.open_redirect
Abstract
O programa lê dados de fora dos limites da memória alocada.
Explanation
O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, o programa lê de fora dos limites da memória alocada, o que pode permitir acesso a informações confidenciais, introduzir comportamentos incorretos ou fazer com que o programa trave.

Exemplo 1: No código a seguir, a chamada para memcpy() lê a memória de fora dos limites alocados de cArray, que contém elementos MAX do tipo char, enquanto iArray contém elementos MAX do tipo int.


void MemFuncs() {
char array1[MAX];
int array2[MAX];
memcpy(array2, array1, sizeof(array2));
}
Exemplo 2: O seguinte programa curto usa um argumento de linha de comando não confiável como buffer de pesquisa em uma chamada para memchr() com um número constante de bytes a serem analisados.


int main(int argc, char** argv) {
char* ret = memchr(argv[0], 'x', MAX_PATH);
printf("%s\n", ret);
}


O programa deve imprimir uma subcadeia de caracteres de argv[0] pesquisando os dados de argv[0] até um número constante de bytes. No entanto, como o número (constante) de bytes pode ser maior que os dados alocados para argv[0], a pesquisa pode continuar além dos dados alocados para argv[0]. Esse será o caso quando x não se encontrar em argv[0].
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
desc.internal.cpp.out_of_bounds_read
Abstract
O programa lê dados somente de fora dos limites da memória alocada.
Explanation
O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de erro "off-by-one" ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e de pilha, entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, o programa lê de fora dos limites da memória alocada, o que pode permitir acesso a informações confidenciais, introduzir comportamentos incorretos ou fazer com que o programa trave.

Exemplo: O código a seguir desfaz sequencialmente desreferência ao array de cinco elementos de char, com a última referência introduzindo um erro "off-by-one".


char Read() {

char buf[5];
return 0
+ buf[0]
+ buf[1]
+ buf[2]
+ buf[3]
+ buf[4]
+ buf[5];
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 125, CWE ID 129, CWE ID 131, CWE ID 193, CWE ID 805
[11] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119, [3] CWE ID 020, [5] CWE ID 125
[12] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119, [3] CWE ID 020, [4] CWE ID 125
[13] Standards Mapping - Common Weakness Enumeration Top 25 2021 [3] CWE ID 125, [4] CWE ID 020, [17] CWE ID 119
[14] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020, [5] CWE ID 125, [19] CWE ID 119
[15] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020, [7] CWE ID 125, [17] CWE ID 119
[16] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[18] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[20] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[21] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[22] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[23] 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)
[24] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[25] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[26] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[36] 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, Control Objective B.3.1.2 - Terminal Software Attack Mitigation
[37] 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 B.3.1.2 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[38] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 119, Risky Resource Management - CWE ID 682
[39] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 805, Risky Resource Management - CWE ID 129, Risky Resource Management - CWE ID 131
[40] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 131
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3590.1 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3590.1 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3590.1 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3590.1 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3590.1 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3590.1 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
desc.internal.cpp.out_of_bounds_read_off_by_one
Abstract
O programa usa uma comparação com sinal para verificar um valor que posteriormente é tratado como sem sinal. Isso pode fazer com que o programa leia dados de fora dos limites da memória alocada.
Explanation
O buffer overflow é provavelmente a forma mais conhecida de vulnerabilidade de segurança de software. A maioria dos desenvolvedores de software sabe o que é uma vulnerabilidade de buffer overflow, mas ataques de buffer overflow contra aplicativos legados e recém-desenvolvidos ainda são bastante comuns. Uma parte do problema deve-se à grande variedade de maneiras de como estouros de buffer podem ocorrer, enquanto outra parte deve-se às técnicas propensas a erros frequentemente utilizadas para impedir esses estouros.

Em uma exploração de buffer overflow clássica, o invasor envia dados a um programa, que ele armazena em um buffer de pilha de tamanho menor do que o normal. O resultado é que as informações na pilha de chamadas são substituídas, incluindo o apontador de retorno da função. Os dados definem o valor do apontador de retorno de forma que, quando a função é retornada, ela transfere o controle para o código mal-intencionado contido nos dados do invasor.

Embora esse tipo de buffer overflow de pilha ainda seja comum em algumas plataformas e comunidades de desenvolvimento, há vários outros tipos de buffer overflow, incluindo estouros de buffer de heap e erros "off-by-one", entre outros. Existem diversos livros excelentes que fornecem informações detalhadas sobre como ataques de buffer overflow funcionam, entre eles Building Secure Software [1], Writing Secure Code [2] e The Shellcoder's Handbook [3].

Em nível de código, vulnerabilidades de buffer overflow geralmente envolvem a violação das premissas do programador. Muitas funções de manipulação de memória em C e C++ não realizam verificações de limites e podem facilmente exceder os limites alocados dos buffers sob os quais elas operam. Até mesmo funções limitadas, como strncpy(), podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.

Nesse caso, o programa lê de fora dos limites da memória alocada, o que pode permitir acesso a informações confidenciais, introduzir comportamentos incorretos ou fazer com que o programa trave.

Exemplo: O código a seguir tenta evitar um buffer overflow de leitura fora dos limites, verificando que o valor não confiável lido de getInputLength() é menor que o tamanho do buffer de destino output. No entanto, como a comparação entre len e MAX tem sinal, se len for negativo, ele se tornará um número positivo muito grande quando for convertido em um argumento sem sinal para memcpy().


void TypeConvert() {
char input[MAX];
char output[MAX];

fillBuffer(input);
int len = getInputLength();

if (len <= MAX) {
memcpy(output, input, len);
}
...
}
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[3] J. Koziol et al. The Shellcoder's Handbook: Discovering and Exploiting Security Holes John Wiley & Sons
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 195, CWE ID 805
[11] Standards Mapping - Common Weakness Enumeration Top 25 2019 [1] CWE ID 119
[12] Standards Mapping - Common Weakness Enumeration Top 25 2020 [5] CWE ID 119
[13] Standards Mapping - Common Weakness Enumeration Top 25 2021 [17] CWE ID 119
[14] Standards Mapping - Common Weakness Enumeration Top 25 2022 [19] CWE ID 119
[15] Standards Mapping - Common Weakness Enumeration Top 25 2023 [17] CWE ID 119
[16] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[18] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[20] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[21] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[22] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[23] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[24] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[25] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] 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.2 - Terminal Software Attack Mitigation
[36] 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.2 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 805
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3550 CAT I, APP3590.1 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3550 CAT I, APP3590.1 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3550 CAT I, APP3590.1 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3550 CAT I, APP3590.1 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3550 CAT I, APP3590.1 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3550 CAT I, APP3590.1 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3550 CAT I, APP3590.1 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002590 CAT I
desc.internal.cpp.out_of_bounds_read_signed_comparison
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique arquivos que de outra forma estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir utiliza a entrada de uma solicitação HTTP para criar um nome de arquivo.


...
*Get the report that is to be deleted
r_name = request->get_form_field( 'report_name' ).
CONCATENATE `C:\\users\\reports\\` r_name INTO dsn.
DELETE DATASET dsn.
...


Se um invasor fornecer um nome de arquivo como "..\\..\\usr\\sap\\DVEBMGS00\\exe\\disp+work.exe", o aplicativo excluirá um arquivo crítico e travará imediatamente o sistema SAP.

Exemplo 2: O código a seguir tem a função de exibir os detalhes de faturas para qualquer data fornecida pelo usuário.


...
PARAMETERS: p_date TYPE string.

*Get the invoice file for the date provided
CALL FUNCTION 'FILE_GET_NAME'
EXPORTING
logical_filename = 'INVOICE'
parameter_1 = p_date
IMPORTING
file_name = v_file
EXCEPTIONS
file_not_found = 1
OTHERS = 2.
IF sy-subrc <> 0.
* Implement suitable error handling here
ENDIF.

OPEN DATASET v_file FOR INPUT IN TEXT MODE.

DO.
READ DATASET v_file INTO v_record.
IF SY-SUBRC NE 0.
EXIT.
ELSE.
WRITE: / v_record.
ENDIF.
ENDDO.
...


Se um invasor fornecer uma string como "..\\..\\usr\\sap\\sys\\profile\\default.pfl" em vez de uma data válida, o aplicativo revelará todas as configurações padrão de parâmetros de perfil do servidor de aplicativos SAP, possivelmente provocando ataques mais refinados.
References
[1] SAP OSS Notes 1497003, 1543851, 177702 and related ones.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.abap.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de uma solicitação HTTP para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "../../tomcat/conf/server.xml", que faz com que o aplicativo exclua um dos seus próprios arquivos de configuração.


var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var rName:String = String(params["reportName"]);
var rFile:File = new File("/usr/local/apfr/reports/" + rName);
...
rFile.deleteFile();
Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para determinar qual arquivo deve ser aberto e para gravar em um console de "Depuração" ou em um arquivo de log. Se o programa for executado com privilégios adequados, e usuários mal-intencionados puderem alterar o arquivo de configuração, eles poderão usar esse programa para ler qualquer arquivo no sistema que termine com a extensão .txt.


var fs:FileStream = new FileStream();
fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
fs.readBytes(arr);
trace(arr);
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.actionscript.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Exemplo 1: O método de ação a seguir do Visualforce usa a entrada do usuário para acessar um recurso estático.


public class MyController {
...
public PageRerference loadRes() {
PageReference ref = ApexPages.currentPage();
Map<String,String> params = ref.getParameters();
if (params.containsKey('resName')) {
if (params.containsKey('resPath')) {
return PageReference.forResource(params.get('resName'), params.get('resPath'));
}
}
return null;
}
}


O programador não considerou a possibilidade de um invasor manipular o nome e o caminho do recurso para acessar recursos que não devem ser voltados para o público.
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.apex.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de uma solicitação HTTP para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "..\\..\\Windows\\System32\\krnl386.exe", que fará com que o aplicativo exclua um importante arquivo do sistema Windows.


String rName = Request.Item("reportName");
...
File.delete("C:\\users\\reports\\" + rName);
Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para determinar qual arquivo deve ser aberto e ecoado de volta para o usuário. Se o programa for executado com privilégios adequados, e usuários mal-intencionados puderem alterar o arquivo de configuração, eles poderão usar esse programa para ler qualquer arquivo no sistema que termine com a extensão ".txt".


sr = new StreamReader(resmngr.GetString("sub")+".txt");
while ((line = sr.ReadLine()) != null) {
Console.WriteLine(line);
}
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.dotnet.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de uma solicitação CGI para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "../../apache/conf/httpd.conf", que fará com que o aplicativo exclua o arquivo de configuração especificado.


char* rName = getenv("reportName");
...
unlink(rName);
Exemplo 2: O código a seguir usa a entrada da linha de comando para determinar qual arquivo deve ser aberto e ecoado de volta para o usuário. Se o programa for executado com privilégios adequados, e usuários mal-intencionados puderem criar links flexíveis para o arquivo, eles poderão usar esse programa para ler a primeira parte de qualquer arquivo no sistema.


ifstream ifs(argv[0]);
string s;
ifs >> s;
cout << s;
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.cpp.path_manipulation
Abstract
Permitir que a entrada do usuário controle nomes de recursos de arquivo usados em operações de arquivo pode viabilizar que um invasor acesse ou modifique conjuntos de dados não pretendidos pelo aplicativo.
Explanation
Erros de manipulação de caminho no CICS ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um nome de recurso de arquivo (FCT) usado em uma operação de arquivo CICS.

2. Ao especificar o recurso, o invasor pode obter acesso não autorizado.

Por exemplo, o programa pode dar ao invasor a capacidade de ler ou gravar dados configurados para uma região CICS normalmente não acessada pelo aplicativo.
Exemplo: O código a seguir usa uma entrada de um formulário HTML para atualizar ou possivelmente excluir um registro de um arquivo.


...
EXEC CICS
WEB READ
FORMFIELD(FILE)
VALUE(FILENAME)
...
END-EXEC.

EXEC CICS
READ
FILE(FILENAME)
INTO(RECORD)
RIDFLD(ACCTNO)
UPDATE
...
END-EXEC.
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.cobol.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de um formulário da Web para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "..\\..\\Windows\\System32\\krnl386.exe", que fará com que o aplicativo exclua um importante arquivo do sistema Windows.


<cffile action = "delete"
file = "C:\\users\\reports\\#Form.reportName#">
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.cfml.path_manipulation
Abstract
Permitir que a entrada do usuário controle os caminhos usados nas operações do sistema de arquivos pode deixar que um invasor substitua arbitrariamente os arquivos no sistema.
Explanation
Exemplo 1: O exemplo a seguir exclui arquivos de forma insegura.


final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final path = headers.value('path');
File(path!).delete();
}


No Example 1, não há validação de headers.value('path') antes de executar funções de exclusão em arquivos.
desc.dataflow.dart.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de uma solicitação HTTP para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "../../tomcat/conf/server.xml", que faz com que o aplicativo exclua um dos seus próprios arquivos de configuração.


rName := "/usr/local/apfr/reports/" + req.FormValue("fName")

rFile, err := os.OpenFile(rName, os.O_RDWR|os.O_CREATE, 0755)

defer os.Remove(rName);
defer rFile.Close()
...

Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para determinar qual arquivo deve ser aberto e ecoado de volta para o usuário. Se o programa for executado com privilégios adequados, e usuários mal-intencionados puderem alterar o arquivo de configuração, eles poderão usar esse programa para ler qualquer arquivo no sistema que termine com a extensão .txt.


...
config := ReadConfigFile()

filename := config.fName + ".txt";
data, err := ioutil.ReadFile(filename)

...

fmt.Println(string(data))
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.golang.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de uma solicitação HTTP para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "../../tomcat/conf/server.xml", que faz com que o aplicativo exclua um dos seus próprios arquivos de configuração.


String rName = request.getParameter("reportName");
File rFile = new File("/usr/local/apfr/reports/" + rName);
...
rFile.delete();
Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para determinar qual arquivo deve ser aberto e ecoado de volta para o usuário. Se o programa for executado com privilégios adequados, e usuários mal-intencionados puderem alterar o arquivo de configuração, eles poderão usar esse programa para ler qualquer arquivo no sistema que termine com a extensão .txt.


fis = new FileInputStream(cfg.getProperty("sub")+".txt");
amt = fis.read(arr);
out.println(arr);


Algumas pessoas acham que, no ambiente móvel, vulnerabilidades clássicas, como a manipulação de caminhos, não fazem sentido — por que o usuário atacaria a si mesmo? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 3: O código a seguir adapta o Example 1 à plataforma Android.


...
String rName = this.getIntent().getExtras().getString("reportName");
File rFile = getBaseContext().getFileStreamPath(rName);
...
rFile.delete();
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[2] FIO00-J. Do not operate on files in shared directories CERT
desc.dataflow.java.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de uma solicitação HTTP para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "../../tomcat/conf/server.xml", que faz com que o aplicativo exclua um dos seus próprios arquivos de configuração.


...
var reportNameParam = "reportName=";
var reportIndex = document.indexOf(reportNameParam);
if (reportIndex < 0) return;
var rName = document.URL.substring(reportIndex+reportNameParam.length);
window.requestFileSystem(window.TEMPORARY, 1024*1024, function(fs) {
fs.root.getFile('/usr/local/apfr/reports/' + rName, {create: false}, function(fileEntry) {
fileEntry.remove(function() {
console.log('File removed.');
}, errorHandler);

}, errorHandler);
}, errorHandler);
Exemplo 2: Este código usa a entrada do armazenamento local para determinar qual arquivo abrir e ecoar de volta ao usuário. Se os usuários mal-intencionados puderem alterar o conteúdo do armazenamento local, eles poderão usar o programa para ler qualquer arquivo no sistema que termine com a extensão .txt.


...
var filename = localStorage.sub + '.txt';
function oninit(fs) {
fs.root.getFile(filename, {}, function(fileEntry) {
fileEntry.file(function(file) {
var reader = new FileReader();
reader.onloadend = function(e) {
var txtArea = document.createElement('textarea');
txtArea.value = this.result;
document.body.appendChild(txtArea);
};
reader.readAsText(file);
}, errorHandler);
}, errorHandler);
}

window.requestFileSystem(window.TEMPORARY, 1024*1024, oninit, errorHandler);
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.javascript.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de uma solicitação HTTP para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "../../tomcat/conf/server.xml", que faz com que o aplicativo exclua um dos seus próprios arquivos de configuração.


val rName: String = request.getParameter("reportName")
val rFile = File("/usr/local/apfr/reports/$rName")
...
rFile.delete()
Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para determinar qual arquivo deve ser aberto e ecoado de volta para o usuário. Se o programa for executado com privilégios adequados, e usuários mal-intencionados puderem alterar o arquivo de configuração, eles poderão usar esse programa para ler qualquer arquivo no sistema que termine com a extensão .txt.


fis = FileInputStream(cfg.getProperty("sub").toString() + ".txt")
amt = fis.read(arr)
out.println(arr)


Algumas pessoas acham que, no ambiente móvel, vulnerabilidades clássicas, como a manipulação de caminhos, não fazem sentido — por que o usuário atacaria a si mesmo? No entanto, lembre-se de que a essência das plataformas móveis são aplicativos baixados de várias fontes e executados lado a lado no mesmo dispositivo. A probabilidade de execução de um malware junto com um aplicativo de banco é alta, o que exige a expansão da superfície de ataque de aplicativos móveis de forma a incluir comunicações entre processos.

Exemplo 3: O código a seguir adapta o Example 1 à plataforma Android.


...
val rName: String = getIntent().getExtras().getString("reportName")
val rFile: File = getBaseContext().getFileStreamPath(rName)
...
rFile.delete()
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[2] FIO00-J. Do not operate on files in shared directories CERT
desc.dataflow.kotlin.path_manipulation
Abstract
Os invasores podem controlar o argumento de caminho do sistema de arquivos, o que permite que eles acessem ou modifiquem arquivos que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: Este código usa a entrada do usuário para criar um caminho de arquivo. O programador não considerou a possibilidade de que um invasor poderia fornecer um nome de arquivo diferente que poderia fazer com que o aplicativo excluísse um arquivo não intencional.


- (NSData*) testFileManager {

NSString *rootfolder = @"/Documents/";
NSString *filePath = [rootfolder stringByAppendingString:[fileName text]];

NSFileManager *fm = [NSFileManager defaultManager];
return [fm contentsAtPath:filePath];
}
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.objc.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de uma solicitação HTTP para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "../../tomcat/conf/server.xml", que faz com que o aplicativo exclua um dos seus próprios arquivos de configuração.


$rName = $_GET['reportName'];
$rFile = fopen("/usr/local/apfr/reports/" . rName,"a+");
...
unlink($rFile);
Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para determinar qual arquivo deve ser aberto e ecoado de volta para o usuário. Se o programa for executado com privilégios adequados, e usuários mal-intencionados puderem alterar o arquivo de configuração, eles poderão usar esse programa para ler qualquer arquivo no sistema que termine com a extensão .txt.


...
$filename = $CONFIG_TXT['sub'] . ".txt";
$handle = fopen($filename,"r");
$amt = fread($handle, filesize($filename));
echo $amt;
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.php.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de uma solicitação HTTP para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "../../tomcat/conf/server.xml", que faz com que o aplicativo exclua um dos seus próprios arquivos de configuração.


rName = req.field('reportName')
rFile = os.open("/usr/local/apfr/reports/" + rName)
...
os.unlink(rFile);
Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para determinar qual arquivo deve ser aberto e ecoado de volta para o usuário. Se o programa for executado com privilégios adequados, e usuários mal-intencionados puderem alterar o arquivo de configuração, eles poderão usar esse programa para ler qualquer arquivo no sistema que termine com a extensão .txt.


...
filename = CONFIG_TXT['sub'] + ".txt";
handle = os.open(filename)
print handle
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.python.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de uma solicitação HTTP para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "../../tomcat/conf/server.xml", que faz com que o aplicativo exclua um dos seus próprios arquivos de configuração.


rName = req['reportName']
File.delete("/usr/local/apfr/reports/#{rName}")
Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para determinar qual arquivo deve ser aberto e ecoado de volta para o usuário. Se o programa for executado com privilégios adequados, e usuários mal-intencionados puderem alterar o arquivo de configuração, eles poderão usar esse programa para ler qualquer arquivo no sistema que termine com a extensão .txt.


...
fis = File.new("#{cfg.getProperty("sub")}.txt")
amt = fis.read
puts amt
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.ruby.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de uma solicitação HTTP para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "../../tomcat/conf/server.xml", que faz com que o aplicativo exclua um dos seus próprios arquivos de configuração.


def readFile(reportName: String) = Action { request =>
val rFile = new File("/usr/local/apfr/reports/" + reportName)
...
rFile.delete()
}
Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para determinar qual arquivo deve ser aberto e ecoado de volta para o usuário. Se o programa for executado com privilégios adequados, e usuários mal-intencionados puderem alterar o arquivo de configuração, eles poderão usar esse programa para ler qualquer arquivo no sistema que termine com a extensão .txt.


val fis = new FileInputStream(cfg.getProperty("sub")+".txt")
val amt = fis.read(arr)
out.println(arr)
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[2] FIO00-J. Do not operate on files in shared directories CERT
desc.dataflow.scala.path_manipulation
Abstract
Os invasores podem controlar o argumento de caminho do sistema de arquivos, o que permite que eles acessem ou modifiquem arquivos que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: Este código usa a entrada do usuário para criar um caminho de arquivo. O programador não considerou a possibilidade de que um invasor poderia fornecer um nome de arquivo diferente que poderia fazer com que o aplicativo excluísse um arquivo não intencional.


func testFileManager() -> NSData {
let filePath : String = "/Documents/\(fileName.text)"
let fm : NSFileManager = NSFileManager.defaultManager()
return fm.contentsAtPath(filePath)
}
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.swift.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Erros de manipulação de caminho ocorrem quando as duas condições a seguir são atendidas:

1. Um invasor pode especificar um caminho usado em uma operação no sistema de arquivos.

2. Ao especificar o recurso, o invasor adquire uma capacidade que, de outra forma, não seria permitida.

Por exemplo, o programa pode dar ao invasor a capacidade de substituir o arquivo especificado ou executá-lo com uma configuração controlada pelo invasor.
Exemplo 1: O código a seguir usa a entrada de uma solicitação HTTP para criar um nome de arquivo. O programador não levou em consideração a possibilidade de que um invasor pudesse fornecer um nome de arquivo, como "..\conf\server.xml", que faz com que o aplicativo exclua um dos seus próprios arquivos de configuração.


Dim rName As String
Dim fso As New FileSystemObject
Dim rFile as File
Set rName = Request.Form("reportName")
Set rFile = fso.GetFile("C:\reports\" & rName)
...
fso.DeleteFile("C:\reports\" & rName)
...
Exemplo 2: O código a seguir usa a entrada de um arquivo de configuração para determinar qual arquivo deve ser aberto e ecoado de volta para o usuário. Se o programa for executado com privilégios adequados, e usuários mal-intencionados puderem alterar o arquivo de configuração, eles poderão usar esse programa para ler qualquer arquivo no sistema que termine com a extensão .txt.


Dim fileName As String
Dim tsContent As String
Dim ts As TextStream
Dim fso As New FileSystemObject

fileName = GetPrivateProfileString("MyApp", "sub", _
"", value, Len(value), _
App.Path & "\" & "Config.ini")
...
Set ts = fso.OpenTextFile(fileName,1)
tsContent = ts.ReadAll
Response.Write tsContent
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
desc.dataflow.vb.path_manipulation
Abstract
Permitir que a entrada do usuário controle caminhos usados em operações de sistema de arquivos pode permitir que um invasor acesse ou modifique recursos do sistema que, de outra forma, estariam protegidos.
Explanation
Path.Combine toma vários caminhos de arquivos como argumentos. Ele os concatena para obter um caminho completo, que normalmente é seguido por uma chamada para read() ou write() para esse arquivo. A documentação descreve vários cenários diferentes com base no fato de o primeiro ou os parâmetros restantes serem caminhos absolutos. Dado um caminho absoluto para o segundo parâmetro ou os restantes, Path.Combine() retornará esse caminho absoluto. Os parâmetros anteriores serão ignorados. As implicações aqui são significativas para aplicativos que possuem código semelhante ao exemplo a seguir.


Exemplo 1: O código a seguir carrega inseguramente um arquivo com elementos de caminho controlados pelo usuário:


// Called with user-controlled data
public static bytes[] getFile(String filename)
{
String imageDir = "\\FILESHARE\images\";
filepath = Path.Combine(imageDir, filename);
return File.ReadAllBytes(filepath);
}


Ao fornecer um caminho absoluto (por exemplo, C:\\inetpub\wwwroot\web.config), um invasor pode controlar qual arquivo é retornado pelo aplicativo.
References
[1] Anna Pobletts Path.Combine Security Issues in ASP.NET Applications
[2] Microsoft Path.Combine Method
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 22, CWE ID 73
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [10] CWE ID 022
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [12] CWE ID 022
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [8] CWE ID 022
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [8] CWE ID 022
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [8] CWE ID 022
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[16] Standards Mapping - FIPS200 SI
[17] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[18] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[19] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[20] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[21] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[22] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[23] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[24] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[25] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[26] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[27] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[28] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.3.1 File Execution Requirements (L1 L2 L3), 12.3.2 File Execution Requirements (L1 L2 L3)
[29] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[30] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[31] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[41] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[42] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[43] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 426
[44] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 022
[45] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 022
[46] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I, APSC-DV-002960 CAT II
[67] Standards Mapping - Web Application Security Consortium Version 2.00 Path Traversal (WASC-33)
[68] Standards Mapping - Web Application Security Consortium 24 + 2 Path Traversal
desc.dataflow.dotnet.path_manipulation_base_path_overwriting