O ataque HTTP Request Smuggling explora uma análise incompleta dos dados apresentados feito por um sistema intermediário HTTP trabalhando como um proxy. HTTP Request Smuggling consiste no envio de uma solicitação HTTP especialmente formatada que será analisada de forma diferente pelo sistema de proxy e pelo sistema final, então o atacante poderia roubar uma solicitação para um sistema sem o outro estar ciente disso. Este ataque faz com que seja possível explorar outros ataques, como cache poisoning, session hijacking, Cross-site Scripting (XSS) e, sobretudo, a capacidade de burlar a proteção de firewall de aplicações web.

Para explorar o HTTP Request Smuggling, algumas condições específicas devem existir, tais como a presença do sistema de proxy específico e versão, como SunOne Proxy 3.6 (SP4) ou beta FW-1/FP4-R55W ou uma vulnerabilidade de XSS no servidor web.

Basicamente o ataque consiste em enviar uma solicitação HTTP que encapsula uma segunda solicitação HTTP no mesmo cabeçalho, como mostrado abaixo:

GET /some_page.jsp?param1=value1&param2=
Content-Type: application/x-www-form-
Content-Length: 0
Foobar: GET /mypage.jsp HTTP/1.0
Cookie: my_id=1234567
Authorization: Basic ugwerwguwygruwy

Neste caso, o primeiro cabeçalho HTTP é analisado pelo sistema de proxy, e o segundo pelo sistema final, permitindo ao invasor burlar as regras de acesso do proxy.

Exemplo: Request Credential Hijacking

Outra area de interesse é a habilidade do atacante forçar a execução de um script (/some_page.jsp) com as credenciais de um cliente. Esse ataque é similar aos efeitos do ataque de Cross-site Request Forgery, mas este é mais eficiente, pois o atacante não é obrigado a interagir com o cliente (vítima). O ataque ocorre como abaixo:

POST /some_script.jsp HTTP/1.0
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 9
Content-Length: 142
this=thatGET /some_page.jsp?param1=value1&param2=value2 HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Foobar:

Quando o cliente envia uma requisição, como:

GET /mypage.jsp HTTP/1.0
Cookie: my_id=1234567
Authorization: Basic ugwerwguwygruwy

Tomcat irá colocar esta requisição na fila de incompletes, e juntos, terão:

GET /some_page.jsp?param1=value1&param2=value2 HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Foobar: GET /mypage.jsp HTTP/1.0
Cookie: my_id=1234567
Authorization: Basic ugwerwguwygruwy

Agora com uma requisição completa, ele irá chamar o script /some_page.jsp e retornar seus resultados ao cliente. Se este script é um pedido de alteração de senha, ou uma transferência de dinheiro para a conta do atacante, então isso pode incorrer em danos potencialmente graves para o cliente.

Muitas vezes durante a implantação de sistemas, os desenvolvedores acabam utilizando scripts auxiliares para ajudar muitas vezes no debug, ou então gerenciar de forma mais simples algum processo junto a database, ou então simplesmente ao utilizar sistemas já prontos, como por exemplo, o Joomla, acabam ficando para traz arquivos que podem ser perigosamente utilizado por atacantes.

Entre esse tipo de “sucata” acabam ficando:

– infs,
– arquivos.inc
– pastas com arquivos de backup, e etc

Apesar de modificar a configuração do Webserver para evitar que o index da pasta seja visível e adicionando um index em todas as pastas, existem diversas possibilidades de detectar estes dados e na maioria das vezes eles contêm informações como senhas de base de dados, source code de aplicação ou então algum script privilegiado que foi negligenciado pelo desenvolvedor.

O ataque de Forced Browsing consiste no uso de diversas técnicas que visam enumerar entre as possibilidades disponiveis:

– Diretórios importantes e/ou que podem conter informações privilegiadas (/admin, /install, /setup, /includes, etc);
– Arquivos de backup com códigos-fonte de aplicações ( index.php.bak, login.bak, etc.);

Uma ferramenta automatizada pode varrer milhares de combinações em sua database de conhecimento de possíveis pastas. O nikto é uma delas. Ele atua como ferramenta opensource para teste de diversas vulnerabilidades em sistemas web, tais como:

