Mas é de graça?!

Um excelente artigo de Ben Forta sobre o porquê de o ColdFusion ser, no final das contas, uma solução infinitamente mais barata que outras existentes. No artigo ele faz uma excelente abordagem sobre o assunto e compara (com dados e precificação) uma solução ColdFusion com ASP, da Microsoft.

But it’s Free!

Por que ColdFusion? CFFaq.com

Ben Forta publicou hoje o CFFaq.com traduzido para o português brasileiro. A tradução é de minha autoria e acho que ficou boa (quanta modéstia)… A idéia é tornar o CFFaq.com uma referência atualizada sobre ColdFusion e assuntos de interesse imediato, pergunta-resposta, principalmente para aqueles que ainda estão pensando em adotar a tecnologia ou mudar de uma outra linguagem server-side. Forta vai, aos poucos, colocar novas perguntas e respostas e outras referências de ColdFusion. O FAQ tem atualmente 21 questões e todas estão traduzidas para o “brazilian portuguese” que, por enquanto, é a única tradução pronta. Vale bastante dar uma boa lida e adicionar aos favoritos:

http://www.cffaq.com

Ah, já ia me esquecendo: Feliz 2003!!

CFMX e Linux, atualizando o assunto…

Há algum tempo atrás, na CF-Brasil, rolou um pequeno quebra pau sobre como o Java se comportava sob Windows em comparação com Linux. Um assunto aparentemente fora do tópico da lista, até mesmo porque quando se fala em Linux (e por tabela software livre, filosofia de vida, yin-yang, etc, etc). Os ânimos de alguns se alteram e acaba-se abandonando a razão e levando a discussão por um caminho absolutamente sem fim e sem sentido. O que importa nesse blá, blá todo é a relação estrita do Java com o ColdFusion MX, obviamente sob Windows e/ou sob Linux.

Ao meu ver, essas diferenças de performance, estabilidade e outras mais efêmeras, não são tão grandes entre Windows e Linux, apesar de haver relativo consenso (até hoje não vi nenhum benchmark ou teste que prove o contrário) que o Java se sai melhor em Windows do que em Linux. Alguns dizem que o suporte do Java em Linux é muito ruim, outros dizem que não, que se resume a problemas de configuração (veja minhas considerações na CF-Brasil aqui e aqui também). Porém a verdade é que um número considerável de usuários ColdFusion MX estão enfrentando sérios problemas com o Linux. Entretanto a Macromedia está tomando todas as medidas necessárias para que isso seja solucionado. De tantas discussões em fórum de suporte (veja aqui e também aqui) a Macromedia antecipou o lançamento do CFMX updater 2 (que deveria sair só daqui há dois meses) e também manter atualizado (última atualização feita anteontem, dia 18) um TechNote que deveria ser lido por todos aqueles que estão hospedando um servidor ColdFusion MX em máquinas Linux.

Não deixe de ler o TechNote “ColdFusion MX support on Linux“

Entrevista interessante!

Vale bastante a pena dar uma lida nesta entrevista com Edwin Smith, engenheiro de softwares na Macromedia. Ele fala sobre o novo ColdFusion MX (e também do JRun) nos dando uma clara visão de como a Macromedia está encarando esta transição e o que vêm por aí (ótimas notícias!). Leitura obrigatória.

Multiple Instances no CFMX for J2EE

Interessante artigo de Brandon Purcell (MM) sobre as possibilidades oferecidas pelo CFMX rodando sob servidores J2EE. Mais um motivo para realmente crer que o CFML pode se tornar um “Java Killer” sem sombra de dúvida. Viva a simplicidade do CFML e o poderio do Java2! :o)

Advantages of using multiple instances for ColdFusion MX for J2EE

Mais um?

Rafael, um programador ColdFusion que tive o prazer de contratar na época do mundinho “pontocom” – quando trabalhei para a Umbro.com – finalmente deixou a frescura de lado e colocou no ar o seu blog. Só o nome do dito cujo é que eu não entendi nada… CF_BOG? Pântano? Lamaçal? (Bog = atolado). Buenas, tomara que ele possa tocar o seu projeto e, junto do CF_GIGOLÔ e o Blog do MF, precursores (uau!) de blogs especializados em CF em terra brasilis, fazer crescer esta maravilhosa tecnologia. O blog ainda está meio zoneado, com uns $BlogDescription$-Value espalhados, mas vale a pena a visita. Quanto mais conteúdo melhor! :o)

