Categorias
Tropeçando

Tropeçando 41

Computador, a Máquina de Fazer Burro « Meio Bit

Greatest hits de dicas do Dropbox - Como se faz - INFO Online

[Dicas-L] Salvando a pele do Programador php - SQL injection

16 perguntas sobre Sistemas Operacionais - Geek List

Descubra o Ubuntu – novo comercial – Ubuntu Dicas

Salvar site como PDF no iPhone, iPod e iPad | Blog do Aurélio

G1 - Google oferece US$ 20 mil para quem 'hackear' o Chrome - notícias em Tecnologia e Games

Índices hipotéticos no PostgreSQL | Comunidade Brasileira de PostgreSQL

Produtividade extrema: 13 dicas para você virar um demônio da Tasmânia com suas tarefas | Papo de Homem – Lifestyle Magazine

Criando Relatórios com PHP - Novatec Editora

Dicas-L: Broffice.org - Broffice - Edição de duas ou mais seções de um documento

Por desconhecimento, muitas pessoas deixam de usar um recurso importante e muito útil da suíte de escritórios Broffice.ORG: a edição de um documento, planilha, apresentação, etc. utilizando duas janelas.

Categorias
Tropeçando

Tropeçando 38

jQuery Cookbook, agora em português

Blog do Márcio d'Ávila » CSS3 testado na prática

Detectando Requisições Ajax com PHP « Igor Escobar // Blog

Instalando um ambiente de desenvolvimento para Android no Ubuntu – Ubuntu Dicas

JQuery para produção de Layouts | Tableless - Desenvolvimento com Padrões Web

IE6 No More - Home

Karadar Classical Music World - Karadar Classical Music World

xkcd: Incident » CrisDias weblog

Typograph – Scale & Rhythm

Typograph é um projeto de lamb.cc (onde tem outros muito uteis para quem desenha páginas web) que nos permite alterar as características de uma folha de estilo CSS vendo o resultado em tempo real.

Podemos especificar as proporções de tamanho nas fontes, os espaços gerados, as margens, o tipo de letra… arrastando e soltando os componentes veremos o resultado no painel central, com opção de obter o código gerado na área inferior direita.

Muito útil para trabalhar e para explicar de forma intuitiva o uso de folhas de estilo.

Feliz 2011 | Tableless - Desenvolvimento com Padrões Web

G1 - Problema no sistema do Hotmail deletou e-mails na virada do ano - notícias em Tecnologia e Games

Categorias
Tropeçando

Tropeçando 37

Anunciado o fim do VGA….Saiba porquê! | Peopleware

Bem vindo a Xangri-lá – Parte 2 | Boas práticas de Desenvolvimento com Padrões Web

LastPass compra Xmarks! | Peopleware

Free AJAX animated loading gif's | 3 dimensional (3D)

Nós também cometemos erros, diz Mozilla - Tecnologia pessoal - Notícias - INFO Online

Acessando o Ubuntu remotamente – Ubuntu Dicas

Categorias
Tropeçando

Tropeçando 34

The Portable Freeware Collection - Latest entries

Coleção de programas portáteis

Fotos y vectores gratis para descargar | Freepik

Modernizr

Modernizr adds classes to theelement which allow you to target specific browser functionality in your stylesheet. You don't actually need to write any Javascript to use it.

Online converter - convert video, images, audio and documents for free

É difícil trabalhar com Cluster? - Mauro Pichiliani - Banco de Dados

De McLanche Feliz a Duncan McCloud: só pode haver um! « Meio Bit

JSON

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

Três ferramentas para editar arquivos PDF na Internet

Cinco sites para fazer streaming de vídeo ao vivo - Geek List

smartQ - workflow visualization, task management, team collaboration

symfony | Web PHP Framework

CodeIgniter - Open source PHP web application framework

The PHP Benchmark

Nem todo trecho de código PHP será executado na mesma velocidade. Você pode se surpreender com os resultados que esta página gera, mas isto é esperado. A idéia é calcular a performance de trechos de código que possuem mais de uma abordagem possível e assim tenha-se a idéia de qual das abordagens possue a melhor performance.

Responsabilidade de um dev client-side | Boas práticas de Desenvolvimento com Padrões Web

Navegabilidade em Dispositivos Móveis | Boas práticas de Desenvolvimento com Padrões Web

Categorias
Banco de dados PHP Programação

Galvão bota a mão na massa em SP

Quem está em SP e estiver disponível em 1º de março (1ª edição) ou 31 de maio (2ª edição) terá uma ótima oportunidade de conhecer ainda mais sobre práticas de segurança no desenvolvimento em php. Recebi a seguinte mensagem do Er Galvão:

