Melhorias para sandbox security no CFMX 7

Uma das mudanças positivas em termos de segurança que o CFMX 7 trouxe foi a divisão das permissões de acesso à tag CFOBJECT e à função CreateObject(). Nas versões anteriores do servidor esta tag e função deveriam ser desabilitadas para maior segurança em ambientes compartilhados (mesmo usando-se sandbox security) devido à possibilidade de se acessar dados e configurações sensíveis do servidor via Java API. Este é um assunto exaustivamente comentado aqui no CFGIGOLO e em listas de discussão como a CF-Brasil, inclusive com críticas, que quase sempre esbarram na dificuldade de se encontrar um bom provedor de hospedagem ColdFusion no Brasil que ofereça todos os recursos e ao mesmo tempo seja responsável. Uma das maiores críticas à restrição desta tag e função vem do fato de que a função CreateObject() é frequentemente usada para invocar componentes ColdFusion (CFCs) e webservices que são nativos em inúmeras aplicações e também em frameworks famosos tais como o Mach-II e afins.

Pois eis que no CFMX7 a Macromedia encontrou uma maneira de granular o acesso/proibição a esta tag/função, permitindo que se libere o uso de CFOBJECT e CreateObject() com base no tipo de invoke que será feito, que são divididos basicamente em: COM, Java, ColdFusion (CFCs) e Webservices. Com isso poderemos encontrar, numa sandbox (sob a orelha “CF Functions”), quatro opções de enable/disable para CreateObject() ao invés de apenas uma, como antigamente. São as opções “CreateObject(COM)”, “CreateObject(Java)”, “CreateObject(Webservices) e “CreateObject”, esta última que diz respeito somente à CFCs. Na orelha “CF Tags” existe apenas uma opção de CFOBJECT, como antigamente, porém esta é subordinada/obedece o que está determinado na orelha “CF functions”. Entenda: ao se habilitar a tag CFOBJECT, ela só poderá invocar componentes Java, COM ou outros se isso estiver explicitamente permitido através da função CreateObject(Java) e/ou CreateObject(COM) na orelha “CF functions”. O release notes do CF7 explica: “Note: Turning off access to Java, COM, or Web Service objects through the CreateObject function also turns off access through the cfobject tag.”

É uma mudança extremamente bem vinda, que queriamos há tempos. Fiz barulho, batuque de panela e questão de votar como enhancement desejado ainda no programa Alpha 1 do Blackstone, quando eram poucos (ou nenhum) brasileiros pé-rapados e que dependem de hospedagem compartilhada (como eu) participando. Vale lembrar que depois de adotado a melhoria, houve também a correção de um bug importante já no RC, poucos meses atrás, que com a ajuda de vocês foi resolvido. É uma mudança bem vinda especialmente para provedores que não podem oferecer hospedagem do tipo múltipla instância (recurso também melhorado no CFMX7) e que com este enhancement poderão agora resolver 80% da chiadeira dos seus clientes com a proibição ao uso de CreateObject() e CFOBJECT.

E os 20% restantes? Bem, eu sempre fui da opinião de que se você quer usar Java, deve usar Java, se quer usar ColdFusion, use ColdFusion. Misturar os dois é possível? Claro que sim, além de ser altamente recomendável, mas eu pergunto: quais aplicações, das do tipo que são hospedadas em ambiente compartilhado, requerem uso da complexidade de recursos da API do Java ou de componentes COM? Vale notar que componentes COM nem são tão perigosos assim em termos de segurança. Seu invoke via CFMX é relativamente tranquilo pois os componentes podem ser protegidos ad hoc (componente à componente), diferente do que acontece com a API Java, mais difícil, do ponto de vista do CFMX, de se bloquear o uso irrestrito (afinal, o CFMX é uma aplicação Java e precisa acessá-la por inteiro). Oras bolas, o que a API Java tem a oferecer para uma pequena aplicação (que é hospedada num servidor compartilhado) em termos de recursos que não manipular imagens, arquivos e outras firulas do tipo? IMHO estas funções básicas podem ser mimetizadas perfeitamente apenas com os próprios recursos oferecidos pela CFML. Invocar custom tags JSP? Claro que sim! Mas via CFIMPORT por favor… não via CreateObject().

Muita gente chia por ter o Java “bloqueado” no CFMX, mas eu estou para ver quem usa o Java com CFML pra valer, em coisas que não podem ser suplantadas por CustomTags ou CFML puro. Sua aplicação CFML vai invocar EJB? Servlets? Será que é este o tipo de aplicação que se encontra em uma hospedagem compartilhada? Muito raro e difícil, quando acontece a aplicação ou site tem uma importância e tamanho que não justificam sua hospedagem em um ambiente compartilhado tradicional. Por isso deixe de ser muquirana e contrate uma hospedagem dedicada se este for o caso… Enquanto isso viva as melhorias do CFMX 7. 😉

Variáveis locais à funções

Variáveis locais de funções são variáveis que existem apenas dentro da função, não existindo na página que chamou a função. Dessa maneira, não só a memória é gerenciada de melhor maneira, como também as variáveis da função não interferem nas da página que a chamou, a vice-versa.

Variáveis locais são criadas com a palavra-chave var:

var valor = 3; //dentro de um bloco CFSCRIPTou
<CFSET VAR valor="3">

Ao criar UDFs, é comum (e recomendado), já declarar todas as variáveis que você irá utilizar no início da função, com a devida palavra-chave var. Aliás, declaração de variáveis locais só podem ser no início da função.

O problema é que muitas pessoas – inclusive eu – esquecem de declarar como variáveis locais as variáveis de loops!

Veja o código abaixo:

for(i=1; i LTE 13; i=i+1) {
thisDigit = mid(thisCNPJ, i, 1);
somaDigitoDois = somaDigitoDois + thisDigit * aMultipliers[i];
}

O código é parte da função CNPJvalidate() e cria uma nova variávei i. Se já existir uma variável i na página que a chamou, o valor desta será sobreposto pelo novo valor setado nesse loop. O correto seria, no início da função já declarar a variável i, mesmo que com qualquer valor.

Em tempo: as funções CNPJvalidate() e CPFvalidate() já foram atualizadas. 🙂

Ah, e não posso esquecer de dar parabéns ao nosso mais novo milionário!