http://www.cfbog.cjb.net – CF_BOG, Confissões de um CF-Maníaco.

Palestra em Brasilia

Semana passada estava trabalhando em Brasília quando vi no jornal que o pessoal da IMedia/Comtraining estava organizando o V Macromedia WebSeminar. Mudei meu vôo para o dia seguinte e, a pedido do Vladimir, fiz uma rápida apresentação sobre o ColdFusion Server. Foi muito na correria, mas acho que deu para falar um pouco sobre os pontos fortes do CF em relação à outras linguagens server-side e passar a limpo alguns dos principais “mitos” errôneos sobre a tecnologia e tirar dúvidas diversas. O evento foi muito bem organizado e contou com a participação de centenas de pessoas, apesar da chuva. Fiquei supreso com o número de “macromedians” em Brasília, muito mais do que esperava, e o melhor: bem organizados.

Security best pratices

Para finalizar a série de posts relacionados com segurança faço algumas pequenas considerações sobre pontos simples, pequenos, porém igualmente importantes para deixar seu servidor mais seguro e à prova de malandragem virtuais. Daqui em diante irei postando coisas relacionadas à segurança sem no entanto me ater a uma seqüência ou série específica.

1) Nos posts passados falei sobre a importância de se deixar o debug options “desligado” no ColdFusion Server. Muitos se esquecem de fazê-lo e isso significa deixar informações valiosas disponíveis para visitantes mal intencionados. Um servidor de produção não deve estar com o debug disponível para todos os IP’s. Quanto menos o malandro do cyberspace souber sobre o seu servidor, melhor para você. “Desligar” o debug no CFServer é uma operação extremamente ridícula, porém negligenciada por muitos. Para fazê-lo basta adicionar um número de IP qualquer na seção “debugging IP’s”. Uma boa sugestão é adicionar o IP loopback da própria máquina (127.0.0.1). Pronto, dessa forma você limita o acessoa informações de erro tais como local físico dos scripts, tipo de servidor, queries SQL e verdadeiros “informes” sobre como é o seu servidor por dentro, tal como você pode ver neste exemplo aqui.

2) Nas versões anteriores ao CFMX, existe um furo de segurança leve, mas que deve ser considerado para aumentar ainda mais a segurança do seu servidor. Ele permite que o visitante, mesmo com o debug desligado, possa conhecer o local físico dos arquivos/scripts do site. Por algum motivo estranho, quando você solicita um arquivo com nomes reservados ao DOS (nul e prn, por exemplo) o ColdFusion retorna uma mensagem de erro diferente, contento a informação de path do scrip: veja este exemplo. Mesmo se você configurar um missing template no ColdFusion Administrator, você terá acesso a esta informação. A solução para este pequeno problema é, também, bem simples. No IIS (se você estiver usando um) vá até o WebSite em questão, clique em “properties” -> “Home Directory”. Em “Application Settings”, clique no botão “Configuration”. Clique no mapping para a extensão “.cfm” e selecione a opção “Check that file exists”. Pronto, agora qualquer erro 404 será direcionada para a página de erro 404 padrão do IIS. Minha recomendação é que se deixe esta opção sempre habilitada em qualquer mapping, não causa perda de performance e você torna o seu servidor web mais “coeso” nas respostas de erro 404.