– Má configuração no webserver
– Ataques de xss, sql injection, entre outros
– Ataques de Force Browsing.

A técnica utilizada para enumerar recursos escondidos no webserver é conhecida como fuzzing e é vastamente utilizada por analistas de segurança a fim de detectar vulnerabilidades até então desconhecidas.

Basicamente a tecnica consiste em enviar requisições para o servidor web e analisar a resposta.

Quando um recurso existente é acessado, o servidor responde com a mensagem HTTP 200 OK.

Da mesma forma existem diversas outras respostas que podem evidenciar a existência de informações interessantes tais como a mensagem HTTP 403 que se refere à necessidade de autenticação para acessar o conteúdo no webserver.

Eliminando as respostas 404 (not found), a ferramenta consegue minerar as respostas e separar somente as informações realmente interessantes.

HTTP response splitting ocorre quando os dados entram na aplicação web através de uma fonte não confiável, frequentemente em um request HTTP, sendo essa manipulada de forma que os dados enviados sejam adicionados em um response Header para o usuário sem ser validada a procura de caracteres maliciosos.

O HTTP response splitting é o que chamamos de vetor de ataques e não um ataque com finalidade por si só. Quando focamos a atenção meramente na técnica, vemos que ela simplesmente retrata um atacante enviando dados maliciosos para uma aplicação vulnerável e a aplicação inclui os dados no cabeçalho de resposta.

Para montar um exploit bem sucedido, a aplicação deve permitir que os dados inseridos contenham o caractere CR (carriage return, que pode ser enviado através de %0d ou \r) e o LF (line feed, que pode ser inserido através de um %0a ou \n) diretamente no header. Estes caracteres não apenas dão ao atacante controle dos headers e o corpo da resposta como também o restante de toda a resposta que a aplicação pretendia enviar para o usuário, criando desta forma uma resposta totalmente controlada por ele.

Exemplo:
O segmento de códigos abaixo se refere ao nome do autor de um weblog, pelo campo author, através de um HTTP request e é setado em um cookie header pelo HTTP response

String author = request.getParameter(AUTHOR_PARAM);
…
Cookie cookie = new Cookie(“author”, author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);

Tendo que uma string que consiste de caracteres padrão alpha-numeric, como por exemplo, “Joao Pedro” é enviada em um HTTP response incluindo este cookie tenha a seguinte forma:

HTTP/1.1 200 OK
…
Set-Cookie: author=Joao Pedro
…

Entretanto, devido o valor do cookie ser formado por dados não validados em um user input, a resposta somente irá permanecer desta forma se o valor submetido para AUTHOR_PARAM não contiver os caracteres CR e LF. Se um atacante submeter uma string maliciosa como, por exemplo,
“Hacker\r\n\HTTP/1.1 200 OK\r\n…”

A resposta HTTP pode ser quebrada em 2 responses com a seguinte forma:
HTTP/1.1 200 OK
…
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
…

Claramente a segunda resposta é totalmente controlada pelo atacante e pode ser construída com qualquer header e conteúdo desejado no corpo da pagina. A habilidade de um atacante construir respostas HTTP arbitrárias pode permitir uma variedade de ataques resultantes como, por exemplo:

– Cross-user Defacement
– Cache Poisoning
– Cross-site Scripting
– Page Hijacking

Nos próximos artigos veremos como utilizar a técnica demonstrada acima para obter diversos resultados de ataques como o Cache Poison e o Cross-site Scripting.

O ataque de Path Transversal tem o objetivo de acessar arquivos e diretórios que estão armazenados fora do diretório utilizado pela aplicação (Webroot).
Acessando a aplicação pelo browser o atacante pode olhar os links absolutos para arquivos armazenados no Web Server. Manipulando as variáveis que referencia os arquivos utilizando “dot-dot-slash (../)” utilizando diferentes seqüências e variações podem permitir acesso arbitrário a arquivos e diretórios no file system, incluindo código fonte da aplicação, arquivos críticos e de configuração do sistema operacional entre outros. Utilizando “../” o atacante consegue direcionar a aplicação para diretórios acima do diretório padrão.
Este ataque pode ser potencializado como veremos abaixo utilizando um código malicioso externo que pode ser injetado diretamente como variável na aplicação, sendo este ataque conhecido também como RFI (Remote File Injection). Este tipo de vulnerabilidade pode ser detectada facilmente utilizando scripts chamados de Spider/Crawler.

