45 itens encontrados
Vulnerabilidades
Abstract
Um invasor pode ser capaz de criar caminhos de fluxo de controle inesperados através do aplicativo, possivelmente se esquivando de verificações de segurança.
Explanation
Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Exemplo: Um motivo comum pelo qual os programadores utilizam a tecnologia de reflexão é para implementar seus próprios expedidores de comandos. O seguinte exemplo mostra um expedidor de comandos que não usa reflexão:


var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var ctl:String = String(params["ctl"]);
var ao:Worker;
if (ctl == "Add) {
ao = new AddCommand();
} else if (ctl == "Modify") {
ao = new ModifyCommand();
} else {
throw new UnknownActionError();
}
ao.doAction(params);


Um programador pode refatorar esse código para usar a reflexão, da seguinte maneira:


var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var ctl:String = String(params["ctl"]);
var ao:Worker;
var cmdClass:Class = getDefinitionByName(ctl + "Command") as Class;
ao = new cmdClass();
ao.doAction(params);


Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite que um invasor instancie qualquer objeto que implementa a interface Worker. Se o expedidor de comandos ainda for responsável pelo controle de acesso, sempre que os programadores criarem uma nova classe que implementa a interface Worker, eles deverão se lembrar de modificar o código de controle de acesso do expedidor. Se o código de controle de acesso não for modificado, algumas classes Worker não terão controle de acesso.

Uma maneira de resolver esse problema de controle de acesso é tornar o objeto Worker responsável pela execução da verificação de controle de acesso. Veja a seguir um exemplo do código novamente refatorado:


var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var ctl:String = String(params["ctl"]);
var ao:Worker;
var cmdClass:Class = getDefinitionByName(ctl + "Command") as Class;
ao = new cmdClass();
ao.checkAccessControl(params);
ao.doAction(params);


Embora seja uma melhoria, isso incentiva uma abordagem descentralizada ao controle de acesso, facilitando erros de controle de acesso por parte dos programadores.
desc.dataflow.actionscript.unsafe_reflection
Abstract
Permitir que entradas não validadas determinem o método de retorno de chamada de um objeto Continuation pode permitir que invasores criem caminhos de fluxo de controle inesperados através do aplicativo, potencialmente ignorando as verificações de segurança.
Explanation
Se um invasor puder fornecer valores que o aplicativo usará para determinar qual classe instanciar ou qual método invocar, o invasor poderá criar caminhos de fluxo de controle inesperados por meio do aplicativo. Isso pode permitir que o invasor ignore as verificações de autenticação ou controle de acesso ou, possivelmente, faça com que o aplicativo se comporte de maneira inesperada.

Exemplo: O método de ação a seguir inicia uma solicitação assíncrona para um serviço da Web externo e define a propriedade continuationMethod, que determina o nome do método a ser chamado ao receber uma resposta.

public Object startRequest() {
Continuation con = new Continuation(40);

Map<String,String> params = ApexPages.currentPage().getParameters();

if (params.containsKey('contMethod')) {
con.continuationMethod = params.get('contMethod');
} else {
con.continuationMethod = 'processResponse';
}

HttpRequest req = new HttpRequest();
req.setMethod('GET');
req.setEndpoint(LONG_RUNNING_SERVICE_URL);
this.requestLabel = con.addHttpRequest(req);
return con;
}

Essa implementação permite que a propriedade continuationMethod seja definida por parâmetros de solicitação de tempo de execução, o que permite que invasores chamem qualquer função que corresponda ao nome.
desc.dataflow.apex.unsafe_reflection
Abstract
Um invasor pode ser capaz de criar caminhos de fluxo de controle inesperados através do aplicativo, possivelmente se esquivando de verificações de segurança.
Explanation
Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Exemplo: Os programadores costumam usar o recurso de reflexão para implementar dispatchers de comandos. O exemplo a seguir mostra um dispatcher de comandos que não usa reflexão:


...
Dim ctl As String
Dim ao As New Worker()
ctl = Request.Form("ctl")
If (String.Compare(ctl,"Add") = 0) Then
ao.DoAddCommand(Request)
Else If (String.Compare(ctl,"Modify") = 0) Then
ao.DoModifyCommand(Request)
Else
App.EventLog("No Action Found", 4)
End If
...


Um programador pode refatorar esse código para usar a reflexão, da seguinte maneira:


...
Dim ctl As String
Dim ao As New Worker()
ctl = Request.Form("ctl")
CallByName(ao, ctl, vbMethod, Request)
...


Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite que um invasor chame qualquer método implementado pelo objeto Worker. Se o dispatcher de comandos for responsável pelo controle de acesso, sempre que os programadores criarem um novo método na classe Worker, eles deverão modificar a lógica de controle de acesso do dispatcher. Se essa lógica de controle de acesso se tornar obsoleta, alguns métodos Worker não terão controle de acesso.

Uma maneira de resolver esse problema de controle de acesso é tornar o objeto Worker responsável pela execução da verificação de controle de acesso. Veja a seguir um exemplo do código novamente refatorado:


...
Dim ctl As String
Dim ao As New Worker()
ctl = Request.Form("ctl")
If (ao.checkAccessControl(ctl,Request) = True) Then
CallByName(ao, "Do" & ctl & "Command", vbMethod, Request)
End If
...


Embora seja uma melhoria, isso incentiva uma abordagem descentralizada ao controle de acesso, facilitando erros de controle de acesso por parte dos programadores.
desc.dataflow.dotnet.unsafe_reflection
Abstract
Um invasor pode ser capaz de criar caminhos de fluxo de controle inesperados através do aplicativo, possivelmente se esquivando de verificações de segurança.
Explanation
Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada.

Essa situação torna-se um cenário apocalíptico quando o invasor pode carregar arquivos para um local que é exibido no caminho da biblioteca ou no caminho do aplicativo. Em qualquer uma dessas condições, o invasor pode usar o recurso de reflexão para introduzir no aplicativo um novo comportamento presumivelmente mal-intencionado.
Exemplo: Um motivo comum pelo qual os programadores utilizam a API de reflexão é para implementar seus próprios dispatchers de comandos. O exemplo a seguir mostra um dispatcher de comandos JNI que usa a reflexão para executar um método Java identificado por um valor lido a partir de uma solicitação CGI. Essa implementação permite que um invasor chame qualquer função definida em clazz.