3) Essa eu nem precisava falar, mas tem muita gente que deixa o ColdFusion Administrator ESCANCARADO para quem quiser visitá-lo. PROTEJA-O JÁ! O diretório CFIDE/Administrator/ deve contar com pelo menos três camadas de proteção, a primeira a própria senha do CFADM, a segunda a proteção de diretório por senha do sistema e a última (se possível) com permissão de acesso apenas a IP’s específicos. Eu ainda coloco uma “quarta” camada de proteção: SSL, acessando o CFADM via https voce protege as senhas de serem “snifadas” em uma rede insegura (Vírtua, por exemplo). Fico impressionado em ver provedores de renome deixando esta opção aberta para que qualquer um possa brincar de brute-force no campo “password”. Lembrem-se de que o CFADM possui apenas uma mísera senha (sequer tem um username). Já consegui acesso a um servidor destes com apenas 6 horas de brute-force rodando na minha máquina. Veja um exemplo de escancaramento aqui.

4) Não instale nenhum exemplo! O ColdFusion Server vêm com uma série de templates de exemplos que podem ser instalados no seu servidor. Eles estão localizados sob a pasta CFDOCS. É recomendável que você NÃO instale tais exemplos no servidor de produção (servidor que fica exposto à internet). Na versão 4.5 o ColdFusion trazia, nestes exemplos, um template que permitia qualquer usuário anônimo fazer um upload (através de CFFILE) no servidor e em qualquer pasta. Isso é uma séria ameaça à segurança do seu servidor por isso não instale aquilo que você não conhece totalmente, independentemente da versão do CF ou mesmo de outros produtos. A velha máxima é a que vale: se não vai usar, não instale.

5) Desabilite o serviço RDS! Mesma coisa. Prefira outras formas de acesso ao seu servidor de produção (FTP, por exemplo). O RDS pode ser mais um dos caminhos que um malandro pode escolher para brincar com a sua máquina, por isso mesmo desligar (seja não instalando-o ou desabilitando o serviço RDS) é uma boa medida de precaução.

Por fim sempre que tiver alguma dúvida sobre segurança em suas aplicações, escreva!

Eating ColdFusion…

Este aqui sou eu, com a cabeça quase explodindo de tanta coisa para fazer.

Estou testando o FCS MX e em breve terei uma webcam online para que os desocupados de plantão (incluindo alguns do meu escritório) possam me importunar remotamente.

Aguardem novidades por aqui, prometo postá-las!

SQL Injection – você está protegido?

Caríssimos(as), em primeiro lugar gostaria de pedir desculpas pela falta de posts neste último mês. Desculpas especialmente aos leitores assíduos que escreveram cobrando atualizações. Tive um mês extremamente corrido, com muitas obrigações a cumprir sem tempo de atualizar o blog – e tocar o CFUG-SP! – mas essa é uma outra história 😉. Espero que daqui até o fim do ano as coisas fiquem mais calmas e que eu possa postar mais vezes por aqui.

Dando continuidade aos posts sobre segurança em aplicações ColdFusion, tratarei de um assunto que não envolve apenas ColdFusion, mas toda e qualquer linguagem server-side (PHP, ASP, JSP, etc). Trata-se do SQL Injection. Se você já conhece esta vulnerabilidade, a leitura é válida pois esse tipo de discussão é rara na Internet brasileira. Mas se você nunca ouviu falar a leitura é obrigatória. Terminando-a provavelmente você terá que sentar a bunda na cadeira e rever quilômetros de código inseguro que você pode ter gerado. Procurarei ser o mais suscinto possível e atacar a questão de vez, com exemplos, sem muita enrolação e apresentações. Se você ainda ficar com alguma dúvida, sugiro que poste-a na lista CF-Brasil. Eu e muitos outros programadores CF terão prazer em ajudá-lo.

SQL Injection, literalmente falando, é o ato de “injetar” código SQL não esperado numa aplicação com fins não muito amigáveis. Apenas para esquentar: você já tentou acessar uma página dinâmica dessa forma:

EXEMPLO 1
http://www.site.com.br/produtos/produto?id=77;DELETE FROM produtos

Ou ainda criou um formulário deste tipo:

EXEMPLO 2
<FORM ACTION=”http://www.servidor_atacado.com/busca.cfm” METHOD=”post”>
<INPUT TYPE=”hidden” NAME=”string_busca” VALUE=”;DROP TABLE noticias”>
<INPUT TYPE=”submit”>
</FORM>

Ou ainda pior:

EXEMPLO 3
<FORM ACTION=”http://www.servidor_atacado.com/login/logar.cfm” METHOD=”post”>
<INPUT TYPE=”hidden” NAME=”username” VALUE=”qqcoisa”>
<INPUT TYPE=”hidden” NAME=”senha” VALUE=”;AND 1=1″>
<INPUT TYPE=”submit”>
</FORM>

Se não tentou, deveria fazê-lo em suas aplicações ColdFusion (ou qualquer outra linguagem) para ver se estas estão seguras.

Note a presença de códigos SQL “extras” na aplicação. Soa alguma coisa comum à SQL? Pois é exatamente isso. Na medida em que a aplicação usa a tag <CFQUERY> para acessar o banco de dados e o faz recebendo informações (via form, url, etc) do usuário, ela pode estar vulnerável. Veja o caso do exemplo 1, onde o arquivo “produto.cfm”, faz uma chamada ao BD da seguinte forma:

SELECT * FROM noticias
WHERE NoticiaID=#url.id#

Com a injeção de código SQL teríamos:

SELECT * FROM noticias
WHERE NoticiaID=77 ;
DELETE FROM noticias

Note o ponto-e-vírgula, que é o separador de comandos para o SQL Server e Access (se não me engano). Em outros bancos de dados você poderia usar simplesmente espaço, o sinal de mais (+), etc, basta consultar. Boom! Sua tabela de notícias foi para o limbo e ai de você se não tiver backup dela. Sem falar no tempo fora do ar até restabelecer todos os serviços…

Mas o problema não se limita à apagar tabelas e ficar fazendo esse tipo de brincadeira de criança (para não usar o termo lammer). Você já pensou em criar um usuário com previlégios de administrador no BD que mantém uma determinada aplicação? Sem apagar nada, sem esforço, conectar-se e roubar o que lhe importa. Pois isso também é possível. O SQL Server, por exemplo, possui uma série de procedures que são usadas para se criar usuários, alterar senhas, aumentar o nível de acesso de determinados usuários, entre tantas outras. Não vou entrar nestes detalhes pois esse não é o objetivo deste post, porém deixo um alerta: JAMAIS configure uma datasource usando uma conta com previlégios de administrador do BD (falarei mais a respeito abaixo).

As possibilidades de ataque e roubo de informações através da técnica de SQL Injection são inúmeras e o pior disso tudo: até os melhores programadores não conhecem tal vulnerabilidade.

Muito se discute sobre a segurança de um determinado sistema operacional, fala-se que o Linux é mais seguro que Windows, fala-se que o firewall XYZ analisa melhor pacotes, que a criptografia 128 bits é “quebrável”, que o site “DamnGood.com” está imune à ataques do tipo DDoS, blá, blá, blá, e esquece-se do fundamental: a aplicação. Sim, a aplicação… àquela que todos põe a mão, àquela que é acessível pela porta 80 do TCP/IP e que tem uma redundância de 100%…. Redundância de 100% para permitir que nenhum engraçadinho fique de fora da farra… ;o)

Agora a boa notícia: o SQL Injection é uma vulnerabilidade facilmente contornável com o simples e velho CÓDIGO SEGURO. Sim, pensar em segurança (como já disse), deve fazer parte da sua rotina de programação. Você deve ter a sensibilidade suficiente para saber que está lidando com uma parte de código importante que poderá ser burlada por alguém que conheça a lógica básica de programação ou até mesmo obtenha alguma informação previlegiada. Informação priveligiada? Ué, mas para obtê-la eu não preciso invadir os sistemas de outra maneira, mais “profissional”? Talvez conseguir uma senha no banco de dados para poder ver suas tabelas, obter acesso ao código fonte do “.cfm” para saber como está estruturada uma query que desejo atacar???

Néca de catibiriba, isso é muito fácil de se obter apenas fazendo a aplicação receber valores que ela não está esperando (e torcer para que o programador seja bem descuidado também). Veja um exemplo tolo (clique no link abaixo):

http://www2.sabesabe.com.br/sejaesp_todas_sabe.cfm?id_sequencial=

