Esta funcionalidade consiste em colocar as mensagens “mais importantes” primeiro, e depois as marcadas com uma estrela, e só a seguir as restantes mensagens.
O Gmail, para definir as mensagens mais importantes, verifica as que responde-mos mais vezes, as que vemos ou vão directas para a reciclagem, e se nós achar-mos que alguma coisa está mal, podemos marcar uma mensagem como Importante ou Não Importante. É também possível utilizar os filtros para ter-mos sempre a certeza de que certas mensagens são marcadas como importantes.
Portanto, no ficheiro principal coloca-mos isto:
<?php
define("APP_RUNNING, true");
?>
E em cada página que quiser-mos que não seja acessível directamente.
<?php
if (!defined("APP_RUNNING")) exit("A página não está disponível.");
?>
]]>
O Collabtive é um software OpenSource em PHP que serve para gerir projectos. Podem ser adicionados vários projectos, e cada projecto pode ter várias metas. Cada meta pode ter vários items que podem ir sendo marcados com “Feitos”, e assim ir determinando a percentagem do projecto que já foi “terminada”.
Suporta também vários utilizadores, vários grupos e permissões, temas e traduções. A equipa de desenvolvimento está também a trabalhar num motor de plugins para o Collabtive, fazendo deste software uma boa escolha.
]]>
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]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/
O blog do PT-DigiArt, uma comunidade portuguesa de Design e Arte, foi inaugurado no dia 18 de Agosto de 2010. O blog abrange todas as áreas da Arte, mas em especial a Arte Digital. Para já, a equipa tem três membros, da qual eu faço parte, mas estamos sempre à procura de novos talentos, por isso, não hesites. Se tens o que é preciso nalguma área do Design, então candidata-te. Se não te queres comprometer, mas tens um artigo que gostavas de ver publicado no blog, envia-o pela página de contacto.
]]>