char* ctl = getenv("ctl");
...
jmethodID mid = GetMethodID(clazz, ctl, sig);
status = CallIntMethod(env, clazz, mid, JAVA_ARGS);
...
desc.dataflow.cpp.unsafe_reflection
Abstract
Um invasor pode ser capaz de criar caminhos de fluxo de controle inesperados através do aplicativo, possivelmente se esquivando de verificações de segurança.
Explanation
Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Essa situação se transformará em um cenário apocalíptico se o invasor puder carregar arquivos em um local exibido no caminho de classe do aplicativo ou se puder adicionar novas entradas ao caminho de classe do aplicativo. Em qualquer uma dessas condições, o invasor pode usar o recurso de reflexão para introduzir no aplicativo um novo comportamento presumivelmente mal-intencionado.
Exemplo: Um motivo comum pelo qual os programadores utilizam a API de reflexão é para implementar seus próprios dispatchers de comandos. O seguinte exemplo mostra um expedidor de comandos que não usa reflexão:


String ctl = request.getParameter("ctl");
Worker ao = null;
if (ctl.equals("Add")) {
ao = new AddCommand();
} else if (ctl.equals("Modify")) {
ao = new ModifyCommand();
} else {
throw new UnknownActionError();
}
ao.doAction(request);


Um programador pode refatorar esse código para usar a reflexão, da seguinte maneira:


String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.doAction(request);


Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite que um invasor instancie qualquer objeto que implementa a interface Worker. Se o expedidor de comandos ainda for responsável pelo controle de acesso, sempre que os programadores criarem uma nova classe que implementa a interface Worker, eles deverão se lembrar de modificar o código de controle de acesso do expedidor. Se o código de controle de acesso não for modificado, algumas classes Worker não terão controle de acesso.

Uma maneira de resolver esse problema de controle de acesso é tornar o objeto Worker responsável pela execução da verificação de controle de acesso. Veja a seguir um exemplo do código novamente refatorado:


String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.checkAccessControl(request);
ao.doAction(request);


Embora seja uma melhoria, isso incentiva uma abordagem descentralizada ao controle de acesso, facilitando erros de controle de acesso por parte dos programadores.

Esse código também destaca outro problema de segurança com o uso da reflexão para construir um expedidor de comandos. Um invasor pode invocar o construtor padrão para qualquer tipo de objeto. Na verdade, o invasor nem mesmo é impedido de acessar objetos que implementam a interface Worker; o construtor padrão para qualquer objeto no sistema pode ser invocado. Se o objeto não implementar a interface Worker, um ClassCastException será lançado antes da atribuição a ao, mas, se o construtor realizar operações que funcionarem a favor do invasor, os danos já terão sido feitos. Embora esse cenário seja relativamente favorável em aplicativos simples, em aplicativos maiores, nos quais a complexidade cresce exponencialmente, não é absurdo considerar que um invasor possa encontrar um construtor a ser otimizado como parte de um ataque.

As verificações de acesso também podem ficar comprometidas mais abaixo na cadeia a execução do código quando certas APIs Java que realizam tarefas usando a verificação de carregadores de classe do chamador imediato são invocadas em objetos não confiáveis retornados por chamadas de reflexão. Essas APIs Java ignoram a verificação de SecurityManager que garante que todos os chamadores na cadeia de execução tenham as permissões de segurança necessárias. É necessário ter cautela para garantir que essas APIs não sejam invocadas nos objetos não confiáveis retornados pela reflexão, pois elas podem ignorar verificações de acesso de segurança e deixar o sistema vulnerável a ataques remotos. Para obter mais informações sobre essas APIs Java, consulte a Orientação 9 das orientações para codificação segura da linguagem de programação Java.
References
[1] Secure Coding Guidelines for the Java Programming Language, Version 4.0
desc.dataflow.java.unsafe_reflection
Abstract
Os invasores podem controlar um argumento para o método performSelector, o que pode permitir que eles criem caminhos inesperados de controle de fluxo por meio do aplicativo, potencialmente ignorando as verificações de segurança.
Explanation
Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada.

Exemplo 1: Uma razão comum pela qual os programadores usam a API do seletor é implementar o próprio despachante de comando deles. O exemplo a seguir mostra um dispatcher de comando Objective-C, que usa a reflexão para executar um método arbitrário identificado por um valor lido a partir de uma solicitação URL de esquema personalizado. Essa implementação permite a um invasor chamar qualquer função mediante a correspondência da assinatura do método definido na classe UIApplicationDelegate.