No exemplo acima podemos obter, literalmente “de bandeija”, toda a informação necessária para se efetuar um ataque do tipo SQL Injection. Aqui vemos o tipo de banco de dados usado, bloco SQL, nome de tabelas, nome de campos, etc, etc. Isso dá a deixa para eu contar qual é a regra número 1 para se safar de ataques SQL Injection (e tantos outros existentes):

1) Jamais deixe amostra os erros da sua aplicação! Deslige o debug info! Estes erros interessam somente à você e a ninguém mais, por isso trate de usar tratamento de erros ou então deixar o servidor CF fazer isso por você por meio do Site-wide Error Handler;

Na seqüência algumas outras (mais diretamente aplicadas ao ColdFusion). Veja e aprenda mais com as referências que dou no final do post.

2) Valide os dados que a sua aplicação recebe. A melhor maneira de se fazer isso é através do uso de stored procedures. Se não puder usar stored procedures ou seu uso não faça sentido, use a tag <CFQUERY> com segurança! O melhor é receber e passar para o BD os valores de strings pela tag <CFQUERYPARAM>. Veja o exemplo abaixo:

SELECT * FROM noticias
WHERE NoticiaID=<CFQUERYPARAM VALUE=”#url.id#” CFSQLTYPE=”CF_SQL_INTEGER”>

Isso inclusive aumenta a performance da sua query pois o CFServer já saberá de antemão qual é o tipo de dado a ser enviado ao BD.

3) Use um user específico para cada datasource que você tem nesse servidor. Eu costumo criar, para uma mesma aplicação/banco de dados, duas datasources distinas. Nas minhas aplicações de notícias, por exemplo, eu tenho sempre o user “noticias_reader” e o user “noticias_writer”. Um poderá (com base nas permissões de acesso do próprio DB) apenas ler e o outro ler e escrever. Dessa forma terei que me preocupar em validar apenas as queries que façam alterações e inserções no BD, já que qualquer operação de alteração ou deleção “forçada” na primeira datasource será negada pelo banco de dados. Em sites abertos ao público, temos tipicamente apenas operações de leitura de dados. Já a alteração/inserção ocorre em sistemas internos (os famosos “admins”), o que já elimina uma camada de vulnerabilidade. Mas mesmo assim SEMPRE VALIDE as entradas de dados da sua aplicação;

4) Jamais use uma conta com previlégios de administrador para conectar-se ao banco de dados (a conta sa do MSSQL, por exemplo). Além de tornar a sua aplicação/vulnerável, você poderá estar comprometendo TODO um sistema. O mesmo é válido para a “trusted connection”. Normalmente a conta usada nesse tipo de autenticação é a de Administador.

5) Para finalizar, a velha máxima: “Quando tudo mais falhar, tenha sempre um backup em mãos… ” ;o)

Abaixo segue alguns links interessantes sobre o assunto (agradeço pelos comentários de Rui Dias Quintino). Leia-os para se saber melhor. Lembre-se de que o seu pescoço – e o seu emprego por tabela – está em jogo em se tratando de segurança!!

O bom e velho Google e seus resultados maravilhosos…
Uma coletânea de 18 mil referências ao assunto.

Guesswork Plagues Web Hole Reporting
Uma das últimas vítimas de um ataque deste tipo. Resultado: acesso indevido à base de dados de clientes da Guess (incluindo 200.000 números de cartões de crédito).

SQL Injection Whitepaper – Spi Dynamics
Bastante completo. Para começar.

Advanced SQL Injection in SQl Server Applications
Direccionado apenas para o SQL Server, que como por esta altura já devem saber é uma aplicação extremamente sensível neste campo.

Guarding your Web Site against SQL Injection Attacks
Depois de ler os anteriores talvez este não acrescente muito. Fortemente ligado à plataforma Microsoft.

SQL Injection FAQ
Um FAQ bem resumido, para aqueles que não têm muito tempo.

OWASP – Open Web Application Security Project (Direct SQL Command Injection)
Um dos melhores sites a este nível. E sendo assim não podia deixar de mencionar este tipo de vulnerabilidades.

SQL Injection Walkthrough
Mais um que apanhei no SecurityTeam.