Vejamos abaixo dois exemplos clássicos desta falha.

Exemplo 1
O exemplo abaixo mostra como uma aplicação manipula recursos em uso.

http://site/get-files.jsp?file=report.pdf
http://site/get-page.php?home=aaa.html
http://site/some-page.asp?page=index.html

Neste exemplo é possível inserir a string maliciosa como parâmetro da variável a fim de acessar arquivos localizados fora do diretório onde estão publicados os arquivos web.

http://site/get-files?file=../../../../diretorio/arquivo
http://site/../../../../diretorio/arquivo

A URL abaixo mostra como explorar um sistema Unix para pegar seu arquivo de senhas.

http://site/../../../../etc/shadow
http://site/get-files?file=/etc/passwd

Exemplo 2
Vejamos um exemplo clássico de aplicação em PHP vulnerável.

$template = ‘blue.php’;
if ( is_set( $_COOKIE[‘TEMPLATE’] ) )
$template = $_COOKIE[‘TEMPLATE’];
include ( “/home/users/phpconf/templates/” . $template );
?>

Um atacante pode explorar esta vulnerabilidade enviando a seguinte requisição HTTP:

GET /vulneravel.php HTTP/1.0
Cookie: TEMPLATE=../../../../../../../../../etc/passwd

Gerando uma resposta do servidor como esta:

HTTP/1.0 200 OK
Content-Type: text/html
Server: Apache

root:fi3sED95ibqR6:0:1:System Operator:/:/bin/ksh
daemon:*:1:1::/tmp:
phpconf:f8fk3j1OIf31.:182:100:Developer:/home/users/phpconf/
:/bin/csh

A repetição dos caracteres ../ apos /home/users/phpconf/templates fez com que a função include() fizesse o include do arquivo /etc/passwd.

Como proteger sua aplicação:

• Preferivelmente trabalhe sem utilizar inputs de usuários na aplicação quando você utilizar file system calls
• Use chroot Jail e políticas de code Access para restringir onde os arquivos podem ser obtidos ou salvos em sua aplicação
• Sanitize todas as variáveis que sua aplicação utiliza impedindo assim que caracteres de escape maliciosos sejam indexados e processados

Para facilitar a vida dos desenvolvedores, abaixo seguem 2 regras para trabalhar melhor o aspecto de segurança da aplicação, seguindo como um roteiro para melhorar a segurança dos sistemas. Obviamente cada desenvolvedor deve verificar quais das regras se adéquam melhor as necessidades da aplicação. Na grande maioria dos casos o simples fato de aplicar 1 das regras já surte o efeito necessário como contenção de riscos na aplicação.

Nunca inserir dados não confiáveis exceto em locais permitidos.

Esta primeira regra é para negar tudo. Não insira dados inseguros em um documento HTML a não ser que seja em uma localização diferente das listadas abaixo. A razão disto é que existem muitos contextos estranhos em HTML que podem tornar o filtro por caracteres de escape muito complicado e as vezes ineficiente. Pensando friamente não existe nenhuma boa razão para colocar dados não confiáveis nestes contextos.

Diretamente em um Script:

Dentro de um comentário HTML:

Em um nome de Atributo:

… NUNCA COLOQUE DADOS NÃO CONFIAVEIS AQUI…=teste />

Em uma tag name:

E o mais importante: Nunca aceite códigos JavaScript a partir de uma origem não confiável e depois execute. Por exemplo, um parâmetro chamado “callback” que contem um JavaScript Code Snippet. Nem uma centena de escaping rules conseguiria consertar uma vulnerabilidade destas.

Faça HTML Escape antes de inserir dados não confiáveis em um elemento HTML

Esta regra é para aqueles que desejam colocar dados não confiáveis diretamente em algum lugar do corpo do formulário HTML. Isto inclui tags normais como div, p, b, td, etc. A maioria dos framworks web tem um método para HTML encoding que escapam os caracteres abaixo. Entretanto, isto é absolutamente não eficiente para outros contextos HTML.