...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url
sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {

NSString *query = [url query];
NSString *pathExt = [url pathExtension];
[self performSelector:NSSelectorFromString(pathExt) withObject:query];
...
desc.dataflow.objc.unsafe_reflection
Abstract
Um invasor pode ser capaz de criar caminhos de fluxo de controle inesperados através do aplicativo, possivelmente se esquivando de verificações de segurança.
Explanation
Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Essa situação se transformará em um cenário apocalíptico se o invasor puder carregar arquivos em um local exibido no caminho de classe do aplicativo ou se puder adicionar novas entradas ao caminho de classe do aplicativo. Em qualquer uma dessas condições, o invasor pode usar o recurso de reflexão para introduzir no aplicativo um novo comportamento presumivelmente mal-intencionado.
Exemplo: Um motivo comum pelo qual os programadores utilizam a API de reflexão é para implementar seus próprios dispatchers de comandos. O seguinte exemplo mostra um expedidor de comandos que não usa reflexão:


$ctl = $_GET["ctl"];
$ao = null;
if (ctl->equals("Add")) {
$ao = new AddCommand();
} else if ($ctl.equals("Modify")) {
$ao = new ModifyCommand();
} else {
throw new UnknownActionError();
}
$ao->doAction(request);


Um programador pode refatorar esse código para usar a reflexão, da seguinte maneira:


$ctl = $_GET["ctl"];
$args = $_GET["args"];
$cmdClass = new ReflectionClass(ctl . "Command");
$ao = $cmdClass->newInstance($args);
$ao->doAction(request);


Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite que um invasor instancie qualquer objeto que implementa a interface Worker. Se o expedidor de comandos ainda for responsável pelo controle de acesso, sempre que os programadores criarem uma nova classe que implementa a interface Worker, eles deverão se lembrar de modificar o código de controle de acesso do expedidor. Se o código de controle de acesso não for modificado, algumas classes Worker não terão controle de acesso.

Uma maneira de resolver esse problema de controle de acesso é tornar o objeto Worker responsável pela execução da verificação de controle de acesso. Veja a seguir um exemplo do código novamente refatorado:


$ctl = $_GET["ctl"];
$args = $_GET["args"];
$cmdClass = new ReflectionClass(ctl . "Command");
$ao = $cmdClass->newInstance($args);
$ao->checkAccessControl(request);
ao->doAction(request);


Embora seja uma melhoria, isso incentiva uma abordagem descentralizada ao controle de acesso, facilitando erros de controle de acesso por parte dos programadores.

Esse código também destaca outro problema de segurança com o uso da reflexão para construir um expedidor de comandos. Um invasor pode invocar o construtor padrão para qualquer tipo de objeto. Na verdade, o invasor nem mesmo é impedido de acessar objetos que implementam a interface Worker; o construtor padrão para qualquer objeto no sistema pode ser invocado. Se o objeto não implementar a interface Worker, um ClassCastException será lançado antes da atribuição a $ao, mas, se o construtor realizar operações que funcionarem a favor do invasor, os danos já terão sido feitos. Embora esse cenário seja relativamente favorável em aplicativos simples, em aplicativos maiores, nos quais a complexidade cresce exponencialmente, não é absurdo considerar que um invasor possa encontrar um construtor a ser otimizado como parte de um ataque.
desc.dataflow.php.unsafe_reflection
Abstract
Um invasor pode ser capaz de criar caminhos de fluxo de controle inesperados através do aplicativo, possivelmente se esquivando de verificações de segurança.
Explanation
Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Essa situação se transformará em um cenário apocalíptico se o invasor puder carregar arquivos em um local exibido no caminho de classe do aplicativo ou se puder adicionar novas entradas ao caminho de classe do aplicativo. Em qualquer uma dessas condições, o invasor pode usar o recurso de reflexão para introduzir no aplicativo um novo comportamento presumivelmente mal-intencionado.
desc.dataflow.python.unsafe_reflection
Abstract
Um invasor pode ser capaz de criar caminhos de fluxo de controle inesperados através do aplicativo, possivelmente se esquivando de verificações de segurança.
Explanation
Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir ao invasor ignorar a autenticação, ignorar as verificações de controle de acesso ou, de outra maneira, fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Essa situação se tornará um cenário apocalíptico se o invasor puder carregar arquivos em um local exibido no caminho de carregamento do aplicativo ou adicionar novas entradas a esse caminho. Em qualquer uma dessas condições, o invasor pode usar o recurso de reflexão para introduzir no aplicativo um novo comportamento presumivelmente mal-intencionado.
Exemplo: Uma razão comum pela qual os programadores usam a reflexão é implementar o próprio despachante de comando. O seguinte exemplo mostra um expedidor de comandos que não usa reflexão:


ctl = req['ctl']
if ctl=='add'
addCommand(req)
elsif ctl=='modify'
modifyCommand(req)
else
raise UnknownCommandError.new
end


Um programador pode refatorar esse código para usar a reflexão, da seguinte maneira:


ctl = req['ctl']
ctl << "Command"
send(ctl)


Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite a um invasor executar qualquer método que termine com a palavra "Command". Caso o distribuidor de comando ainda seja responsável pelo controle de acesso, sempre que os programadores criarem um novo método que termine com "Command", eles deverão se lembrar de modificar o código de controle de acesso do despachante. Mesmo assim, a prática comum quando se tem vários métodos de nome semelhante pode ser criá-los dinamicamente ao usar define_method(), ou pode ser chamá-los ao substituir missing_method(). Fazer a auditoria e o rastreio desses métodos assim como de que maneira o código de controle é utilizado com eles é muito difícil e, ao considerar essa situação, ela também dependerá de quais outros códigos de biblioteca estão carregados; isso fará com que essa tarefa seja quase impossível de realizar corretamente.
desc.dataflow.ruby.unsafe_reflection
Abstract
Um invasor pode ser capaz de criar caminhos de fluxo de controle inesperados através do aplicativo, possivelmente se esquivando de verificações de segurança.
Explanation
Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Essa situação se transformará em um cenário apocalíptico se o invasor puder carregar arquivos em um local exibido no caminho de classe do aplicativo ou se puder adicionar novas entradas ao caminho de classe do aplicativo. Em qualquer uma dessas condições, o invasor pode usar o recurso de reflexão para introduzir no aplicativo um novo comportamento presumivelmente mal-intencionado.
Exemplo: Um motivo comum pelo qual os programadores utilizam a API de reflexão é para implementar seus próprios expedidores de comandos. O exemplo a seguir mostra um expedidor de comandos que usa reflexão:


def exec(ctl: String) = Action { request =>
val cmdClass = Platform.getClassForName(ctl + "Command")
Worker ao = (Worker) cmdClass.newInstance()
ao.doAction(request)
...
}


Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite que um invasor instancie qualquer objeto que implementa a interface Worker. Se o expedidor de comandos ainda for responsável pelo controle de acesso, sempre que os programadores criarem uma nova classe que implementa a interface Worker, eles deverão se lembrar de modificar o código de controle de acesso do expedidor. Se o código de controle de acesso não for modificado, algumas classes Worker não terão controle de acesso.

Uma maneira de resolver esse problema de controle de acesso é tornar o objeto Worker responsável pela execução da verificação de controle de acesso. Veja a seguir um exemplo do código novamente refatorado:


def exec(ctl: String) = Action { request =>
val cmdClass = Platform.getClassForName(ctl + "Command")
Worker ao = (Worker) cmdClass.newInstance()
ao.checkAccessControl(request);
ao.doAction(request)
...
}


Embora seja uma melhoria, isso incentiva uma abordagem descentralizada ao controle de acesso, facilitando erros de controle de acesso por parte dos programadores.

Esse código também destaca outro problema de segurança com o uso da reflexão para construir um expedidor de comandos. Um invasor pode invocar o construtor padrão para qualquer tipo de objeto. Na verdade, o invasor nem mesmo é impedido de acessar objetos que implementam a interface Worker; o construtor padrão para qualquer objeto no sistema pode ser invocado. Se o objeto não implementar a interface Worker, um ClassCastException será lançado antes da atribuição a ao, mas, se o construtor realizar operações que funcionarem a favor do invasor, os danos já terão sido feitos. Embora esse cenário seja relativamente favorável em aplicativos simples, em aplicativos maiores, nos quais a complexidade cresce exponencialmente, não é absurdo considerar que um invasor possa encontrar um construtor a ser otimizado como parte de um ataque.

As verificações de acesso também podem ficar comprometidas mais abaixo na cadeia a execução do código quando certas APIs Java que realizam tarefas usando a verificação de carregadores de classe do chamador imediato são invocadas em objetos não confiáveis retornados por chamadas de reflexão.Essas APIs Java ignoram a verificação de SecurityManager que garante que todos os chamadores na cadeia de execução tenham as permissões de segurança necessárias.É necessário ter cautela para garantir que essas APIs não sejam invocadas nos objetos não confiáveis retornados pela reflexão, pois elas podem ignorar verificações de acesso de segurança e deixar o sistema vulnerável a ataques remotos.Para obter mais informações sobre essas APIs Java, consulte a Orientação 9 das orientações para codificação segura da linguagem de programação Java.
References
[1] Secure Coding Guidelines for the Java Programming Language, Version 4.0
desc.dataflow.scala.unsafe_reflection
Abstract
Os invasores podem controlar um argumento para o método performSelector, o que pode permitir que eles criem caminhos inesperados de controle de fluxo por meio do aplicativo, potencialmente ignorando as verificações de segurança.
Explanation
Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada.

Exemplo 1: Uma razão comum pela qual os programadores usam a API do seletor é implementar o próprio despachante de comando deles. O exemplo a seguir mostra um dispatcher de comando Swift que usa a reflexão para executar um método arbitrário identificado por um valor lido de uma solicitação de esquema de URL personalizada. Essa implementação permite a um invasor chamar qualquer função mediante a correspondência da assinatura do método definido na classe UIApplicationDelegate.


func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let query = url.query
let pathExt = url.pathExtension
let selector = NSSelectorFromString(pathExt!)
performSelector(selector, withObject:query)
...
}
desc.dataflow.swift.unsafe_reflection
Abstract
Um invasor pode ser capaz de criar caminhos de fluxo de controle inesperados através do aplicativo, possivelmente se esquivando de verificações de segurança.
Explanation
Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Exemplo: Um motivo comum pelo qual os programadores utilizam o CallByName é para implementar o próprio dispatcher de comandos. O seguinte exemplo mostra um dispatcher de comandos que não utiliza a função CallByName:


...
Dim ctl As String
Dim ao As new Worker
ctl = Request.Form("ctl")
If String.Compare(ctl,"Add") = 0 Then
ao.DoAddCommand Request
Else If String.Compare(ctl,"Modify") = 0 Then
ao.DoModifyCommand Request
Else
App.EventLog "No Action Found", 4
End If
...



Um programador pode refatorar esse código para usar a reflexão, da seguinte maneira:


...
Dim ctl As String
Dim ao As Worker
ctl = Request.Form("ctl")
CallByName ao, ctl, vbMethod, Request
...




Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite que um invasor chame qualquer método implementado pelo objeto Worker. Se o dispatcher de comandos ainda for responsável pelo controle de acesso, sempre que os programadores criarem um novo método na classe Worker, eles deverão se lembrar de modificar o código de controle de acesso do dispatcher. Se eles não conseguirem modificar o código de controle de acesso, alguns métodos Worker não terão nenhum controle de acesso.

Uma maneira de resolver esse problema de controle de acesso é tornar o objeto Worker responsável pela execução da verificação de controle de acesso. Veja a seguir um exemplo do código novamente refatorado:


...
Dim ctl As String
Dim ao As Worker
ctl = Request.Form("ctl")
If ao.checkAccessControl(ctl,Request) = True Then
CallByName ao, "Do" & ctl & "Command", vbMethod, Request
End If
...



Embora seja uma melhoria, isso incentiva uma abordagem descentralizada ao controle de acesso, facilitando erros de controle de acesso por parte dos programadores.
desc.dataflow.vb.unsafe_reflection
Abstract
O uso de analisadores XML configurados de forma a não impedir nem limitar a resolução de entidades externas pode expor o analisador a um ataque de Entidades Externas XML
Explanation
Ataques de Entidades Externas XML tiram proveito de um recurso XML para criar documentos dinamicamente na ocasião do processamento. Uma entidade XML permite incluir dados dinamicamente a partir de um determinado recurso. Entidades externas permitem que um documento XML inclua dados de um URI externo. A menos que configuradas para fazerem o contrário, entidades externas forçam o analisador XML a acessar o recurso especificado pelo URI, por exemplo, um arquivo na máquina local ou em um sistema remoto. Esse comportamento expõe o aplicativo a ataques de XXE (Entidades Externas XML), que podem ser usados para realizar a negação de serviço do sistema local, obter acesso não autorizado a arquivos na máquina local, fazer a varredura de máquinas remotas e realizar a negação de serviço de sistemas remotos.

O seguinte documento XML mostra um exemplo de ataque de XXE.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/winnt/win.ini" >]><foo>&xxe;</foo>


Esse exemplo poderá revelar o conteúdo do arquivo do sistema C:\winnt\win.ini se o analisador XML tentar substituir a entidade pelo conteúdo desse arquivo.
References
[1] XML Denial of Service Attacks and Defenses MSDN Magazine
[2] XML External Entity (XXE) Processing OWASP
[3] Testing for XML Injection OWASP
[4] XML External Entities The Web Application Security Consortium
desc.controlflow.dotnet.xml_external_entity_injection
Abstract
O método identificado permite referências a entidades externas. Essa chamada pode permitir que um invasor injete uma entidade externa XML no documento XML para revelar o conteúdo de arquivos ou recursos de rede internos.
Explanation
Uma injeção de Entidade Externa XML (XXE) ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um elemento <ENTITY> da DTD (Definição de Tipo de Documento) em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir referências a entidades aninhadas e fazer com que um analisador XML consuma quantidades cada vez maiores de recursos da CPU. Em casos mais perniciosos da injeção de entidades externas XML, um invasor pode ser capaz de adicionar elementos XML que expõem o conteúdo de recursos do sistema de arquivos local ou que revelam a existência de recursos de rede internos.

Exemplo 1: veja a seguir um código Objective-C que é vulnerável a ataques de XXE:


- (void) parseSomeXML: (NSString *) rawXml {

BOOL success;
NSData *rawXmlConvToData = [rawXml dataUsingEncoding:NSUTF8StringEncoding];
NSXMLParser *myParser = [[NSXMLParser alloc] initWithData:rawXmlConvToData];
[myParser setShouldResolveExternalEntities:YES];
[myParser setDelegate:self];
}