No dia primeiro de Março estarei em São Paulo ministrando um workshop sobre segurança em aplicações PHP, focando em tópicos específicos e técnicas 100% práticas de defesa.

Er Galvão entende muito de segurança e tem grande facilidade em passar seu conhecimento, como pode ser visto no artigo Segurança no PHP. Se eu estivesse em São Paulo, não perderia.

Segurança no desenvolvimento é fundamental para que a internet seja, verdadeiramente, uma ferramenta benéfica para o comércio. Conheço códigos de lojas virtuais que não foram desenvolvidas com preocupação nos tópicos de segurança. Se isso acontece por terem sido construídas antes de se conhecer as práticas atuais, está mais do que na hora de que sejam reconstruídas. Imagine o prejuízo que já se tem (só não se sabe) quando algum criminoso digital conhece essas falhas.

Use a tecnologia a seu favor. Ouça o que o Er Galvão tem a contribuir.

http://www.temporealeventos.com.br/?area=88

São Paulo - SP
1 de Março 31 de maio das 9h00 às 17h00 (2ª edição)

Aprenda: 1 profissional por máquina

PHP: Proteja sua Aplicação

técnicas para defender sua aplicação PHP de ataques como SQL Injection, Cross Site Scripting e Cross Site Request Forgeries

Objetivo: Neste treinamento o profissional aprenderá técnicas para defender sua aplicação PHP de ataques como SQL Injection, Cross Site Scripting e Cross Site Request Forgeries. Primeiramente serão apresentados exemplos práticos de funcionamento de cada um destes ataques de forma à compreender os pontos fracos de cada aplicação. Serão então colocadas em prática diversas técnicas, variando das mais simples às menos óbvias que axiliarão o desenvolvedor à diminuir consideravelmente o nível de vulnerabilidade de suas aplicações.

Público Alvo: Desenvolvedores PHP e demais interessados

Pré-requisitos: Conhecimentos básicos de HTML e Conhecimentos intermediários de PHP

Sistema operacional em que o curso será ministrado: Linux

Após o término deste treinamento o participante estará imediatamente apto a: Compreender o funcionamento dos ataques mais comuns que rondam a web, desenvolver aplicações mais seguras e robustas, menos vulneráveis à ataques.

Conteúdo Programático

Boas práticas:

O que todo o programador PHP deveria saber
O que é e como funciona um ataque de SQL Injection
SQL Injection - Técnicas de defesa: Porque addslashes não é o bastante
O que é e como funciona um ataque de Cross Side Scripting (XSS)
XSS - Técnicas de defesa
O que é e como funciona um ataque de Cross Site Request Forgeries (CSRF)
CSRF - Técnicas de defesa

Categorias
PHP

Converter formato de data para o formato BR, em uma linha de código só

Vou pedir licença ao Frederico e também palpitar sobre a possibilidade de, em uma linha, converter o formato de data do banco (funciona para o MySQL e outros bancos) para o formato brasileiro em php.

$data = "2008-01-09 14:56:06";
echo date('d/m/Y H:i:s', strtotime($data)); // mostrará 09/01/2008 14:01:06.
echo date('d/m/Y', strtotime($data)); // mostrará 09/01/2008.

Update em 24/01/2023: Podemos utilizar também DateTimeImmutable:

php > $data = "2008-01-09 14:56:06";
php > echo (new \DateTimeImmutable($data))->format('d/m/Y H:i:s');
09/01/2008 14:56:06
php > echo (new \DateTimeImmutable($data))->format('d/m/Y');
09/01/2008

Simples assim. 🙂

Essa solução funciona para datas no formato yyyy-mm-dd hh:mm:ss e yyyy-mm-dd.

Categorias
PHP

Segurança no PHP

Os 6 requisitos mínimos