…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…

…ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE…

Faça escape dos seguintes caracteres com HTML entity encoding para previnir problemas em contextos de execução, como por exemplo um script, style ou entção event handlers. Usar codificação hexadecimal é recomendada. Alem disto existem 5 caracteres significantes em XML (&, <, >,”,’) que podem ajudar em um contexto HTML.

& –> &
< –> <
> –> >
” –> “
‘ –> ‘ ‘ não e recomendado
/ –> / a barra de data é recomendada em contextos html.

Resumindo, quando pensamos em XSS attacks, temos que levar em conta que o Client Side é tão crítico quando o Server side, ou seja, temos que cuidar sempre do aspecto do cliente que acessa a aplicação evitando problemas futuros com roubos de informações.

(continua na próxima edição…)

Cross-site-scripting attacks, ou Xss como são conhecidos, são um tipo de Injection attacks, onde scripts maliciosos são injetados através de parâmetros confiáveis em um Website. O ataque de XSS ocorre quando um atacante utiliza a aplicação web para enviar códigos maliciosos, geralmente na forma de Browser Side Scripts para um usuário acessar.

O atacante pode utilizar o XSS para enviar um script malicioso com diversas finalidades:

– Roubar cookies do browser para efetuar um seqüestro de sessão;
– Iludir o usuário para que este acessse um determinado conteúdo e preencha dados seus pensando que está utilizando o site real, quando na verdade o conteúdo que o mesmo está acessando faz parte de um HTML malicioso que foi embutido em algum componente vulnerável da aplicação.

Os ricos de ataques XSS podem ser variáveis, pois depende muito do que o atacante pretende fazer com a falha que ele encontrou. Desta forma o XSS pode ser o vetor para uma infinidade de outros ataques muito mais perigosos como Browser Hijacking, ClickJacking e XSRF (Cross-site Request Forgery).

Como proteger sua aplicação para evitar que este tipo de falha seja utilizado contra seus usuários permitindo que credenciais sejam roubadas?

Dica importante:

Dados não Confiáveis

Dados não confiáveis são todos aqueles dados que são originados a partir de HTTP requests, em forma de parâmetros URL, form fields, headers ou Cookies. Porém dados que são originados a partir de Databases, web services e outros sources são frequentemente tratados também como não confiáveis a partir da perspectiva de segurança.

Todos os dados que sua aplicação utilizada devem ser sanitizados para remover caracteres de escape entre outras coisas. Nunca se deve trabalhar diretamente com dados inseguros em funções que injetem ou exibam informações em uma database ou em um form HTML.

(leia: Roteiro para a melhoria da segurança dos sistemas)

Filtragem Incorreta de Caracteres de Escape

Ocorre quando o dado inputado na variável não é filtrado para remoção de caracteres de escape e então é transformado em uma query SQL. Isto resulta na potencial manipulação de queries executadas na database pelo usuário da aplicação.

Um exemplo:

statement = “SELECT * FROM users WHERE name = ‘” + userName + “‘;”
Este código é designado para trazer resultados de um determinado username a partir da tabela users. Entretanto, se a variável “userName” for modificada para um determinado valor especifico que contenha caracteres de escape como por exemplo ‘, “, ), essa query SQL pode retornar mais do que o autor do código previu. Por exemplo, colocando o “userName” como:
a’ or ‘t’=’t
Ao ser executada pelo código da aplicação web a database irá executar o seguinte query:
SELECT * FROM users WHERE name = ‘a’ OR ‘t’=’t’;
Se este código for utilizado em um procedimento de autenticação, este exemplo pode ser utilizado para selecionar um usuário válido porque a validação do query ‘t’=’t’ é sempre válida, afinal t sempre é igual a t.
Gerenciamento de tipos de dados incorretos
Ocorre quando um valor inputado em um campo não é checado pelo tipo dele. Por exemplo, se a aplicação irá fazer uma checagem na base utilizando uma variável de tipo numérico e o programador não colocou uma checagem para validar se a variavel realmente tem um valor numérico. Por exemplo:
statement := “SELECT * FROM data WHERE id = ” + a_variable + “;”
Está claro neste statement que o autor do código definiu a_variable para ser um número correlacionado com o campo “id”. Entretanto, se de fato for uma string o usuário pode manipular o statemente como quiser, inclusive sobrepassando a necessidade de um caracter de escape. Exemplo, colocando a variavel como:
1;DROP TABLE users
Irá deletar a tabela “users” da database, porque para o sql a string acima será executada da seguinte forma:
SELECT * FROM DATA WHERE id=1;DROP TABLE users;