Suponha que um invasor seja capaz de controlar o conteúdo de rawXml de tal forma que o XML tenha a seguinte aparência:


<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>


Quando o XML for avaliado pelo servidor, o elemento <foo> incluirá o conteúdo do arquivo boot.ini.
desc.semantic.cpp.xml_external_entity_injection
Abstract
O uso de analisadores XML configurados de forma a não impedir nem limitar a resolução de entidades externas pode expor o analisador a um ataque de Entidades Externas XML
Explanation
Ataques de Entidades Externas XML tiram proveito de um recurso XML para criar documentos dinamicamente na ocasião do processamento. Uma entidade XML permite a inclusão de dados dinamicamente a partir de um determinado recurso. Entidades externas permitem que um documento XML inclua dados de um URI externo. A menos que configuradas para fazerem o contrário, entidades externas forçam o analisador XML a acessar o recurso especificado pelo URI, por exemplo, um arquivo na máquina local ou em um sistema remoto. Esse comportamento expõe o aplicativo a ataques de XXE (Entidades Externas XML), que podem ser usados para realizar a negação de serviço do sistema local, obter acesso não autorizado a arquivos na máquina local, fazer a varredura de máquinas remotas e realizar a negação de serviço de sistemas remotos.

O seguinte documento XML mostra um exemplo de ataque de XXE.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>


Esse exemplo poderá travar o servidor (em um sistema UNIX), se o analisador de XML tentar substituir a entidade pelo conteúdo do arquivo /dev/random.
References
[1] XML External Entity (XXE) Processing OWASP
[2] Testing for XML Injection OWASP
[3] XML External Entities The Web Application Security Consortium
[4] IDS17-J. Prevent XML External Entity Attacks CERT
[5] DOS-1: Beware of activities that may use disproportionate resources Oracle
[6] INJECT-5: Restrict XML inclusion Oracle
desc.semantic.java.xxe_injection
Abstract
O método identificado permite referências a entidades externas. Essa chamada pode permitir que um invasor injete uma entidade externa XML no documento XML para revelar o conteúdo de arquivos ou recursos de rede internos.
Explanation
Uma injeção de Entidade Externa XML (XXE) ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um elemento <ENTITY> da DTD (Definição de Tipo de Documento) em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir referências a entidades aninhadas e fazer com que um analisador XML consuma quantidades cada vez maiores de recursos da CPU. Em casos mais perniciosos da injeção de entidades externas XML, um invasor pode ser capaz de adicionar elementos XML que expõem o conteúdo de recursos do sistema de arquivos local ou que revelam a existência de recursos de rede internos.

Exemplo 1:estes são alguns códigos vulneráveis a ataques XXE:


- (void) parseSomeXML: (NSString *) rawXml {

BOOL success;
NSData *rawXmlConvToData = [rawXml dataUsingEncoding:NSUTF8StringEncoding];
NSXMLParser *myParser = [[NSXMLParser alloc] initWithData:rawXmlConvToData];
[myParser setShouldResolveExternalEntities:YES];
[myParser setDelegate:self];
}


Suponha que um invasor seja capaz de controlar o conteúdo de rawXml de tal forma que o XML tenha a seguinte aparência:


<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>


Quando o XML for avaliado pelo servidor, o elemento <foo> incluirá o conteúdo do arquivo boot.ini.
desc.semantic.objc.xml_external_entity_injection
Abstract
Processar um documento XML não validado pode permitir que um invasor altere a estrutura e o conteúdo do XML, escaneie a porta do servidor host ou escaneie o host da rede interna, inclua arquivos arbitrários do sistema de arquivos, ou cause um ataque de negação de serviço do aplicativo.
Explanation
Uma injeção de Entidade Externa XML (XXE) ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No caso mais benigno, um invasor pode ser capaz de inserir referências de entidade aninhada e fazer com que um analisador XML consuma cada vez mais quantidades de recursos da CPU. Em casos mais nefastos de injeção de XXE, um invasor pode ser capaz de adicionar elementos XML que expõem o conteúdo de recursos do sistema de arquivos local, revelam a existência de recursos de rede interna ou exponha conteúdo back-end em si.

Exemplo 1: Estes são alguns códigos vulneráveis a ataques XXE:

Pressuponha que um invasor possa controlar o XML de entrada para o seguinte código:


...
<?php
$goodXML = $_GET["key"];
$doc = simplexml_load_string($goodXml);
echo $doc->testing;
?>
...


Agora suponha que o XML a seguir é passado pelo invasor para o código no Example 2:



<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>



Quando o XML é processado, o conteúdo do elemento <foo> é preenchido com o conteúdo do arquivo boot.ini do sistema. O invasor pode usar elementos XML que são devolvidos ao cliente para roubar dados ou obter informações sobre a existência de recursos de rede.
desc.dataflow.php.xml_external_entity_injection
Abstract
O uso de processadores de XML que não impedem nem limitam a resolução de entidades externas pode expor o aplicativo a ataques de Entidades Externas XML.
Explanation
Os ataques de Entidades Externas XML se beneficiam de um recurso XML para criar documentos dinamicamente em tempo de execução. Uma entidade XML permite a inclusão de dados dinamicamente de um recurso específico. Entidades externas permitem que um documento XML inclua dados de um URI externo. A menos que configuradas para fazerem o contrário, entidades externas forçam o analisador XML a acessar o recurso especificado pelo URI, como um arquivo no computador local ou em um sistema remoto. Esse comportamento expõe o aplicativo a ataques de XXE (Entidades Externas XML), que os invasores podem usar para realizar a negação de serviço do sistema local, obter acesso não autorizado a arquivos na máquina local, fazer a varredura de computadores remotos e realizar a negação de serviço de sistemas remotos.


Exemplo 1: O seguinte documento XML mostra um exemplo de ataque de XXE.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>