por Er Galvão Abbott (http://www.galvao.eti.br/) na revista PHPMagazine (http://www.phpmagazine.org.br/)

logo-phpmagazine

Apresentareremos neste artigo 6 requisitos que todo o desenvolvedor PHP deveria contemplar em sua aplicação. São boas práticas e hábitos simples que implementam um nível mínimo de segurança em qualquer sistema ou ferramenta desenvolvida com a linguagem.

A linguagem PHP é, sem dúvida, uma das mais populares quando o assunto é desenvolvimento de aplicações web. Existe, porém, um preconceito muito grande com a linguagem quando a questão é segurança. Neste artigo veremos 6 requisitos básicos que toda aplicação deveria possuir e que implementarão o mínimo de segurança em tudo o que você desenvolver.

Conceito: PHP é uma linguagem mais vulnerável do que as outras?

Atualmente impera no mercado de desenvolvimento um preconceito relacionado à segurança de aplicações PHP. A linguagem é freqüentemente alvo de duras críticas por parte da própria comunidade de desenvolvimento, e não é raro presenciarmos aplicações extremamente vulneráveis que, com toda a certeza, dão razão a essas críticas.

Este preconceito, totalmente equivocado, tem suas origens na extrema flexibilidade de configuração e uso da linguagem e no número cada vez maior de desenvolvedores inexperientes que começam sua carreira desenvolvendo aplicações PHP, ignorando questões básicas, seja por falta de conhecimento ou porque estão procurando agilizar sua produção pessoal.

Este artigo não é destinado apenas aos que estão começando. É surpreendente o número de desenvolvedores mais experientes que, por terem adquirido vícios, ainda ignoram as questões que apresentaremos aqui.

Requisito #1: Esqueça register_globals!

Register_globals é, sem dúvida alguma, a diretiva de configuração mais popular e polêmica já implementada no PHP. É popular entre os desenvolvedores por tornar o processo de programação muito mais ágil e prático. É polêmica porque retira tanto do programador quanto do interpretador da linguagem a responsabilidade em definir a origem das informações utilizadas pela aplicação.

Esta diretiva causou tantos problemas que começou a vir desabilitada por default a partir da versão 4.2.0 e será eliminada na versão 6. Por isso, se você ainda programa com register_globals ligada, está mais do que na hora de mudar.

Observe o seguinte exemplo de código:

$url = "http://www.meusite.com.br/index.php";
$errMsg = "Usuário%20não%20autenticado";
if (!$autenticado) {
header("Location: $url?erro=$errMsg");
} else {
/* A aplicação age com se o usuário estivesse autenticado */
}

Este código verifica por uma variável booleana chamada $autenticado, que tipicamente viria de uma sessão aberta quando o usuário se autenticou em nossa aplicação ou mesmo de um cookie. Ao utilizarmos os recursos da register_globals, porém, não estamos dizendo ao interpretador PHP que este dado deve vir obrigatoriamente de uma destas duas fontes.

Sendo assim, o interpretador procurará por esta variável em diversas fontes (variável do servidore web, dados de formulário, cookie, arquivos enviados por upload, query string ou sessões) das quais ele obteve informações até encontrá-la, desprezando se esta fonte está correta.

Torna-se extremamente simples "enganar" a sua aplicação PHP, basta que eu chame o seu arquivo passando a variável esperada por query string.

http://www.meusite.com.br/script.php?autenticado=1

Ao receber a query string contendo a informação "autenticado", este dado será automaticamente interpretado como uma variável pelo interpretador, quer exista sessões ou cookies ou não.

Uma dúvida freqüente é "se não tenho autorização para desligar a register_globals o que eu posso fazer?". A resposta para isso é tão simples quanto tudo o mais na linguagem: programe como se ela estivesse desligada! Veja como fica o nosso código ao não utilizar a register_globals:

$url = "http://www.meusite.com.br/index.php";
$errMsg = "Usuário%20não%20autenticado";
if (!$_SESSSION['autenticado']) {
header("Location: $url?erro=$errMsg");
} else {
/* A aplicação age com se o usuário estivesse autenticado */
}

Observe a mudança: ao utilizarmos o array super global $_SESSION, estamos explicitando para o interpretador que a informação "autenticado" tem que, obrigatoriamente, vir de uma sessão. Isto significa que será impossível para o interpretador confundir este dado com um dado enviado pela query string, pois este fica armazenado em um array super global diferente:

  • $_SERVER - Informações definidas pelo servidor web (Apache, IIS etc)
  • $_GET - Informações passadas por query string ou por um formulário web utilizando o método GET
  • $_POST - Informações enviadas, tipicamente, por um formulário web utilizando o método POST
  • $_COOKIE - Informações fornecidas por um cookie HTTP
  • $_FILES - Informações fornecidas por arquivos que foram enviados via upload HTTP
  • $_ENV - Informações fornecidas pelo ambiente do servidor
  • $_REQUEST* - Informações fornecidas por GET, POST ou COOKIE

* Cuidado: O uso do array super global $_REQUEST é quase tão perigoso quanto a register_globals em si, pois nesse caso a informação pode vir de qualquer um dos 3 métodos: GET, POST ou COOKIE.

Requisito #2: Use require e não include

O comando include e seus derivados - como include_once - são freqüentemente usados em detrimento do comando require. Este fato curioso a princípio é conseqüência da similaridade do comando include com outras linguagens, como C e Java.

O que muita gente não sabe, porém, é que este comando carrega consigo um risco muito grande para sua aplicação: se por algum motivo a inclusão do arquivo falhar - erro de digitação, disco corrompido etc - será gerado um erro de nível warning, um nível leve de erro que não causa a parada da execução do script.

Utilizando o comando require, garantimos que, no caso de falha na carga do arquivo, seja gerado, além do erro de nível warning, um erro de nível fatal. Em bom português isso significa que a execução do seu script será imediatamente interrompida neste caso. Por que é bom que seu script seja interrompido no caso de falha de inclusão de outro arquivo? Simples: no caso de falhas, as variáveis, as funções, as constantes e o que mais este arquivo carregava consigo, simplesmente, não estarão disponíveis.

Requisito #3: Filtre a entrada de dados!

Um dos principais conceitos de segurança é a filtragem dos dados que são recebidos antes de utilizá-los. A falta de fitlragem é a causa de inúmeros problemas de segurança, incluindo o infame SQL Injection, ou Injeção de SQL. Observe o seguinte código:

require_once("conecta.php");
$conn = conecta();
$sql = "SELECT email FROM usuarios WHERE usuario_id = " . $_GET['uid'];
$recordSet = mysql_query($sql);
while ($record = mysql_fetch_assoc($recordSet)) {
echo $record['email'] . '<br />';
}
mysql_close();

O problema deste código é utilizar um dado informado pela query string (uid) sem fazer nenhuma filtragem, ou seja, nosso script aceitará cegamente qualquer coisa que for digitada como valor de uid. Observe a seguinte URL:

http://www.meusite.com.br/script.php?uid=198%20OR%20'x'='x'

Após a conversão dos caracteres especiais desta URL, o valor de uid será (sem aspas duplas): "198 or 'x'='x'". Note que, quando concatenarmos isto à nossa query, ela terá sofrido uma grande modificação:

SELECT email FROM usuarios WHERE usuario_id = 198 or 'x'='x'

É por isso que a chamamos de "Injeção de SQL". A parte em vermelho acima é formada de SQL válido, mas completamente alienígena à nossa plicação: ele modifica o comportamento original da query.

Observe que, com um mínimo de esforço, um usuário conseguiu expor todos os e-mails cadastrados em nossa base de dados: como foi utilizado o operador "OR" e a segunda condição ('x'='x') é sempre verdadeira, serão exibidos todos os registros.

Para evitarmos este tipo de problema, devemos aplicar um tratamento à informação antes de utilizá-la. Caso a minha query - como neste exemplo - esteja esperando um número inteiro, a solução é simples: forçamos a conversão do dado recebido para número inteiro:

require_once("conecta.php");
$conn = conecta();

settype($_GET['uid'], integer);

$sql = "SELECT email FROM usuarios WHERE usuario_id = " . $_GET['uid'];
$recordSet = mysql_query($sql);
while ($record = mysql_fetch_assoc($recordSet)) {
echo $record['email'] . '<br />';
}
mysql_close();

A partir de agora, qualquer dado enviado pela query string será primeiro convertido para inteiro e somente depois desta conversão é que o utilizaremos. No caso de uma tentativa de Injeção de SQL, nosso script considerará apenas a parte numérica (198), como deveria ser. Além disso, se por um acaso nosso script receber apenas texto, a função settype converterá isto para o número 0.

Caso a minha query esteja esperando uma string a solução reside em criar um tratamento que valide esta string. Vejamos um exemplo: possuo uma query que busca dados de um usuário através de seu endereço de e-mail:

$sql = "SELECT nome, sobrenome FROM usuarios WHERE email = '" . $_GET['email'] . "'";

Sabemos que um endereço de e-mail é formado por um nome de usuário, uma arroba e um domínio. Para fins de simplificação do exemplo, trabalharemos como se o usuário só pudesse usar letras, números e o caracterese de ponto - para quem levar a validação de e-mail a sério consulte a RFC 822. Podemos representar isso através de uma expressão regular:

/^[A-Z|a-z|0-9|\.|]+\@[A-Z|a-z|0-9\.|]+/

Sendo assim, só aceitaremos o dado de endereço de e-mail se ele estiver dentro dos padrões de minha expressão regular. Nosso código então ficaria assim:

require_once("conecta.php");
if (preg_match('
/^[A-Z|a-z|0-9|\.|]+\@[A-Z|a-z|0-9\.|]+/', $_GET['email'])) {
$conn = conecta();

$sql = "SELECT nome, sobrenome FROM usuarios WHERE email = '" . $_GET['email'] . "'";
$recordSet = mysql_query($sql);
while ($record = mysql_fetch_assoc($recordSet)) {
echo $record['email'] . '<br />';
}
} else {
die("O dado informado não é um endereço de e-mail válido.");
}
mysql_close();