Como o character “;” no SQL é um delimitador de linha, tudo que vier após ele será considerado um novo comando.

Existentes a mais de uma década, os ataques de SQL Injection vem crescendo drasticamente nos últimos anos, como exemplo, no segundo trimestre de 2008 tivemos aproximadamente 500.000 websites explorados com essa técnica.

Ataques de SQL Injection consistem na exploração de vulnerabilidades de segurança em um website inserindo e executando códigos maliciosos em uma base de dados. Podem ser utilizados para desfigurar um site modificando seus arquivos ou entradas no banco de dados (defacing) e desabilitá-los apagando seu conteúdo, ou ainda hospedar e espalhar vírus, malwares e spywares alterando conteúdos legítimos e fazendo com que usuários acessem material malicioso sem que saibam disso, em hipóteses mais sérias pode ocorrer o roubo de informações de cartões de crédito, senhas e outros.

No início de 2009 um hacker romeno utilizou vulnerabilidades de SQL Injections para hackear e ganhar acesso a diversos dados em grandes empresas de Antivirus, por exemplo, o caso da Kaspersky, Bit Defender e F-Secure.

Basicamente a falha de SQL Injection acontece quando uma determinada variável tratada dentro da aplicação não manipula de forma correta os valores que são inseridos dentro dela, passando estes dados diretamente para uma Query SQL e executando logo em seguida.

Os tipos mais conhecidos de ataques em SQL Injections são:

– Filtragem incorreta em caracteres de escape
– Gerenciamento de Tipos de dados incorretos

Como se proteger?
Todos os dados inputados por usuários não podem ser inputados diretamente em um SQL statement. Ao invés disso devem ser utilizadas queries parametrizadas, ou então os inputs devem ser cuidadosamente filtrados para verificar caracteres de escape.
Usando Queries Parametrizadas
Em linguagens de programação como Java e .NET, queries parametrizadas podem ser utilizadas para trabalhar com parâmetros (algumas vezes chamados de placeholders ou bind virables) ao invés de injetar o dado inputado diretamente na query. Em muitos casos, a query SQL é fixa. O dado inputado é então adicionado (limitado) a um parametro. Abaixo um exemplo usando Java e a API JDBC.
PreparedStatement prep = conn.prepareStatement(“SELECT * FROM USERS WHERE USERNAME=? AND PASSWORD=?”);
prep.setString(1, username);
prep.setString(2, password);
Usando Scaping
Essa é uma forma de tentar se previnir contra este tipo de ataque, porém algo que não se deve utilizar unicamente é filtrar caracteres perigosos. Um dos motivos pelos quais esse tipo de técnica não é a mais adequada é porque ela é baseada na criação de uma “lista negra” de caracteres que podem ser perigosos se inseridos em uma query SQL. Sendo assim, qualquer caracter perigoso que esteja fora de sua lista, irá ser executado. No PHP, por exemplo, existe uma função chamada mysql_real_escape_string que faz esta limpeza e pode ser utilizada para sanitizar seus inputs antes de envialos para uma query SQL:
$query = sprintf(“SELECT * FROM Users where UserName=’%s’ and Password=’%s'”,
mysql_real_escape_string($Username),
mysql_real_escape_string($Password));
mysql_query($query);
Abaixo segue um exemplo de uma função de escaping customizada baseada em um filtro de SQL injection.

$title = $_POST[‘title’]; // dado inputado pelo site
$description = $_POST[‘description’]; // dado inputado pelo site

// Definindo a lista