Esse exemplo poderá travar o servidor (em um sistema UNIX), se o analisador de XML tentar substituir a entidade pelo conteúdo do arquivo /dev/random.
References
[1] XML vulnerabilities
[2] Announcing defusedxml, Fixes for XML Security Issues
[3] defusedxml
[4] defusedexpat
[5] XML External Entity (XXE) Processing OWASP
[6] Testing for XML Injection (OWASP-DV-008) OWASP
[7] XML External Entities The Web Application Security Consortium
desc.dataflow.python.xxe_injection
Abstract
O uso de analisadores XML configurados de forma a não impedir nem limitar a resolução de entidades externas pode expor o analisador a um ataque de Entidades Externas XML
Explanation
Ataques de Entidades Externas XML tiram proveito de um recurso XML para criar documentos dinamicamente na ocasião do processamento. Uma entidade XML permite a inclusão de dados dinamicamente a partir de um determinado recurso. Entidades externas permitem que um documento XML inclua dados de um URI externo. A menos que configuradas para fazerem o contrário, entidades externas forçam o analisador XML a acessar o recurso especificado pelo URI, por exemplo, um arquivo na máquina local ou em um sistema remoto. Esse comportamento expõe o aplicativo a ataques de XXE (Entidades Externas XML), que podem ser usados para realizar a negação de serviço do sistema local, obter acesso não autorizado a arquivos na máquina local, fazer a varredura de máquinas remotas e realizar a negação de serviço de sistemas remotos.

O seguinte documento XML mostra um exemplo de ataque de XXE.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>


O documento XML de exemplo lerá o conteúdo de /etc/passwd e o incluirá no documento.

Exemplo 1:O código a seguir usa um analisador XML não seguro para processar uma entrada não confiável a partir de uma solicitação HTTP.


def readFile() = Action { request =>
val xml = request.cookies.get("doc")
val doc = XMLLoader.loadString(xml)
...
}
References
[1] XML External Entity (XXE) Processing OWASP
[2] Testing for XML Injection OWASP
[3] XML External Entities The Web Application Security Consortium
[4] IDS17-J. Prevent XML External Entity Attacks CERT
[5] DOS-1: Beware of activities that may use disproportionate resources Oracle
[6] INJECT-5: Restrict XML inclusion Oracle
desc.dataflow.scala.xml_external_entity_injection
Abstract
O método identificado permite referências a entidades externas. Essa chamada pode permitir que um invasor injete uma entidade externa XML no documento XML para revelar o conteúdo de arquivos ou recursos de rede internos.
Explanation
Uma injeção de Entidade Externa XML (XXE) ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um elemento <ENTITY> da DTD (Definição de Tipo de Documento) em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir referências a entidades aninhadas e fazer com que um analisador XML consuma quantidades cada vez maiores de recursos da CPU. Em casos mais perniciosos da injeção de entidades externas XML, um invasor pode ser capaz de adicionar elementos XML que expõem o conteúdo de recursos do sistema de arquivos local ou que revelam a existência de recursos de rede internos.

Exemplo 1:estes são alguns códigos vulneráveis a ataques XXE:


func parseXML(xml: String) {
parser = NSXMLParser(data: rawXml.dataUsingEncoding(NSUTF8StringEncoding)!)
parser.delegate = self
parser.shouldResolveExternalEntities = true
parser.parse()
}


Suponha que um invasor seja capaz de controlar o conteúdo de rawXml de tal forma que o XML tenha a seguinte aparência:


<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>


Quando o XML for avaliado pelo servidor, o elemento <foo> incluirá o conteúdo do arquivo boot.ini.
References
[1] XML External Entity (XXE) Processing OWASP
[2] Testing for XML Injection OWASP
[3] XML External Entities The Web Application Security Consortium
desc.structural.swift.xml_external_entity_injection
Abstract
A gravação de dados não validados em um documento XML pode permitir que um invasor altere a estrutura e o conteúdo do XML.
Explanation
Uma injeção de XML ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para enviar informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir tags estranhas e fazer com que um analisador de XML lance uma exceção. Em casos mais perniciosos de injeção de XML, um invasor pode ser capaz de adicionar elementos XML que alteram credenciais de autenticação ou modificam preços em um banco de dados de comércio eletrônico XML. Em alguns casos, a injeção de XML pode até mesmo provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1:

Suponha que um invasor seja capaz de controlar shoes no seguinte XML.

<order>
<price>100.00</price>
<item>shoes</item>
</order>


Agora, suponha que esse XML está incluído em uma solicitação de serviço Web back-end para efetuar um pedido de um par de sapatos. Suponha que o invasor modifique seu pedido e substitua shoes com por shoes</item><price>1.00</price><item>shoes. O novo XML teria a seguinte aparência:

<order>
<price>100.00</price>
<item>shoes</item><price>1.00</price><item>shoes</item>
</order>


Ao usar analisadores SAX, o valor a partir da segunda tag <price> substitui o valor da primeira tag <price>. Isso permite que o invasor compre um par de sapatos de $100 por apenas $1.
desc.dataflow.dotnet.xml_injection
Abstract
O método identificado grava uma entrada XML não validada. Essa chamada pode permitir que um invasor injete elementos ou atributos arbitrários no documento XML.
Explanation
Uma injeção de XML ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir tags estranhas e fazer com que um analisador de XML lance uma exceção. Em casos mais perniciosos de injeção de XML, um invasor pode ser capaz de adicionar elementos XML que alteram credenciais de autenticação ou modificam preços em um banco de dados de comércio eletrônico XML. Em alguns casos, a injeção de XML pode provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1:

Suponha que um invasor seja capaz de controlar shoes no seguinte XML.

<order>
<price>100.00</price>
<item>shoes</item>
</order>


Agora, suponha que esse XML está incluído em uma solicitação de serviço Web back-end para efetuar um pedido de um par de sapatos. Suponha que o invasor modifique seu pedido e substitua shoes com por shoes</item><price>1.00</price><item>shoes. O novo XML teria a seguinte aparência:

<order>
<price>100.00</price>
<item>shoes</item><price>1.00</price><item>shoes</item>
</order>


Ao usar analisadores SAX, o valor a partir da segunda tag <price> substitui o valor da primeira tag <price>. Isso permite que o invasor compre um par de sapatos de $100 por apenas $1.
desc.dataflow.cpp.xml_injection
Abstract
A gravação de dados não validados em um documento XML pode permitir que um invasor altere a estrutura e o conteúdo do XML.
Explanation
Uma injeção de XML ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode inserir tags estranhas e fazer com que um analisador de XML lance uma exceção. Em casos mais perniciosos de injeção de XML, um invasor pode adicionar elementos XML que alteram credenciais de autenticação ou modificam preços em um banco de dados de comércio eletrônico XML. Às vezes, a injeção de XML pode provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1:

Suponha que um invasor possa controlar shoes no seguinte XML:

<order>
<price>100.00</price>
<item>shoes</item>
</order>


