As “vilãs” CFOBJECT e CreateObject()

Hoje na lista CF-Brasil surgiu um assunto interessante sobre o porquê de algumas tags serem desabilitadas em provedores hospedagem compartilhada ColdFusion, especialmente a tag CFOBJECT e a função CreateObject(). Re-posto aqui a minha mensagem para a lista.

Na verdade poucos sabem, até porque a maioria dos provedores de hospedagem não configura seus servidores corretamente, mas a tag CFOBJECT e a sua função correlata CreateObject não deve ser habilitada numa hospedagem compartilhada ColdFusion MX (mesmo aquelas que fazem uso de sandbox security) por oferecer riscos às aplicações que ali residem. Os riscos vão desde manipulação de variáveis de uma aplicação qualquer até o acesso a datasources e arquivos (“sandboxeados” ou não). Deixando estas tags habilitadas o servidor torna-se um prato cheio para indivíduos mal intencionados e que conheçam um pouco mais a fundo o runtime do CFMX e da própria plataforma Java. Não se compara com a facilidade de se manipular e abusar do servidor com CFFILE sem sandbox security configurado (o que muitos ainda fazem), mas é bastante real e possível. Isso é um prato cheio para discussões em listas de fora e blogs de especialistas, dê uma googlada sobre o assunto que você terá muitos resultados, incluindo scripts para quem quiser brincar e conferir o que estou dizendo.

Em ambiente compartilhado (mesmo com sandbox security ativada) todos os “sites” do CFMX compartilham uma mesma instância do Java Machine (JVM). Desta maneira uma série de informações que deveriam ser exclusivas de uma determinada aplicação/site ficam expostas para consulta e alteração por todos os usuários que “habitam” aquela mesma instância de JVM (no caso do CFMX de todos os sites usando esta tecnologia). Para exemplificar, confira o script abaixo, que permite a visualização (e alteração se você quiser) de um enorme repositório de informações sensíveis do CFMX:

Em versões CFMX 6.0 pré SP1 era possível descobrir a senha do administrator com um simples scriptzinho. A Macromedia foi “tapando os buracos” aos poucos, mas de uma maneira que o pessoal costuma chamar “security by obscurity”, ou seja, escondendo a brecha mas não eliminando-a por completo. A coisa não se restringe somente ao próprio servidor CF, mas às aplicações rodando em todo o servidor. Você pode alterar variáveis, conhecer seus valores (ex: variáveis de sessão armazenando dados sensíveis como cartões de crédito etc) e por aí vai. Este é um defeito (minha opinião) da plataforma JRun e há tempos a Macromedia não corrige ou altera isso, apesar dos inúmeros pedidos da comunidade. Deve ser algo difícil por ser estrutural e inerente ao produto.

Desta maneira a única maneira de se hospedar CFMX de forma completa (sem limitação de tags) e totalmente segura e em ambiente “compartilhado” é criar multiplas instâncias de CFMX (mais conhecido como CFMX for J2EE, configuração presente na nova versão Enterprise do 6.1), seja sob o JRun (nativo) ou sob outro servidor J2EE. O problema é que cada instância terá a sua JVM exclusiva e isso consome muito mais recursos do servidor, limitando o número de contas que podem ser adicionadas à máquina (umas 50-100 contas para um servidor P4 (single CPU) com 1-2Gb de RAM num chute, imaginando o consumo de uns 30-40 Mb por cada instância/jvm, tal como a Macromedia teoriza). Trata-se de uma hospedagem “semi-dedicada” por assim dizer e por isso não devemos encará-la como “compartilhada”.

A dobradinha JBoss/TomCat (Apache), por exemplo, permite isolar aplicações de forma completa compartilhando uma única JVM. Porém o CFMX com TomCat ainda não é oficialmente suportado (veja este technote e este artigo) pela Macromedia. Dessa maneira torna-se um setting mariginal, difícil de garantir que vai rodar numa boa, inclusive com upgrades do CFMX, apesar de ser tecnicamente possível. Quem sabe no futuro?

Concordo que é um GRANDE limitador para a tecnologia e esta é a minha maior crítica ao servidor CFMX (leia o meu guia de configuração de sandboxes para ambiente compartilhado em CFMX), mas se você for parar para pensar, há muita coisa boa que pode ser feita (inclusive mimetizar orientação à objetos com CFCs) sem usar esta tag/função. A idéia é: uma hospedagem ColdFusion é uma hospedagem ColdFusion, ponto final. Não é uma hospedagem Java ou similar, apesar do CF suportar nativamente isso.

Com relação as outras restrições tratam-se de questões de performance e/ou de segurança menores (leia as minhas considerações no tal guia). Você pode, sozinho, degradar muito a performance do servidor inteiro se inventar moda de indexar a cada segundo seus índices Verity, ou então “schedular” 200 scripts CFM de 400K e mais cem queries para rodar a cada segundo… sim, tem “programadores” com esta capacidade…. E isso não é exclusivo do CF, em qualquer outra tecnologia temos estes problemas em ambientes compartilhados.