$dirtystuff = array(“\””, “\\”, “/”, “*”, “‘”, “=”, “-“, “#”, “;”, “<“, “>”, “+”, “%”);


$title = str_replace($dirtystuff, “”, $title); // Funcionou!
$description = str_replace($dirtystuff, “”, $description); // Funcionou!

// input: I\ “like/ green<** veg’et=a-bles> ;and< pizza**
// output: I like green vegetables and pizza

// input: a’;DROP TABLE users; SELECT * FROM data WHERE name LIKE ‘%
// output: aDROP TABLE users SELECT FROM data WHERE name LIKE

?>
Finalizando, existem muitas outras formas de se prevenir contra ataques de SQL Injection, porém a mais importante ainda depende dos programadores aumentarem seu conhecimento sobre segurança, aplicando a seus códigos.

É muito comum encontrarmos artigos técnicos e não técnicos comentando sobre invasões em computadores, redes, certificados digitais SSL e sites seguros, afinal diante da infinidade de facilidades e benefícios que a internet nos traz, temos por trás o número de fraudes que cresce assustadoramente todos os dias, o que faz com que esses assuntos estejam sempre em alta.

Hackers ou crackers? Serão esses os grandes responsáveis por esse aumento no número de fraudes? Serão assim tão complexas as ações que permitem o aumento das estatísticas? Independente de como minha aplicação ou website for feito, se eu tiver um certificado digital SSL terei segurança? O que você realmente sabe sobre isso???

É importante sabermos que existem diferenças entre hackers e crackers, e que em grande parte das vezes que algum tipo de incidente ocorre, nenhum deles estava diretamente envolvido. Devido a vulnerabilidades existentes nos websites, aplicações, etc, basta que pessoas com o mínimo de conhecimento e um pouco de persistência vasculhem a web em busca de ferramentas que permitam identificar vulnerabilidades existentes e outras que permitam explorá-las e teremos mais um fato que irá contribuir para o aumento das estatísticas.

Enquanto o mercado se expande e várias empresas de todos os portes abrem portas na internet, um problema mais grave acaba muitas vezes esquecido, tornando-se um grande vilão, a segurança em aplicações web.

Chegando ao grande ponto dessa questão, nas aplicações a falta de segurança adequada é culpa do desenvolvedor e de quem não a exige. No e-commerce a culpa também é nossa, pois compramos sem pesquisar o suficiente e sem exigir do lojista as garantias adequadas, criando assim um ciclo contínuo que iria melhorar nossa vida digital. Devemos pesquisar mais, saber que um certificado digital SSL não garante a segurança do website, mas é estritamente necessário, que ao pensarmos em desenvolver algo devemos fazê-lo com um profissional que tenha conhecimento nesse assunto e que conheça e adote as melhores práticas de segurança, incluindo normatizações específicas como, por exemplo, o PCI – Payment Card Industry.

Temos acompanhado muitos testes realizados em websites diversos, e-commerces e institucionais, e muitos fóruns fechados que tratam do assunto, e o resultado não é nada agradável. Acompanhando uma estatística de 2007 onde um relatório indica que 90% das aplicações para web são vulneráveis, constatamos a veracidade desse fato em sites pequenos, médios e grandes, alguns muito conhecidos, outros pouco conhecidos, onde a base de dados estava completamente disponível. Infelizmente, muitos desses sites exibem um selo de “Site Seguro”, o que podemos afirmar com 100% de certeza de que isso não existe, nenhum ambiente é 100% seguro para essa afirmação, e para isso não falamos dos melhores hackers do mundo ou crackers, falamos de pessoas com pouco conhecimento em segurança que conseguem muitas vezes obter acesso a variados websites com a utilização de pouquíssimos recursos, e isso independente da linguagem e banco de dados utilizados.

Não raros são os casos onde usando apenas strings de validação como ‘or ‘ e alguns outros, membros de comunidades de segurança ou de hacking informam que conseguiram acesso ao banco de dados do website com poderes de administração, o grande problema nesse caso, os campos de autenticação.

A partir de hoje nosso objetivo nessa coluna será levar conhecimento a vocês, de modo a melhorar ainda mais a qualidade dos projetos desenvolvidos por cada um, como empresa ou profissional liberal, e apoiar no desenvolvimento de uma cultura de segurança mais atuante e presente em nosso mercado.

No próximo artigo, entraremos mais a fundo na parte técnica e de deveres e responsabilidades segundo nossa legislação, acompanhem.