Agora, suponha que esse XML esteja incluído em uma solicitação de serviço Web back-end para efetuar um pedido de um par de sapatos. Suponha que o invasor modifique seu pedido e substitua shoes com por shoes</item><price>1.00</price><item>shoes. O novo XML teria a seguinte aparência:

<order>
<price>100.00</price>
<item>shoes</item><price>1.00</price><item>shoes</item>
</order>


Ao usar analisadores SAX, o valor a partir da segunda tag &lt;price&gt; substitui o valor da primeira tag <price>. Isso permite que o invasor compre um par de sapatos de $100 por apenas $1.
desc.dataflow.golang.xml_injection
Abstract
A gravação de dados não validados em um documento XML pode permitir que um invasor altere a estrutura e o conteúdo do XML.
Explanation
Uma injeção de XML ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir tags estranhas e fazer com que um analisador de XML lance uma exceção. Em casos mais perniciosos de injeção de XML, um invasor pode ser capaz de adicionar elementos XML que alteram credenciais de autenticação ou modificam preços em um banco de dados de comércio eletrônico XML. Em alguns casos, a injeção de XML pode provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1:

Suponha que um invasor seja capaz de controlar shoes no seguinte XML.

<order>
<price>100.00</price>
<item>shoes</item>
</order>


Agora, suponha que esse XML está incluído em uma solicitação de serviço Web back-end para efetuar um pedido de um par de sapatos. Suponha que o invasor modifique seu pedido e substitua shoes com por shoes</item><price>1.00</price><item>shoes. O novo XML teria a seguinte aparência:

<order>
<price>100.00</price>
<item>shoes</item><price>1.00</price><item>shoes</item>
</order>


Ao usar analisadores SAX, o valor a partir da segunda tag <price> substitui o valor da primeira tag <price>. Isso permite que o invasor compre um par de sapatos de $100 por apenas $1.
References
[1] IDS16-J. Prevent XML Injection CERT
[2] INJECT-3: XML and HTML generation requires care Oracle
desc.dataflow.java.xml_injection
Abstract
A gravação de dados não validados em um documento XML pode permitir que um invasor altere a estrutura e o conteúdo do XML.
Explanation
Uma injeção de XML ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir tags estranhas e fazer com que um analisador de XML lance uma exceção. Em casos mais perniciosos de injeção de XML, um invasor pode ser capaz de adicionar elementos XML que alteram credenciais de autenticação ou modificam preços em um banco de dados de comércio eletrônico XML. Em alguns casos, a injeção de XML pode provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1:

Suponha que um invasor possa controlar shoes no XML a seguir.

<order>
<price>100.00</price>
<item>shoes</item>
</order>


Agora, suponha que esse XML está incluído em uma solicitação de serviço Web back-end para efetuar um pedido de um par de sapatos. Suponha que o invasor modifique seu pedido e substitua shoes com por shoes</item><price>1.00</price><item>shoes. O novo XML teria a seguinte aparência:

<order>
<price>100.00</price>
<item>shoes</item><price>1.00</price><item>shoes</item>
</order>


Isso pode permitir que um invasor compre um par de sapatos que custam US$100,00 por US$1,00.
desc.dataflow.javascript.xml_injection
Abstract
O método identificado grava uma entrada XML não validada. Essa chamada pode permitir que um invasor injete elementos ou atributos arbitrários no documento XML.
Explanation
Uma injeção de XML ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir tags estranhas e fazer com que um analisador de XML lance uma exceção. Em casos mais perniciosos de injeção de XML, um invasor pode ser capaz de adicionar elementos XML que alteram credenciais de autenticação ou modificam preços em um banco de dados de comércio eletrônico XML. Em alguns casos, a injeção de XML pode provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1:

Suponha que um invasor seja capaz de controlar shoes no seguinte XML.

<order>
<price>100.00</price>
<item>shoes</item>
</order>


Agora, suponha que esse XML está incluído em uma solicitação de serviço Web back-end para efetuar um pedido de um par de sapatos. Suponha que o invasor modifique seu pedido e substitua shoes com por shoes</item><price>1.00</price><item>shoes. O novo XML teria a seguinte aparência:

<order>
<price>100.00</price>
<item>shoes</item><price>1.00</price><item>shoes</item>
</order>


Ao usar analisadores SAX, o valor a partir da segunda tag <price> substitui o valor da primeira tag <price>. Isso permite que o invasor compre um par de sapatos de $100 por apenas $1.
desc.dataflow.objc.xml_injection
Abstract
A gravação de dados não validados em um documento XML pode permitir que um invasor altere a estrutura e o conteúdo do XML.
Explanation
Uma injeção de XML ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir tags estranhas e fazer com que um analisador de XML lance uma exceção. Em casos mais perniciosos de injeção de XML, um invasor pode ser capaz de adicionar elementos XML que alteram credenciais de autenticação ou modificam preços em um banco de dados de comércio eletrônico XML. Em alguns casos, a injeção de XML pode provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1:

Suponha que um invasor seja capaz de controlar shoes no seguinte XML.

<order>
<price>100.00</price>
<item>shoes</item>
</order>


Agora, suponha que esse XML está incluído em uma solicitação de serviço Web back-end para efetuar um pedido de um par de sapatos. Suponha que o invasor modifique seu pedido e substitua shoes com por shoes</item><price>1.00</price><item>shoes. O novo XML teria a seguinte aparência:

<order>
<price>100.00</price>
<item>shoes</item><price>1.00</price><item>shoes</item>
</order>


Ao usar analisadores XML, o valor da segunda marca <price> substitui o valor da primeira marca <price>. Isso permite que o invasor compre um par de sapatos de $100 por apenas $1.


Uma forma mais grave desse ataque chamada de injeção de XXE pode ocorrer quando o invasor controla a frente ou todo o documento XML que é analisado.

Exemplo 2: Estes são alguns códigos vulneráveis a ataques XXE:

Pressuponha que um invasor possa controlar o XML de entrada para o seguinte código:


...
<?php
$goodXML = $_GET["key"];
$doc = simplexml_load_string($goodXml);
echo $doc->testing;
?>
...


Agora suponha que o XML a seguir é passado pelo invasor para o código no Example 2:



<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>



Quando o XML é processado, o conteúdo do elemento <foo> é preenchido com o conteúdo do arquivo boot.ini do sistema. O invasor pode usar elementos XML que são devolvidos ao cliente para roubar dados ou obter informações sobre a existência de recursos de rede.
desc.dataflow.php.xml_injection
Abstract
A gravação de dados não validados em um documento XML pode permitir que um invasor altere a estrutura e o conteúdo do XML.
Explanation
Uma injeção de XML ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir tags estranhas e fazer com que um analisador de XML lance uma exceção. Em casos mais perniciosos de injeção de XML, um invasor pode ser capaz de adicionar elementos XML que alteram credenciais de autenticação ou modificam preços em um banco de dados de comércio eletrônico XML. Em alguns casos, a injeção de XML pode provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1:

Suponha que um invasor seja capaz de controlar shoes no seguinte XML.

<order>
<price>100.00</price>
<item>shoes</item>
</order>


Agora, suponha que esse XML está incluído em uma solicitação de serviço Web back-end para efetuar um pedido de um par de sapatos. Suponha que o invasor modifique seu pedido e substitua shoes com por shoes</item><price>1.00</price><item>shoes. O novo XML teria a seguinte aparência:

<order>
<price>100.00</price>
<item>shoes</item><price>1.00</price><item>shoes</item>
</order>


Ao usar analisadores SAX, o valor a partir da segunda tag <price> substitui o valor da primeira tag <price>. Isso permite que o invasor compre um par de sapatos de $100 por apenas $1.
desc.dataflow.python.xml_injection
Abstract
A gravação de dados não validados em um documento XML pode permitir que um invasor altere a estrutura e o conteúdo do XML. A análise de XML não validado pode resultar em negação de serviço, exposição de informações confidenciais e até execução remota de código.
Explanation
Uma injeção de XML ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um documento XML ou analisados como XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir tags estranhas e fazer com que um analisador de XML lance uma exceção. Em casos mais perniciosos de injeção de XML, um invasor pode ser capaz de adicionar elementos XML que alteram credenciais de autenticação ou modificam preços em um banco de dados de comércio eletrônico XML. Em alguns casos, a injeção de XML pode provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1:

Suponha que um invasor seja capaz de controlar shoes no seguinte XML.

<order>
<price>100.00</price>
<item>shoes</item>
</order>


Agora, suponha que esse XML está incluído em uma solicitação de serviço Web back-end para efetuar um pedido de um par de sapatos. Suponha que o invasor modifique seu pedido e substitua shoes com por shoes</item><price>1.00</price><item>shoes. O novo XML teria a seguinte aparência:

<order>
<price>100.00</price>
<item>shoes</item><price>1.00</price><item>shoes</item>
</order>


Ao usar analisadores SAX, o valor a partir da segunda tag <price> substitui o valor da primeira tag <price>. Isso permite que o invasor compre um par de sapatos de $100 por apenas $1.
References
[1] Introduction to Software Security: XML Injection Atacks University of Wisconsin-Madison
[2] Exploitation: XML External Entity (XXE) Injection Depth Security
desc.dataflow.ruby.xml_injection
Abstract
A gravação de dados não validados em um documento XML pode permitir que um invasor altere a estrutura e o conteúdo do XML. A análise de XML não validado pode resultar em negação de serviço, exposição de informações confidenciais e até execução remota de código.
Explanation
Uma injeção de XML ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.

2. Os dados são gravados em um documento XML ou analisados como XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir tags estranhas e fazer com que um analisador de XML lance uma exceção. Em casos mais perniciosos de injeção de XML, um invasor pode ser capaz de adicionar elementos XML que alteram credenciais de autenticação ou modificam preços em um banco de dados de comércio eletrônico XML. Em alguns casos, a injeção de XML pode provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1:

Suponha que um invasor seja capaz de controlar shoes no seguinte XML.

<order>
<price>100.00</price>
<item>shoes</item>
</order>


Agora, suponha que esse XML está incluído em uma solicitação de serviço Web back-end para efetuar um pedido de um par de sapatos. Suponha que o invasor modifique seu pedido e substitua shoes com por shoes</item><price>1.00</price><item>shoes. O novo XML teria a seguinte aparência:

<order>
<price>100.00</price>
<item>shoes</item><price>1.00</price><item>shoes</item>
</order>


Ao usar analisadores SAX, o valor da segunda marca <price> substitui o valor da primeira marca <price>.Isso permite que o invasor compre um par de sapatos de $100 por apenas $1.
References
[1] IDS16-J. Prevent XML Injection CERT
[2] INJECT-3: XML and HTML generation requires care Oracle
desc.dataflow.scala.xml_injection
Abstract
O método identificado grava uma entrada XML não validada. Essa chamada pode permitir que um invasor injete elementos ou atributos arbitrários no documento XML.
Explanation
Uma injeção de XML ocorre quando:

1. Os dados entram em um programa por uma fonte não confiável.


2. Os dados são gravados em um documento XML.

Em geral, os aplicativos usam o XML para armazenar dados ou enviar mensagens. Quando usados para armazenar dados, documentos XML são frequentemente tratados como bancos de dados e podem conter informações confidenciais. Mensagens XML são muitas vezes utilizadas em serviços Web e também podem ser usadas para transmitir informações confidenciais. Mensagens XML podem até mesmo ser usadas para enviar credenciais de autenticação.

A semântica de documentos e mensagens XML poderá ser alterada se um invasor tiver a capacidade de escrever XML bruto. No melhor dos casos, um invasor pode ser capaz de inserir tags estranhas e fazer com que um analisador de XML lance uma exceção. Em casos mais perniciosos de injeção de XML, um invasor pode ser capaz de adicionar elementos XML que alteram credenciais de autenticação ou modificam preços em um banco de dados de comércio eletrônico XML. Em alguns casos, a injeção de XML pode provocar criação de scripts entre sites ou avaliação de código dinâmico.

Exemplo 1:

Suponha que um invasor seja capaz de controlar shoes no XML a seguir.

<order>
<price>100.00</price>
<item>shoes</item>
</order>


Agora, suponha que esse XML está incluído em uma solicitação de serviço Web back-end para efetuar um pedido de um par de sapatos. Suponha que o invasor modifique seu pedido e substitua shoes com por shoes</item><price>1.00</price><item>shoes. O novo XML teria a seguinte aparência:

<order>
<price>100.00</price>
<item>shoes</item><price>1.00</price><item>shoes</item>
</order>


Ao usar analisadores SAX, o valor a partir da segunda tag <price> substitui o valor da primeira tag <price>. Isso permite que o invasor compre um par de sapatos de $100 por apenas $1.
desc.dataflow.swift.xml_injection