Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla

ESCOLA SUPERIOR ABERTA DO BRASIL – ESAB
CURSO DE PÓS-GRADUAÇÃO LATO SENSU EM
ENGENHARIA DE SISTEMAS
JÚLIO CÉSAR DE PAULA COUTINHO
PROCESSO DE TESTES DE VULNERABILIDADES EM
COMPONENTES MVC PARA CMS JOOMLA
VILA VELHA – ES
2011

Monografia apresentada ao Curso de
Pós-Graduação em Engenharia de
Sistemas da Escola Superior aberta do
Brasil como requisito para obtenção do
título de Especialidade em Engenharia
de Sistemas, sob orientação do Prof.
Ms. Cleyverson Pereira Costa.
VILA VELHA – ES
2011

Monografia aprovada em .. de 2011.
Banca Examinadora
VILA VELHA – ES
2011

A minha esposa Rosana e meu filho
Bruno pelo apoio e paciência
demonstrados em todos os momentos
desta minha caminhada.

AGRADECIMENTOS
À Deus pela oportunidade da vida,
saúde e vontade de aprender, a minha
família pelo apoio e paciência.

“O ditado de que os sistemas de
segurança têm de vencer sempre e o
atacante só tem de vencer uma vez é
verdadeiro.”
(Dustin Dykes)

RESUMO
Palavras-chave: Desenvolvimento de extensões, CMS Joomla, Vulnerabilidades em
componentes
Este estudo tem objetivo demonstrar as fases de desenvolvimento de um componente
MVC para o CMS Joomla com ênfase nas vulnerabilidades mais comuns, tipos de
ataques e formas de proteção extras a serem empregadas em componentes e
websites desenvolvidos em Joomla! A facilidade de uso e baixa curva de
aprendizagem exigida pelo CMS, levam o usuário a crer na facilidade de desenvolver
componentes MVC para o mesmo, ignorando a necessidade de grande conhecimento
técnico para tal empreendimento. Invasões em websites joomla, seja através de
componentes vulneráveis, seja através de templates piratas, ou ainda pelo uso de
provedores desatualizados e permissões inadequadas, enfraquecem o projeto e
prejudicam a comunidade como um todo, o enfraquecimento de projetos open source
acabam por fortalecer projetos de código-fonte fechados. Componentes MVC bem
desenvolvidos, seguindo preceitos de segurança, aliados ao uso de templates
qualificados e a escolha de provedores idôneos, com aplicação correta das
permissões em diretórios e arquivos minimizam consideravelmente o risco de ataques
bem sucedidos. Este conjunto de fatos resulta em credibilidade para a marca Joomla!
como um todo possibilitando desta forma um ganho real para toda a sociedade e
comunidade Joomla! em geral.

LISTA DE FIGURAS
Figura 1 – Camadas do CMS Joomla!..........................................................30
Figura 2 – API do CMS Joomla! Fonte: http://docs.joomla.org/, (2009)........34
Figura 3 – Classe JFACTORY Fonte: http://docs.joomla.org/, (2009) ..........35
Figura 4 – MVC Fonte: http://pt.wikipedia.org/wiki/MVC, (2011) ..................42
Figura 5 – Classe JModel) Fonte: http://docs.joomla.org/, (2009) ................44
Figura 6 – Classe JView) Fonte: http://docs.joomla.org/, (2009) ..................45
Figura 7 – Classe JController Fonte: http://docs.joomla.org/, 2009 ..............46
Figura nr 8 – Instanciando o BD Fonte: autoria própria (2011).....................47
Figura nr 9 – executando consulta Fonte: autoria própria (2011) .................47
Figura 10 – Executando a consulta Fonte: autoria própria (2011)................47
Figura 11 – apresentação de resultados Fonte: autoria própria (2011)........48
Figura 12 – resultado em array) Fonte: autoria própria (2011) .....................48
Figura 13 – Query completa Fonte: autoria própria (2011)...........................48
Figura 14 – query para atualização Fonte: autoria própria (2011)................49
Figura 15 – Método getEscaped Fonte: autoria própria (2011) ....................50
Figura nr 16 – Método geNullDate Fonte: autoria própria (2011) .................50
Figura nr 17 – Método getNullRows Fonte: autoria própria (2011)...............50
Figura nr 18 – Método getErrorNum) Fonte: autoria própria (2011) .............51
Figura 19 – Parte do código-fonte do arquivo joomla.php Fonte: autoria
própria (2011) ...............................................................................................54
Figura nr 20 – continuação código-fonte joomla.php Fonte: autoria própria
(2011) ...........................................................................................................55
Figura 21 – parte do código-fonte do arquivo helper.php Fonte: autoria
própria (2011) ...............................................................................................56

Figura 22 – Formulário para inserção de dados em componente MVC via
backend Fonte: autoria própria (2011)..........................................................60
Figura nr 23 – Tipo de ataque CSRF Fonte: http://www.google.com/images/,
(2011) ...........................................................................................................68
Figura nr 24 – Defacement Fonte: http://www.google.com/images/, (2008).68
Figura 25 – Iniciando o backtrack em máquina virtual..................................72
Figura 26 – Backtrack pronto para uso em máquina virtual Fonte: autoria
própria (2011)...............................................................................................73
Figura nr 27 – A aplicação é a ponta do iceberg Fonte: autoria própria (2010)
......................................................................................................................77
Figura 28 – JRoute Fonte: autoria própria (2011).........................................85
8.8.3 Verificando o Token.............................................................................85
Figura nr 29 – JRequest Fonte: autoria própria (2011).................................85
Figura 30 – JRequestGet Fonte: autoria própria (2011) ...............................85
Figura 31 – $_Get[] Fonte: autoria própria (2011) ........................................88
Figura 32– SQLInjection Fonte: autoria própria (2011).................................88
Figura nr 33 – String SQLInjection Fonte: autoria própria (2011) .................89
Figura nr 34 – String SQLInjection Fonte: autoria própria (2011) .................89
Figura 35 – String Request Fonte: autoria própria (2011) ............................90
Figura 36 – String HmtlSpecial Fonte: autoria própria (2011).......................90
Figura nr 37 – JEXEC Fonte: autoria própria (2011) ....................................91

LISTA DE SIGLAS
JOOMLA! – Sistema Gerenciador de Conteúdos Open Source distribuído sob licença
GNU/GPL cuja pronúncia correta é “DJUMLA!”
LAMP – Linux Apache Mysql PHP
CMS – Sistema Gerenciador de Conteúdos
WEBDESIGN – Projeto para Web
WEBSITE – Conjunto de páginas relacionadas a determinada instituição ou pessoa
codificada em linguagem de marcação de texto ou linguagem de programação para a
web, renderizadas por um navegador
BROWSER – Navegador Web
MVC – Padrão de projeto de desenvolvimento de software que divide as camadas em
Modelo Visão e Controlador
HACKER – usuário com grande conhecimento em informática geralmente aplicado
para o bem comum
CRACKER – usuário com grande conhecimento em informática geralmente aplicado
para o mal através de invasões em sistemas web com intuito de furto de dados
sensíveis pessoais e corporativos

SCRIPTKIDDIES – usuários novatos que buscam na internet informações úteis para
invadir websites e sistemas em busca de reconhecimento
HASH – impressão digital usada em criptografia de senhas
FORK – Separação, briga
TOKEN – Chave para acesso a ambiente seguro
LDAP – Servidor de acesso muito utilizado em intranet

SUMÁRIO
1. INTRODUÇÃO ......................................................................................................16
1.1 PALAVRAS-CHAVE ..................................Erro! Indicador não definido.
1.2 EXPOSIÇÃO DO ASSUNTO..................................................................17
1.3 PROBLEMA DE PESQUISA ..................................................................18
1.4 JUSTIFICATIVA......................................................................................18
1.5 OBJETIVOS............................................................................................19
1.5.1 Geral ...................................................................................................19
1.5.2 Específicos.........................................................................................19
1.7 METODOLOGIA DE PESQUISA............................................................20
2. FUNDAMENTAÇÃO TEÓRICA............................................................................21
2.1 WEBDESIGN..........................................................................................21
2. 2 CMS.......................................................................................................21
2. 3 HISTÓRICO DO CMS JOOMLA!...........................................................23
2. 4 VERSÕES DO CMS JOOMLA! .............................................................24
2.5 JOOMLA! NO MERCADO WEB .............................................................25
2. 6 QUEM USA JOOMLA!...........................................................................26
2. 7 JOOMLA! E O WEBDESIGNER............................................................26
2. 8 EXTENSÕES PARA JOOMLA! .............................................................28
2.9 SEGURANÇA E JOOMLA!.....................................................................28
3. JOOMLA! FRAMEWORK.....................................................................................30
3.1 CAMADA APLICATIVO ..........................................................................31
3.2 CAMADA EXTENSÕES .........................................................................32
3.3 FUNCIONAMENTO DO FRAMEWORK .................................................32

4. JOOMLA! API.......................................................................................................34
4.1 JFACTORY.............................................................................................35
4.1.1 Método Getacl....................................................................................35
4.1.2 Método Getapplication......................................................................36
4.1.3 Método Getcache...............................................................................36
4.1.4 Método Getconfig ..............................................................................37
4.1.5 Método Getdbo ..................................................................................37
4.1.6 Método Getdocument........................................................................37
4.1.7 Método Geteditor...............................................................................38
4.1.8 Método Getlanguage .........................................................................38
4.1.9 Métdod Getmailer ..............................................................................39
4.1.10 Método Getsession..........................................................................39
4.1.11 Método Gettemplate ........................................................................39
4.1.12 Método Geturi ..................................................................................40
4.1.13 Método Getuser ...............................................................................40
4.1.14 Método Getxmlparser......................................................................41
5. DESENVOLVIMENTO DE COMPONENTE MVC.................................................42
5.1 O MODELO (MODEL) ............................................................................42
5.2 A VISÃO (VIEW).....................................................................................43
5.3 O CONTROLADOR (CONTROLLER) ....................................................43
5.4 CLASSES UTILIZADAS NA IMPLEMENTAÇÃO DE COMPONENTES
MVC..............................................................................................................44
5.4.1 JModel ................................................................................................44
5.4.2 JView ..................................................................................................44
5.4.3 JController..........................................................................................45
5.4.4 JDATABASE.......................................................................................46

5.4.4.1 Consultas com JDATABASE......................................................47
5.4.4.2 Atualizações de registros com JDATABASE.............................49
5.4.4.3 Outros recursos do objeto JDATABASE ....................................49
5.4.4.3.1 getEscaped()...........................................................................49
5.4.4.3.2 getNullDate() ...........................................................................50
5.4.4.3.3 getNumRows() ........................................................................50
5.4.4.3.4 getErrorNum();...............................................................................50
5.5 FERRAMENTAS CASE PARA O DESENVOLVIMENTO DE
COMPONENTE MVC...................................................................................51
5.5.1 Aptana ................................................................................................51
5.5.2 Alphaplug ...........................................................................................51
5.5.3 GEPAC................................................................................................52
5.6 Tipos de componentes MVC................................................................52
5.7 Falhas de segurança no componente, encontradas na fase de testes
......................................................................................................................52
5.8 Criptografia das senhas no Joomla!...................................................54
5.8.1 Joomla.php.........................................................................................54
5.8.2 getCryptedPassword.........................................................................55
5.8.3 HASH ..................................................................................................57
5.8.4 MD5.....................................................................................................58
5.9 Formas de correção das falhas encontradas.....................................58
6. VULNERABILIDADES E DEFACEMENT’S .........................................................60
6.1 SQL INJECTION ....................................................................................61
6.2 Campos de texto em formulário sem filtragem..................................62
6.3 Manuseando campos de texto em Formulário com PHP ..................63
6.3.1 Tipos não esperados.........................................................................64
6.4 CROSS-SITE SCRIPTING (XSS)...........................................................65

6.5 Directory Scanning...............................................................................67
6.6 CROOS-SITE REQUEST FORGERY (CSRF) .......................................67
6.7 Defacement ...........................................................................................68
7. TESTES DE PENETRAÇÃO ................................................................................70
7.1 Teste caixa preta...................................................................................71
7.2 Teste caixa branca................................................................................71
7.3 Testes de vulnerabilidades em componente MVC.............................71
7.4 Bactrack ................................................................................................71
7.5 Nikto.......................................................................................................73
7.6 ZeroDayscan .........................................................................................73
7.7 OWASP ..................................................................................................74
7.7.1 Requisitos e funcionamento do OWASP.........................................74
8. MELHORES PRÁTICAS PARA EVITAR INVASÕES ..........................................77
8.1 O provedor de hospedagem ................................................................78
8.2 Instalação automática do Joomla! ......................................................78
8.4 URL’s amigáveis...................................................................................80
8.5 Aplicação correta das permissões......................................................80
8.6 Atualização da versão do CMS............................................................83
8.8 Protejam-se de ataques CSRF.............................................................84
8.8.1 POST...................................................................................................84
8.8.2 GET .....................................................................................................84
8.8.3 Verificando o Token ..........................................................................85
8.8.4 Procedimentos complementares .....................................................85
8.9 Validação de campos nos formulários de componentes..................86
8.9.1 Validação de campos no lado cliente ..............................................87
8.9.2 Validação de campos no lado do servidor ......................................87

8.9.3 Validação de formulário contra SQL Injection ................................87
8.9.4 Validação de formulários contra ataques XSS................................89
8.10 Validação do nível de permissão dos usuários ...............................90
8.11 Segurança na programação de componente MVC ..........................90
CONCLUSÃO ...........................................................................................................93
REFERÊNCIAS BIBLIOGRÁFICAS.........................................................................96

1. INTRODUÇÃO
O presente trabalho abordará o tema Processo de Testes de Vulnerabilidades em
Componentes MVC para CMS Joomla.
O problema consiste em demonstrar que componentes em desacordo com os
padrões de projeto MVC e boas práticas de segurança, podem facilitar invasões a
websites desenvolvidos com CMS Joomla!
O desenvolvedor deve preocupar-se em testar o seu componente contra os tipos de
ataques mais conhecidos, fazendo uso de aplicativos e técnicas utilizadas em testes
de penetração, escaneamento de servidores e aplicativos, não se esquecendo de
validar todos os campos de entrada em formulários.
A invasão de websites desenvolvidos em CMS Joomla! são em sua grande maioria
possíveis através de falhas no servidor de hospedagem, porém, é crescente o
número de ataques do tipo code injection realizados via extensões vulneráveis.
Independente da causa que possibilitou a efetivação do ataque, um website invadido
prejudica não só o projeto, mas toda a comunidade que utiliza o CMS Joomla!
1.2 EXPOSIÇÃO DO ASSUNTO
Este trabalho aborda testes de vulnerabilidades em componente MVC desenvolvido
para o CMS Joomla!

1.3 PROBLEMA DE PESQUISA
Qual a relação das vulnerabilidades no desenvolvimento de componente MVC para
o CMS Joomla com invasões sofridas em websites com o CMS?
1.4 JUSTIFICATIVA
Com o fortalecimento do “software livre” produtos de excelente qualidade estão
disponíveis, particularmente para o mercado web. Sistemas de Gerenciamento de
Conteúdos são programas que auxiliam no desenvolvimento de um webdesign
seguindo os conceitos previstos na Web 2.0. O CMS Joomla! destaca-se por sua
facilidade de uso e baixa curva de aprendizagem, tendo sido adotado pela maioria
dos Órgãos do Governo Federal. As extensões utilizadas pelo CMS Joomla são
classificadas em componentes, módulos, plugins e templates, cada uma com sua
função específica e requisitos prévios obrigatórios. O desenvolvimento de um
componente é processo extremamente técnico que exige conhecimento em
programação orientada a objetos e observância na utilização de padrões de projeto
MVC. Entretanto, muitos desenvolvedores criam novas soluções utilizando a
programação procedural ou mesmo, deixam de testar e validar os campos de
entrada de dados de suas extensões, abrindo uma brecha perigosa na segurança do
CMS Joomla! Com popularização da Internet e o advento das mídias sociais,
diminui-se consideravelmente o tempo de resposta a boatos e situações impostas.
As empresas e instituições precisam possuir um website ou portal de qualidade,
integrado às mais importantes mídias sociais, sob pena de verem suas marcas e
reputações manchadas pelos boatos da rede. Mais do que 24/7, os projetos web
devem prover 24/7/365. No quesito desenvolvimento web, o CMS Joomla! com seu
poder de extensibilidade é a melhor opção open source do mercado.

1.5 OBJETIVOS
1.5.1 Geral
Descrever um processo de análise de testes de vulnerabilidades no
desenvolvimento de componente MVC para o CMS Joomla.
1.5.2 Específicos
 Demonstrar o desenvolvimento de um componente MVC para Joomla;
 Descrever as principais vulnerabilidades existentes;
 Demonstrar falhas de segurança no componente, encontradas na fase de
testes;
 Demonstrar formas de correção das falhas encontradas.
1.6 DELIMITAÇÃO DO TRABALHO
Demonstrar as fases do processo de desenvolvimento de um componente MVC
para o CMS Joomla, explorar as principais falhas de segurança e melhores práticas,
para evitar o sucesso de possíveis ataques de crackers.

1.7 METODOLOGIA DE PESQUISA
Quanto ao objetivo será utilizada a metodologia de pesquisa do tipo Exploratório-
Descritiva e a técnica a pesquisa bibliográfica.
Análise dos dados coletados através da lista oficial de componentes vulneráveis do
projeto Joomla, lista de websites que sofreram ataques do tipo defacement
disponível no website H-Zone, leitura e consulta à livros especializados no
desenvolvimento de extensões MVC e segurança para a Web e websites
especializados no assunto, na rede mundial de computadores (INTERNET).

2. WEBDESIGN, CMS E JOOMLA
2.1 WEBDESIGN
O webdesign sempre foi relegado à segundo plano nas Instituições Governamentais
e Empresas Privadas. Via de regra, ficava à cargo do “menino do site” a
incumbência de desenvolver o website ou portal corporativo. Entretanto, os websites
deixaram de ser apenas folders decorativos e passaram a ser “vetores” de
informação em tempo real.
É praticamente impossível pensar em websites sem acesso a banco de dados, o
velho website estático com HTML puro está praticamente extinto e o webdesigner
fica em situação difícil dependendo do “amigo programador enrolado” para
desenvolver os códigos relacionados à programação. Não cabe ao webdesigner
desenvolver código e sim atender aos requisitos levantados em relação a
usabilidade, acessibilidade, persuasão e política de webmarketing do projeto,
traduzidos no design de página, design de site, design de conteúdo e design de
navegação.
Segundo Nielsen (2000), Qualquer empresa que torne seu site fácil de usar terá
uma grande vantagem sobre seus concorrentes, independente do setor em que se
encontra.
2.2 CMS
O significado de CMS é Content Management System ou simplesmente Sistema
Gerenciador de Conteúdos. O CMS é um framework, que possui todos os insumos
necessários para o desenvolvimento de um webdesign. Todas as etapas do

processo são implementadas com a utilização do CMS. O design de página e design
de site ficam a cargo do template que é a camada de visão. O design de conteúdo é
o foco principal do CMS, permitindo um gerenciamento rápido e simples, possível a
qualquer pessoa com o mínimo de conhecimento em um editor de texto.
O CMS pode ter suas funcionalidades extendidas com a utilização de programas
específicos que permitem acoplar ao projeto, determinada função que até então não
existia no mesmo. Por exemplo, um álbum de fotos.
Existem vários projetos relacionados a CMS, disponíveis sob licença GNU/GPL,
destacando-se: Joomla, Drupal e Xoop’s.
Segundo Memória (2006), Projetos sérios para a Internet são essencialmente
multidisciplinares, envolvendo diferentes áreas do conhecimento. A presença de
profissionais especializados em diferentes disciplinas está cada vez maior nos dias
atuais e o webmaster, ou faz tudo, morreu.
Mas será essa realmente a realidade do mercado brasileiro? Quantos websites
sérios e de sucesso foram desenvolvidos pelo faz tudo, ou simplesmente freela?
As produtoras resistiam em utilizar ferramentas gratuitas para seus clientes com
receio de encolher o valor do produto final que ofereciam. Mas o mercado valoriza
soluções open source, sempre em evolução.
Arquitetos, analistas e gerentes estão restritos a instituições governamentais,
grandes agências e empresas que podem manter um time de desenvolvimento
multidisciplinar. Projetos de médio e pequeno porte são desenvolvidos por agências
menores que não possuem a estrutura multidisciplinar ideal.

Os Gerenciadores de Conteúdos, ou CMS, ressuscitaram e trouxeram de volta ao
mercado, com força total, a figura do webmaster, ou faz tudo. A pequena curva de
aprendizagem da maioria dos CMS permite que em pouco tempo sejam
desenvolvidos projetos profissionais, seguros e dinâmicos. Porém, se o escopo é o
desenvolvimento de novas funcionalidades ou layouts gráficos, conhecidos por
templates, será exigido do profissional, conhecimentos relacionados a programação
orientada a objetos, banco de dados, webdesign, webmarketing e noções de
sistemas operacionais.
2.3 HISTÓRICO DO CMS JOOMLA!
Joomla! (pronuncia-se djumla) é a transcrição fonética para a palavra Swahili
"Jumla", que significa "todos juntos" ou "sob a forma de um todo".
Esta palavra Swahili é de origem Árabe, usualmente entendida como "Total" ou
"soma" e devido à influência dos comerciantes árabes está presente em outros
idiomas.
É um CMS “open Source”, distribuído gratuitamente, que funciona com a tecnologia
LAMP (Linux Apcahe Mysql PHP). Infelizmente carece, enquanto a maioria dos
projetos desenvolvidos sob a ideologia do “Software Livre, de uma documentação
robusta e organizada. Na maioria das vezes a própria comunidade é quem busca
documentar o projeto.
Originou-se de uma briga entre os desenvolvedores do CMS Mambo e a empresa
Miro, detentora da patente, quando a mesma decidiu criar uma fundação e de certa
forma restringiu o acesso ao código-fonte.

O projeto Joomla é mantido pela Open Source Matters, Inc. (OSM), uma
organização sem fins lucrativos, constituída nos termos da lei dos Estados Unidos e
do estado de Nova York. Oferece apoio organizacional, legal e financeiro para o
projeto. A OSM foi criada para garantir que o projeto Joomla possa continuar
existindo no futuro independentemente da participação de voluntários individuais.
2. 4 VERSÕES DO CMS JOOMLA!
A primeira versão do Joomla, a 1.0, surgiu no ano de 2005 causando apreensão e
perspectiva na comunidade tendo em vista a situação política do momento aliada ao
fato de que o seu código-fonte mantinha todas as características do Mambo.
Joomla! 1.5 foi lançado em janeiro de 2008 rompendo de vez com o Mambo através
da implantação de um modelo orientado a objetos, seguindo padrões de projeto
MVC, Factory e etc... e com override de template, característica que o tornou digno
de um CMS dentro dos padrões da Web2.0.
Em janeiro de 2011 foi lançada a nova versão do CMS, a 1.6, com grandes
novidades e melhorias em relação as anteriores:
 Uma nova “ACL” foi disponibilizada permitindo ao desenvolvedor a criação de
níveis e grupos;
 O gerenciamento de conteúdos foi simplificado com a exclusão das seções,
que hierarquicamente, burocratizavam o uso do CMS;
 A opção de websites em vários idiomas de forma nativa, sem a necessidade
do uso de extensões de terceiros é outra melhoria considerável; e
 O gerenciamento do tempo de publicação dos módulos era algo a muito
esperado pela comunidade.

O lançamento do Joomla! 1.7 está previsto para julho de 2011 e em 2012 deverá ser
lançada a versão 1.8 do CMS.
2.5 JOOMLA! NO MERCADO WEB
Existem vários CMS open source que usam a mesma tecnologia (LAMP) disponíveis
no mercado, dentro eles podemos citar:
 Drupal;
 Xoop's;
 Wordpress;
 Moodle;
 Magento.
Os principais concorrentes do Joomla no mercado são Drupal e Xoop's, tendo em
vista que os dois atuam no gerenciamento de conteúdo voltado a websites e portais.
Muitas pessoas confundem e até mesmo comparam Wordpress com Joomla, mas, é
preciso lembrar que o Wordpress é um excelente CMS voltado ao gerenciamento de
“Blogs”.
Moodle é um CMS voltado ao ensino à distância “EAD” modalidade E-Learning com
várias opções de provas, questionários e interatividade acadêmica.
Magento tem o foco em e-commerce “b2-c” ou “b2-b”.
O grande diferencial do CMS Joomla em relação a todos os outros, sem dúvida, é a
comunidade atuante em toda a parte do mundo, através de seus mais de 400.000

usuários do fórum em diversos idiomas, 147 JUG'S (Grupo de Usuários) pelo mundo
afora, organizando o evento oficial Joomla! Day, postando artigos na Joomla!
Magazine, participando do Joomla! People.
O CMS Joomla foi premiado diversas vezes, venceu o Best PHP Open Source
Content Management System em 2007 e desde então firma-se enquanto melhor
CMS open source do mercado.
2.6 QUEM USA JOOMLA!
O CMS Joomla vem sendo utilizado em larga escala por grandes empresas e
instituições governamentais, dentre elas podemos citar:
 Danone;
 Porsche do Brasil;
 Ministério da Educação;
 Departamento de Segurança da Informação e Comunicações da Presidência
da República;
 Ministério da Defesa;
 Exército Brasileiro;
 Aeronáutica;
 Marinha.
2. 7 JOOMLA! E O WEBDESIGNER
O CMS Joomla! É uma web app multiplataforma com baixa curva de aprendizagem,
que permite que qualquer pessoa sem conhecimento técnico, possa gerenciar

websites ou portais. Mas, Joomla é uma ferramenta, ele não faz nada. Em tese, o
webdesign, seja um website, portal ou sistema é desenvolvido por uma equipe ou
pessoa qualificada tecnicamente e hospedado em servidores idôneos e com o
ambiente bem configurado e atualizado. Mas na prática, por tratar-se de “software
livre” o que vêm ocorrendo é que as pessoas pensam que Joomla! faz tudo, que
está tudo pronto e que não existe necessidade de investimentos capacitação ou
contratação de mão de obra.
O resultado, se traduz em potencial risco à marca e imagem das empresas e
instituições, tendo em vista a probabilidade de ocorrer um grave incidente
relacionado a segurança, seja através de defacement, SQL Injection, Denial of
Service, xss ou PHP injection.
A maioria dos ataques podem ser evitados com medidas básicas relativas ao Uso do
CMS Joomla, que por si só é extremamente seguro, com ambiente administrativo
acessado via usuário e senha, senha esta criptografada com Hash MD5. O Joomla!
permite ainda a utilização de TOKEN e servidores LDAP.
As melhores práticas de segurança estão relacionadas a: manter a versão do CMS
atualizada, hospedar o projeto em servidores idôneos e bem configurados, utilizar
url’s amigáveis e templates comerciais adquiridos nos clubes de template. O
desenvolvimento de extensões MVC deve ser realizado apenas por programadores
Orientados a Objetos, qualificados, ambientados com o framework do Joomla e que
sigam orientações rígidas no sentido de proteger o código-fonte de suas extensões.
Extensões têm papel fundamental enquanto programas que irão integrar-se ao
projeto para estender suas funcionalidades. Ao serem instaladas passam a fazer
parte do website Joomla! com acesso total ao banco de dados da aplicação. Se mal
projetadas, podem abrir backdoors que permitirão incidentes de segurança
causando danos irreparáveis ao webdesign, prejudicando desta forma o
desenvolvedor, a marca do cliente e em última instância: “ O projeto Joomla! e toda
a sua Comunidade.”

2. 8 EXTENSÕES PARA JOOMLA!
Segundo North (2011), Extensões são programas que permitem estender as
funcionalidades de um projeto desenvolvido com CMS Joomla! São divididas em
extensões do core ou núcleo e extensões de terceiros. São classificadas em:
 Componentes: são programas desenvolvidos para permitir algum tipo de
funcionalidade até então inexistente no projeto, por exemplo um álbum de
fotos. Componentes interagem com o banco de dados do website criando
novas tabelas e relacionamentos;
 Módulos: geralmente estão associados a algum componente e têm a função
de mostrar determinada informação no website. Podem ser utilizados para
integrar sistemas ou formulários legados, ao website;
 Plugins: são scripts, pedaços de código que reagem à ação do usuário
possibilitando determinado efeito no website. Por exemplo, o plugin de
inserção de imagens em artigos de conteúdo;
 Templates: responsáveis pela camada de visão, layout gráfico, design de
página e design de site de um projeto desenvolvido com CMS Joomla;
 Languages: são pacotes de idiomas que podem ser facilmente instalados no
projeto desenvolvido com CMS Joomla, permitindo a internacionalização do
mesmo.
Caratti e Silva (2010), entendem que extensão é uma pequena aplicação
desenvolvida com regras de construção estabelecidas pelo ambiente Joomla!
2.9 SEGURANÇA E JOOMLA!

Mitnick (2005), defende que o departamento de tecnologia da informação de
qualquer empresa deve ter um conjunto especial de políticas que o ajude a proteger
os ativos de informações da organização.
Segundo Hope e Walther (2009), criar dados de entrada anti-segurança e testar o
software são as tarefas mais difíceis de fazer.
Joomla é um CMS estremamente seguro, já recebeu prêmios relacionados ao tema,
mas tem sido criticado por conta de ataques bem sucedidos, particularmente
defacements.
A falta de uma política séria voltada a segurança, a utilização de extensões
vulneráveis e desenvolvedores sem capacitação técnica são os grandes
responsáveis pelos problemas de segurança com o CMS Joomla!
2.10 CONSIDERAÇÕES PARCIAIS
Houve uma época em que fazer “na mão” era sinônimo de conhecimento. Hoje, é no
mínimo insensato não utilizar um CMS, para desenvolver um projeto web. Os
gerenciadores de conteúdos permitem instalar funcionalidades e recursos
fundamentais em qualquer projeto moderno.
Joomla é um dos melhores gerenciadores de conteúdo da atualidade, possui uma
comunidade forte e atuante ao redor do mundo e tem conseguindo destaque no
governo brasileiro, sendo utilizado por grande parte das Instituições
Governamentais.

3. JOOMLA! FRAMEWORK
Framework é um arcabouço, em desenvolvimento de software, uma abstração que
une códigos comuns entre vários projetos de software provendo uma funcionalidade
genérica. Pode atingir uma funcionalidade específica, por configuração, durante a
programação de uma aplicação. O framework dita o fluxo de controle da aplicação,
chamado de inversão de controle.
Figura 1 – Camadas do CMS Joomla!
Fonte: http://docs.joomla.org/, 2009
Tudo no Joomla é construído sobre o seu framework, esta base constituída por
classes de objetos que controlam, geram informações e coordenam as ações do
Joomla. Possui vários pacotes:
 o pacote aplicativo, que alimenta a camada aplicativo e contém a classe
JApplication;
 o pacote com as bibliotecas de cachê;
 o pacote chamado de comum e que contém as classes básicas e as
bibliotecas de compatibilidade com versões anteriores;
 o pacote conector com bibliotecas para clientes como FTP e LDAP;
 o pacote para a base de dados que contém a classe JDatabase e as
bibliotecas necessárias;

 o pacote documento com as bibliotecas necessárias para criar e apresentar
páginas;
 o pacote do sistema de arquivos com bibliotecas para interagir com o
filesystem;
 o pacote i18n com bibliotecas de internacionalização (idiomas);
 o pacote de instalação com bibliotecas para poder instalar extensões
(componentes, módulos, plugins, templates, etc);
 o pacote de e-mail com bibliotecas;
 o pacote modelo com bibliotecas o objeto de acesso de dados;
 o pacote de parâmetros com bibliotecas para a manipulação de parâmetros;
 o pacote de registro (registry) com bibliotecas de armazenamento de
configurações;
 o pacote de modelos com bibliotecas de templates;
 o pacote de utilidades com diversas bibliotecas de uso geral;
 a classe JFactory que permite instanciar os objetos do framework;
 a classe JVersion que permite obter a versão do Joomla.
O framework não pode ser acessado diretamente, mas o Joomla oferece uma ponte
para criar seus vários objetos através do JFactory.
Os plugins, são extensões que trabalham par e passo com o framework ampliando
suas funcionalidades. Por exemplo, podemos ter um plugin que analisa o texto de
uma página antes que seja apresentado e mude algumas das suas características
substituindo partes do texto ou trocando alguns marcadores por imagens.
3.1 CAMADA APLICATIVO

A camada aplicativo é formada por todos os objetos necessários para que o sistema
funcione de forma integrada e coordenada. Esta camada também é a interface para
as extensões.
3.2 CAMADA EXTENSÕES
Esta camada é constituída por componentes, módulos e templates. Os componentes
são aplicativos escritos para o Joomla que ampliam a funcionalidade do sistema. Por
exemplo, um sistema de gerenciamento de weblinks ou de downloads. Os
componentes são elementos incluídos no corpo da página.
Os módulos também são pequenos aplicativos que podem ser incluídos em todas as
páginas (ou apenas nas da sua escolha) no topo, nas laterais ou no rodapé.
Exemplos são o módulo de login e o módulo de estatística do site.
Templates são modelos de apresentação das páginas, a camada de visão.
Controlam a disposição dos módulos e fornecem informações sobre a aparência e
disposição do texto.
3.3 FUNCIONAMENTO DO FRAMEWORK
Para produzir extensões para o Joomla é muito importante entender o mecanismo
do sistema. Conhecendo o funcionamento do sistema fica mais fácil criar extensões
que se integrem de forma harmônica e que incorporem a segurança e a
coordenação oferecida pelo sistema.
Simplicando as coisas ao máximo, o mecanismo é o seguinte: um script "acorda" o
framework para que ele forneça os modelos (classes) necessários para produzir

todos os objetos que vão compor o sistema. Usando o JFactory como ferramenta, o
script vai criando todos os objetos necessários para o funcionamento do mesmo, ou
seja, vai compondo a camada aplicativo povoando-a com objetos e com referências
a bibliotecas. Quando esta camada estiver pronta e ativa, os componentes, módulos
e templates são incorporados e os plugins são "ativados".

4. JOOMLA! API
A “API” do Joomla! é chamada simplesmente de Joomla! Framework. Para tirar o
melhor proveito do Joomla! Framework no desenvolvimento de extnesões MVC
deve-se usar chamadas a API do Joomla, evitando-se ao máximo as chamadas
diretas as bibliotecas.
Figura 2 – API do CMS Joomla!
Fonte: http://docs.joomla.org/, (2009)

4.1 JFACTORY
Esta classe possui vários Métodos utilizados no desenvolvimento de componentes
MVC, sendo a mais importante do framework. O código-fonte pode ser acessado no
diretório/pasta /libraries/joomla/factory.php.
Figura 3 – Classe JFACTORY
4.1.1 Método GETACL
O Método getACL obtém um objeto de autorização retornando uma referência para o
objeto global JAuthorization, criando-o se ainda não existir.
Referência: function &getACL( ).
Exemplo de uso: $autoriza =& JFactory::getACL();

4.1.2 Método GETAPPLICATION
O Método getApplication obtém um objeto aplicativo retornando uma referência para
o objeto global JApplication, criando-o se ainda não existir.
Referência: function &getApplication([mixed $id = null], [array $config = array()],
[$prefix = 'J'])
$id - (opcional) um identificador ou nome do cliente
$config - (opcional) um array associativo da configuração
Exemplo de uso: $aplicativo =& JFactory::getApplication();
4.1.3 Método GETCACHE
O Método getCache obtém um objeto cache retornando uma referência para o
objeto global JCache.
Referência: function &getCache([string $group = ''], [string $handler = 'callback'],
[string $storage = null])
$group - (opcional) o nome do grupo cachê
$handler - (opcional) o manipulador a ser usado
$storage - (opcional) o Método de armazenamento
Exemplo de uso: $cache =& JFactory::getCache();

4.1.4 Método GETCONFIG
O Método getConfig obtém um objeto configuração retornando uma referência para
o objeto global JRegistry, criando-o se ainda não existir.
Referência: function &getConfig([string $file = null], [string $type = 'PHP'])
$file - (opcional) o caminho (path) para o arquivo de configuração
$type - (opcional) o tipo de arquivo
Exemplo de uso: $config =& JFactory::getConfig();
4.1.5 Método GETDBO
O Método getDBO obtém um objeto banco de dados retornando uma referência
para o objeto global JDatabase, criando-o se ainda não existir.
Referência: function &getDBO( )
Exemplo de uso: $db =& JFactory::getDBO();
4.1.6 Método GETDOCUMENT
O Método getDocument obtém um objeto documento retornando uma referência
para o objeto global JDocument, criando-o se ainda não existir.

Referência: function &getDocument( )
Exemplo de uso: $documento =& JFactory::getDocument();
4.1.7 Método GETEDITOR
O Método getEditor obtém um objeto editor retornando uma referência para o objeto
global JEditor.
Referência: function &getEditor([string $editor = null])
$editor - (opcional) o editor que deve ser carregado, depende dos plugins instalados
Exemplo de uso: $editor =& JFactory::getEditor();
4.1.8 Método GETLANGUAGE
O Método getLanguage obtém um objeto idioma retornando uma referência para o
objeto global JLanguage, criando-o se ainda não existir.
Referência: function &getLanguage( )
Exemplo de uso: $idioma =& JFactory::getLanguage();

4.1.9 Método GETMAILER
O Método getMailer obtém um objeto mailer retornando uma referência para o objeto
global JMail, criando-o se ainda não existir.
Referência: function &getMailer( )
Exemplo de uso: $mail =& JFactory::getMailer();
4.1.10 Método GETSESSION
O Método getSession obtém um objeto sessão retornando uma referência para o
objeto global JSession, criando-o se ainda não existir.
Referência: function &getSession([array $options = array()])
$options - (opcional) uma array contendo as opções da sessão
Exemplo de uso: $sessao =& JFactory::getSession();
4.1.11 Método GETTEMPLATE
O Método getTemplate obtém um objeto template retornando uma referência para o
objeto global JTemplate, criando-o se ainda não existir.

Referência: function &getTemplate( )
Exemplo de uso: $template =& JFactory::getTemplate();
4.1.12 Método GETURI
O Método getURI pbtém um objeto URI retornando uma referência para o objeto
global JURI.
Referência: function &getURI([ $uri = 'SERVER'])
Exemplo de uso: $uri =& JFactory::getURI();
4.1.13 Método GETUSER
O Método getUser obtém um objeto usuário retornando uma referência para o objeto
global JUser, criando-o se ainda não existir.
Referência: function &getURI([ $id = NULL])
$id - (opcional) o usuário que deve ser carregado. Pode ser um inteiro ou string (a
string é automaticamente transformada em ID)
Exemplo de uso: $usuario =& JFactory::getUser('admin');

4.1.14 Método GETXMLPARSER
O Método getXMLParser obtém um documento XML retornando uma referência
para o objeto documento XML.
Referência: function &getXMLParser([string $type = ' DOM'], [array: $options =
array()])
$type - (opcional) o tipo de analisador de XML necessário: 'DOM', 'RSS' ou 'Simple'
$options - (opcional)
Usando 'DOM': Se ['lite'] for true ou não for definido, então domit_lite é usado
Usando 'RSS': ['rssUrl'] a url rss a ser analisada
Usando 'RSS': ['cache_time'] é o tempo de cache do feed. Se não definido, o
default é 3600 seg
Exemplo de uso: $parser =& JFactory::getXMLParser();
A Interface de Programação do Joomla segue padrões de projetos e seus métodos e
classes auxiliam sobremaneira no desenvolvimento de novas aplicações para o
CMS.
A utilização de métodos é fundamental para ganharmos tempo e desenvolvermos
extensões mais seguras e funcionais.

5. DESENVOLVIMENTO DE COMPONENTE MVC
Uma das grandes vantagens do CMS Joomla é a possibilidade de estender as
funcionalidades do projeto web com a utilização de extensões. Um componente é
um sistema orientado a objetos, desenvolvido para desempenhar determinada
função de forma integrada ao Joomla, possuindo geralmente duas interfaces:
Administrativa, restrita a usuários autorizados e acessada via backend e pública
acessada por todos os usuários via frontend. Para desenvolver o componente
utiliza-se uma “IDE” do porte do Aptana ou o bloco de notas. Ao ser instalado, o
componente passa a fazer parte do projeto, possui acesso total ao banco de dados
através da classe JDATABASE e funciona em total harmonia com os outros
componentes existentes no projeto permitindo um ganho real em funcionalidades.
Entretanto a falsa impressão de ser fácil programar para o joomla, aliada a falta de
cuidados básicos de segurança no desenvolvimento do código-fonte podem trazer
sérios prejuízos ao projeto desenvolvido, tendo em vista que uma porcentagem
considerável de ataques bem sucedidos à projetos desenvolvidos com o CMS
Joomla ocorrem justamente através da exploração de vulnerabilidades em
componentes MVC. O padrão de projeto utilizado no desenvolvimento de
componentes é o MVC (Model View Controller), um padrão de arquitetura de
software que visa a separar a lógica de negócio da lógica de apresentação,
permitindo o desenvolvimento, teste e manutenção isolado de ambos.
Figura 4 – MVC
Fonte: http://pt.wikipedia.org/wiki/MVC, (2011)
5.1 O MODELO (MODEL)

É a parte do componente que encapsula os dados da aplicação. Na maioria das
vezes vai fornecer rotinas de administração e manipulação de dados através de
Métodos para adicionar, eliminar e atualizar informações na base de dados (CRUD).
De modo geral, a técnica de acesso aos dados deve ser encapsulada no modelo.
Desta forma, se uma aplicação for transferida de um sistema que usa banco de
dados para um sistema que usa arquivos texto para guardar as informações, o único
elemento que precisa ser alterado será o modelo. Representa o domínio da
informação ou dados que o componente trabalha.
5.2 A visão (View)
É a parte do componente usada para transformar e preparar os dados do modelo
para que possam ser apresentados de alguma forma, geralmente numa página
HTML. O controlador retira os dados do modelo e os entrega para a visão. Esta, por
sua vez, alimenta “templates” com estes dados para que possam ser apresentados
ao usuário. A visão não modifica os dados de nenhuma forma, apenas os apresenta.
Poderá ser apresentada no formato HTML ou PDF.
5.3 O controlador (Controller)
O controlador é responsável pelas respostas às ações dos usuários, validação dos
dados, controle de paginação e aplicação de filtros. No caso de uma aplicação web,
uma ação de usuário (geralmente) é a solicitação de uma página. O controlador vai
determinar qual solicitação foi feita e vai responder de acordo fazendo com que o
modelo manipule os dados necessários na base de dados para depois passá-los
para a visão e esta providenciará a visualização ao usuário.

5.4 Classes utilizadas na implementação de componentes MVC
5.4.1 JModel
JMODEL é uma classe abstrata, estendida da classe JOBJECT, que fornece as
funcionalidades básicas para os padrões de projeto MVC do Joomla! Modelos que
estendem a classe JMODEL são frequentemente utilizados em componente MVC
com objetivo de definir a lógica de negócio do componente específico.
Figura 5 – Classe JModel)
5.4.2 JView
JVIEW é uma classe abstrata, estendida da classe JOBJECT, que fornece as
funcionalidades básicas para os padrões de projeto MVC do Joomla! Para utilizar as

funcionalidades de forma plena nos componentes MVC, deverão ser criadas as
classes JVIEW exclusivas do componente.
Figura 6 – Classe JView)
5.4.3 JController
JCONTROLLER é uma classe abstrata, estendida da classe JOBJECT, que fornece
as funcionalidades básicas para as classes do controlador de seu componente MVC.

Figura 7 – Classe JController
Fonte: http://docs.joomla.org/, 2009
5.4.4 JDATABASE
Quando o Joomla 1.5 é iniciado, ele precisa fazer uma série de consultas à sua base
de dados, senão nem consegue "entrar no ar". Para fazer estas consultas, o sistema
cria um objeto database. Se este objeto já existe, não há a necessidade de criar um

objeto do mesmo tipo para suprir as necessidades do novo componente MVC, basta
chamá-lo por referência.
5.4.4.1 Consultas com JDATABASE
Para invocar qualquer objeto por referência usa-se o marcador &. No caso, para
obter este objeto, o código é o seguinte:
Figura nr 8 – Instanciando o BD
Fonte: autoria própria (2011)
Com o objeto Database à disposição o programador pode fazer uma query
(pergunta) ao banco de dados e depois colher as respostas. Para colocar uma
pergunta chama-se (com ->) o Método setQuery() através deste objeto. Por
exemplo:
Figura nr 9 – executando consulta
Depois da query colocada, os resultados podem ser verificados. Por exemplo, se
apenas o valor do primeiro campo da primeira linha do conjunto de resultados for
desejado, é só usar o Método loadResult:
Figura 10 – Executando a consulta

Se o programador desejar todos os campos da primeira linha do conjunto de
resultados, então é preciso chamar através do seguinte código:
Figura 11 – apresentação de resultados
Os resultados encontrados serão colocados num array. Se o programador desejar
um objeto cujas propriedades sejam os nomes dos campos, pode executar a query
com:
Figura 12 – resultado em array)
Agora $objeto->title é o título do primeiro artigo achado, $objeto->alias é o apelido
do artigo. Quando o objeto for null, este Método cria o objeto e lhe atribui as
propriedades com os valores da primeira linha encontrada.
Mas, se o programador desejar um array de objetos com todos os artigos da tabela,
deve fazer o seguinte:
Figura 13 – Query completa
O código acima vai listar todos os títulos e todos os “alias” dos artigos existentes na
tabela de artigos.

5.4.4.2 Atualizações de registros com JDATABASE
Na atualização de algum campo da tabela, o programador pode usar o trecho de
código abaixo em sua consulta:
Figura 14 – query para atualização
A query foi colocada numa variável, a $query. Depois, esta variável foi usada como
parâmetro em setQuery(). Isto não é obrigatório, mas deixa o código um pouco mais
claro. Uma vez colocada a query, ela pode (e deve) ser acionada pelo Método
query()
5.4.4.3 Outros recursos do objeto JDATABASE
O JDATABASE pode ser usado para fornecer alguns valores extras, além de efetuar
consultas contra o banco de dados.
5.4.4.3.1 getEscaped()
O Método getEscaped, preparar strings com caracteres especiais (como é o caso do
apóstrofo) para que sejam aceitas pelo banco de dados sem darem erro. O Método

abaixo transforma "pingo d'água" em "pingo d'água" permitindo a gravação do
registro no banco de dados:
Figura 15 – Método getEscaped
5.4.4.3.2 getNullDate()
O Método getNullDate fornece uma "data e hora" zerada, ou seja, 000-00-00
00:00:00:
Figura nr 16 – Método geNullDate
5.4.4.3.3 getNumRows()
O Método getNumRows retorna a quantidade de linhas produzidas pela última
query executada:
Figura nr 17 – Método getNullRows
5.4.4.3.4 getErrorNum();
O Método getErroNum é utilizado para tratamento de erros.

Figura nr 18 – Método getErrorNum)
5.5 FERRAMENTAS CASE PARA O DESENVOLVIMENTO DE
COMPONENTE MVC
Existem ferramentas que auxiliam e agilizam o processo de desenvolvimento de
componentes MVC para o CMS Joomla.
5.5.1 Aptana
Aptana é uma IDE (Integrated Development Environment) open source, gratuita,
baseada no eclipse, possui um plugin para integração com o PHP, sendo utilizada
em larga escala no desenvolvimento de componentes MVC para o CMS Joomla! O
seu download pode ser feito livremente no endereço <http://www.aptana.com/>
5.5.2 Alphaplug
Alphaplug é um aplicativo online que permite a geração de toda a estrutura do
componente MVC (modelos, visões, controladores), além dos arquivos de idiomas,
arquivos de instalação e desinstalação, scripts .sql para criação e população das
tabelas. Após preencher os dados básicos do componente é gerado um pacote
compactado, pronto para ser instalado no Joomla, cabendo ao programador a
codificação do componente. O alphaplug pode ser utilizado livremente no endereço
<http://www.alphaplug.com/index.php/products/mvc-generator-online.html/>

5.5.3 GEPAC
GEPAC é um gerenciador online de pacotes MVC para Joomla! 1.6 que permite a
geração de toda a estrutura do componente MVC (modelos, visões, controladores),
além dos arquivos de idiomas, arquivos de instalação e desinstalação, scripts .sql
para criação e população das tabelas. Após preencher os dados básicos do
componente é gerado um pacote compactado, pronto para ser instalado no Joomla!
1.6, cabendo ao programador a codificação do componente. O GEPAC pode ser
utilizado livremente no endereço <http://www.joomlabrasilia.com.br/gepac/>
5.6 TIPOS DE COMPONENTES MVC
Existem 02 (dois) tipos de componentes MVC, os que fazem parte do núcleo do
CMS Joomla e são distribuídos com o pacote de instalação e os desenvolvidos por
empresas e programadores independentes sem ligação com a equipe mantenedora
do projeto. Esses componentes recebem a denominação de “extensões de
terceiros.”
5.7 FALHAS DE SEGURANÇA NO COMPONENTE, ENCONTRADAS
NA FASE DE TESTES
Muitos componentes são desenvolvidos por programadores inexperientes que não
tomam medidas preventivas visando a proteção de seus componentes contra
tentativas de ataques de crackers.
As principais falhas observadas são relativas a falta ou validação ineficiente dos
dados inseridos em formulários de seus componentes, o que pode acarretar a

aceitação de qualquer tipo de dados pela aplicação, ou mesmo o envio de
formulários em branco que acabam por gravar registros nulos no banco de dados.
Os principais ataques a componentes MVC estão relacionados à passagem de
valores inesperados em formulários que podem culminar em um defacement, ou
mesmo em um total comprometimento do website através de ataques do tipo SQL
Injection.
O projeto Joomla! mantém um grupo de especialistas que trabalha exclusivamente
com a segurança do CMS e Componentes, catalogando os componentes de
terceiros que apresentem algum tipo de vulnerabilidade, ficando os mesmos
registrados na base de dados até que venham a apresentar a solução para o
problema levantado, geralmente através de uma release de segurança ou nova
versão para o componente.
A lista oficial de componente vulneráveis pode ser acessada em
<http://docs.joomla.org/Vulnerable_Extensions_List/>
A comunidade Joomla! também mobiliza-se em prol da segurança do CMS e suas
extensões sendo importante o acompanhamento dos feeds abaixo, voltados à este
tema:
<http://feeds.joomla.org/JoomlaSecurityNews/>
<http://feeds.joomla.org/JoomlaSecurityVulnerableExtensions/>
<http://pipes.yahoo.com/pipes/pipe.info?_id=NFvms7053RGSMS6czKky6g/>

5.8 CRIPTOGRAFIA DAS SENHAS NO JOOMLA!
Para entender a engenharia utilizada no processo de criptografia e armazenamento
de senhas do CMS, é preciso analisar dois arquivos. Um faz parte do parte do plugin
de autenticação do joomla e o outro faz parte da biblioteca do joomla.
5.8.1 Joomla.php
O arquivo joomla.php está localizado em /plugins/authentication/ e a parte de seu
código-fonte que trata da criptografia da senha pode ser analisado abaixo:
Figura 19 – Parte do código-fonte do arquivo joomla.php
As linhas 70 a 78 mostram que o plugin acessou o banco de dados do Joomla para
buscar algumas informações na tabela de usuários filtrando os dados pelo nome de
usuário.

Figura nr 20 – continuação código-fonte joomla.php
Se tiver encontrado alguma coisa, explode o que encontrou no campo password
usando o delimitador ":" (linha 82). A primeira parte (a senha criptografada) é
armazenada na variável $crypt; (linha 83) a segunda (o chamado sal) é colocada na
variável $salt (linha 84). Isto indica que as senhas guardadas são compostas por
duas partes. Alguns exemplos são:
3291503d0bd0059c54b466049594c443:Tk7F78S1VpAAGgPB
69a02eba32f545982806168859ebb08b:kQFgQ54RngbuYhsC
Logo a seguir, o Método getCryptedPassword, que pertence à classe JUserHelper, é
chamado com os parâmetros senha e sal (veja na linha 85).
5.8.2 getCryptedPassword
O Método getCryptedPassword da classe JUserHelper está inserido no arquivo
helper.php, localizado em /libraries/joomla/user
A função getCryptedPassword (linha 106) precisa no mínimo de um parâmetro: a
senha em texto claro ($plaintext); os outros três parâmetros são opcionais. Se o sal
($salt) não for fornecido, ele recebe uma string vazia; se o tipo de encriptação
($encryption) não for definido, o valor padrão 'md5-hex' é assumido e se mostrar o
tipo de encriptação ($show_encrypt) não for especificado, o padrão será falso.

Em princípio, se chamarmos a função apenas com a senha fornecida pelo usuário, o
sal não será usado, o tipo de cifragem será md5-hex e o tipo de encriptação não
será adicionado ao resultado. É a cifragem mais simples que existe.
As linhas restantes desta função tratam de identificar o tipo de encriptação solicitado
e realizam a cifragem de acordo. Para nós interessam apenas as linhas finais, onde
o hash do tipo md5-hex é calculado.
Se o sal estiver presente, a variável $encrypted recebe o valor de retorno da função
do PHP md5() aplicada ao conjunto $plaintext.$salt; se não estiver presente, a
mesma função do PHP é aplicada apenas a $plaintext. Da mesma forma, se
$show_encrypt for verdadeiro, o tipo de cifragem é adicionado ao resultado pela
concatenação de '{MD5}'.$encrypted; caso contrário, o valor de retorno será apenas
o hash obtido.
Figura 21 – parte do código-fonte do arquivo helper.php

5.8.3 HASH
Joomla! usa Hash MD5. Um hash, também chamado de "digesto", é uma espécie de
"assinatura" ou "impressão digital" que representa o conteúdo de um fluxo de dados.
Um hash pode ser comparado com um selo de embalagem que indica clara e
inequivocamente se a embalagem já foi aberta ou violada.
Hashes transformam os dados do texto (claro ou cifrado) num pequeno digesto, de
tamanho fixo, numa operação de mão única. Uma operação de mão única não tem
volta, ou seja, em tese não é possível obter o texto claro a partir de um resultado
hash. Porém, já existem programas capazes de quebrar hashes.
Guardar senhas em texto claro é dar chance para o azar. Se um arquivo de senhas
for roubado ou um banco de dados com registros de senhas for hackeado, o estrago
pode ser enorme. Como um hash não é reversível e, para serem usadas, as senhas
precisam ser conferidas, é muito mais prudente armazenar os resultados hash das
senhas do que as próprias senhas.
O uso de uma senha pressupõe que um usuário a digite. Tendo a senha como
entrada, é fácil e rápido calcular o resultado hash da senha fornecida e compará-lo
com o valor arquivado. Se forem idênticos, a senha confere, mostrando que o
usuário conhecia uma senha válida.
Este procedimento reduz sensivelmente os riscos porque o único momento em que
a senha pode ser roubada é enquanto está sendo digitada e antes de ser
transformada em hash.

5.8.4 MD5
O MD5 foi desenvolvido por Ron Rivest em 1991. É basicamente o MD4 com um
"cinto de segurança" - os cálculos são um pouco mais lentos, mas, em
compensação, é muito mais seguro.
Da mesma forma que outras funções hash, o MD5 é usado em assinaturas digitais
onde um texto longo precisa ser "comprimido" de forma segura antes de ser cifrado
com uma chave privada (secreta) por um criptossistema de chave pública. Foi
projetado para máquinas de 32 bits, podendo ser facilmente programado de forma
compacta. O autor colocou o algoritmo no domínio público em abril de 1992.
Como o texto sobre a função hash MD4 é bastante minucioso e o MD5 é muito
parecido, não há a necessidade de entrar em muitos detalhes. Caso você tenha
dúvidas, complemente a leitura com o texto MD4.
5.9 FORMAS DE CORREÇÃO DAS FALHAS ENCONTRADAS
Para corrigir falhas de segurança nos componentes MVC durante a fase de testes,
devem ser adotadas práticas relacionadas a testes de validação dos dados inseridos
nos formulários.
Desenvolver componentes para o CMS Joomla exige do técnico, conhecimento
avançado em lógica de programação, programação orientada a objetos e banco de
dados.

Diferente do gerenciamento de conteúdo ou do desenvolvimento de um website, o
desenvolvimento de um componente MVC exige sim, conhecimento técnico. Muitas
invasões são efetuadas em cima de vulnerabilidades existentes em componentes
desenvolvidos fora dos padrões de projeto do framework do Joomla!
Utilizar os métodos do próprio framework e seguir padrões de projeto são atitudes
fundamentais para que seja desenvolvida uma extensão segura.

6. VULNERABILIDADES E DEFACEMENT’S
As principais vulnerabilidades em componentes MVC estão relacionadas à falta de
tratamento aos tipos de dados que são enviados pelos formulários à base de dados,
particularmente com expressões regulares que impeçam a formação de tags HTML.
Este descuido pode facilitar ataques de diversos tipos.
Observe na imagem abaixo que possuímos 04 (quatro) campos de texto em um
formulário e espera-se que o usuário insira somente caracteres do tipo “string”. Mas,
e se o usuário inadvertidamente tentar inserir dados numéricos ou caracteres
especiais, qual seria o comportamento do componente? Ele iria processar o
registro?
Figura 22 – Formulário para inserção de dados em componente MVC via backend
Um componente que funcione no backend do Joomla!, dificilmente sofrerá um
ataque de crackers tendo em vista a própria política do CMS que só permite acesso
a usuários com perfil de Administrador e Super Administrador. Partimos do princípio
que se o cracker conseguiu acesso ao backend, todo o website está comprometido.
Porém, os componentes que recebem dados via frontend estão sujeitos a diversos
tipos de ataques.

6.1 SQL INJECTION
Qualquer SGBD (Sistema Gerenciador de Bancos de Dados Relacional) entende
apenas uma linguagem: SQL (Structured Query Language) ou linguagem de
consulta estruturada. CREATE, DELETE, UPDATE e SELECT são apenas alguns
dos comandos mais utilizados nesta linguagem, mas não está no escopo do nosso
artigo, ensinar SQL e sim apresentar-lhe o SQL INJECTION.
Uma das formas mais comuns e efetivas de ataque na internet é o SQL Injection. No
SQL Injection, um cracker tenta enviar códigos SQL via consultas SQL não
autorizadas e filtradas. O código SQL do cracker pode não ter nenhum retorno em
termos de informações de segurança ou simplesmente executar um processo de
destruição absoluta.
Existem precauções básicas que você deve tomar, para proteger os dados que
serão recebidos através de formulários, principalmente se foi você quem o
desenvolveu. A regra básica é tratar e validar os dados que serão recebidos e se
assegurar que o seu código nunca irá receber os dados de uma forma bruta, ou
seja, sem o devido tratamento.
Você pode tratar os dados de várias formas, desde limite de caracteres aceitos com
maxlenght e size até scripts em javascript, para fazer a validação a nível cliente e
scripts PHP, para validação a nível provedor.
Todos os dados enviados devem ser processados e validados antes de serem
utilizados pela aplicação.

6.2 CAMPOS DE TEXTO EM FORMULÁRIO SEM FILTRAGEM
Por exemplo, um formulário HTML pode aceitar um campo para um nome. Enquanto
um usuário normal iria simplesmente digitar o seu nome no campo de texto do
formulário, o cracker injeta código SQL para tentar executar uma consulta não
autorizada ao banco de dados. Se no código do script PHP que vai receber os dados
do formulário você “setou” a variável $name do tipo Get ou Post nome, que é o
campo do formulário, a consulta normal ao banco de dados seria algo isto:
$sql="Select * FROM jos_users WHERE name =' " . $name. " ';";
O cracker então digitaria algo parecido com o que segue: dummytext ' OR ' a ' = ' a
O código SQL gerador a partir desta injeção seria algo parecido com isto: select *
FROM jos_users WHERE name = 'dummytext' OR ' a ' = ' a ';
Quando a consulta enviada pelo cracker é executada, o teste ' a ' = ' a ' retornaria
um valor real para cada linha e a consulta apresentaria a lista de todos os usuários
existentes na tabela jos_users. O mais assustador é que qualquer código SQL
válido, ou seja, sem erro de sintaxe, pode ser injetado, como mostrado no código a
seguir: dummytext ' ; DROP table jos_users; SELECT * FROM jos_poll where title = '
O código acima iria destruir completamente a tabela de usuários do Joomla. Uma
rotina simples de tratamento e validação do campo de texto do formulário permitiria
eliminar qualquer perigo de um ataque deste tipo.

6.3 MANUSEANDO CAMPOS DE TEXTO EM FORMULÁRIO PHP
Joomla inclui rotinas para gerar caracteres de escape para quaisquer caracteres
(string) que não podem ser armazenados adequadamente dentro de um banco de
dados. Por exemplo, a “plica” ( ' ) não pode ser armazenada na declaração SQL
padrão de inserção sem modificação. Portanto, uma seqüência de caracteres de
escape com barra invertida ( ) permite a inclusão de caracteres especiais no MySql.
Assim, uma barra invertida seguida pela citação ( " ) seria o único meio de
armazenar os dados no campo do banco de dados. A seqüência de caracteres de
escape fornecidos pelo próprio sistema invalida o ataque via injection, porque os
caracteres digitados pelo hacker não serão entendidos pelo sistema como um
comando SQL, será apenas um caracter literal comum a ser armazenado no banco
de dados.
O provável resultado dessa consulta seria o retorno de um erro, uma vez que não
existem registros correspondentes a esse valor seria encontrado. Para o código
PHP, você pode usar um banco de dados específicos de cada Método para gerar
uma string que cria códigos para escapar de caracteres especiais. Para o MySQL,
PHP inclui a função mysql_real_escape_string ()
O uso da função fica parecido com isto: $name = mysql_real_escape_string($name);
Joomla! fornece um Método getEscaped () que irá retornar a string
independentemente de seqüência de escape de caracteres. Embora Joomla
atualmente só suporte MySQL (previsto suportar ORACLE a partir da versão 6),
você pode obter com o objeto JDatabase, a string que escapou e seria algo parecido
com isto:
$db =& Jfactory::getDBO();
$name = $db->getEscaped($name) ;

Voltando aos ataques, no primeiro exemplo de ataque via SQL Injection, com os
caracteres de escape, teríamos a seguinte seqüência inofensiva:
dummytext ' or 'a ' = ' a
O segundo exemplo ficaria assim:
dummytext' ; Drop Table jos_users; select * from jos_polls where title = '
Existe uma diretiva do PHP conhecida como "magic quotes", que irá adicionar
automaticamente barras para todos os campos recebidos de fonte externa (como um
navegador da web). Na versão 6 do PHP, esta diretiva foi eliminada.
Portanto, é melhor ficar atento (a) aos códigos, principalmente de extensões de
terceiros, para que seja executado de forma segura e caso esteja hospedando o
Joomla em servidores com PHP 4.x (a maioria dos baratinhos ainda utiliza esta
versão antiga do PHP) verifique a magiq quotes. ELA DEVE ESTAR LIGADA, ou
seja, magiq_quotes = ON
6.3.1 Tipos não esperados
Outra forma de ataque via SQL Injection pode ocorrer quando valores não
esperados, (string, float, e assim por diante) são digitados e passados diretamente
para a consulta SQL. Por exemplo, um valor de id obtido a partir de uma consulta ao
banco de dados executada diretamente em linha de comando como esta:

$sql = " select * from jos_users where id = " . $id . "; “;
O mesmo tipo de SQL Injection poderia ser utilizado com o id recuperado, se não for
tratado com os caracteres de escape:
1; Drop table jos_users;
Portanto, quando você aceitar valores de uma consulta ou formulário de envio,
certifique-se de escrevê-los através do php. Por exemplo, para escrever o $id em
um valor inteiro (Integer), você poderia utilizar o seguinte código PHP:
$id= intval($id);
Digitando este código, qualquer tipo de SQL Injection, será automaticamente
eliminado, ou irá gerar um erro quando o código encontrar os caracteres inválidos.
Se você usar os Métodos JRequest:: getVar () ou JRequest:: get (), nativos do
Joomla para obter a seqüência de dados enviados via formulário de consulta, você
já está protegido. Estas funções fornecem um filtro seguro para todos os tipos de
dados indefinidos ou não esperado. Entretanto, quaisquer dados obtidos fora dessas
funções, devem ser tratados por você com caracteres de escape, sempre que
possível.
6.4 CROSS-SITE SCRIPTING (XSS)
É um Método de inserção de algumas instruções para que seja executado um
código javascript, um objeto, ou código HTML quando um editor de HTML é
disponibilizado para o usuário. Este código pode abrir uma janela oculta no sistema

do usuário e gravar itens como nomes de usuários e senhas em outras janelas do
navegador. O fato de um “website” permitir ao usuário postar conteúdo (uma das
principais características da web 2.0), este vulnerabilidade tem aumentado e sido
explorada ao máximo. Croos-site scripting é um ataque muito perigoso e deve ser
evitado.
Estes tipos de ataques podem ser controlados através da interface de usuário do
joomla! No entanto, a prevalência de extensões disponíveis que permitem inserção
de código HTML, por exemplo, (Livros de visitas e fóruns) significa que você deve
estar alerta para prevenir esses tipos de ataque. Assegurar que as novas extensões
façam a filtragem das tags utilizadas por este Método de ataque (principalmente e)
antes de implantar a extensão ou o seu site.
PHP tem um conjunto de funções que podem lhe ajudar. A função strip_tags () irá
funcionar retirando todas as tags de HTML, XML e PHP, de uma seqüência de
dados enviados e devolvendo o texto plano. Isto pode ser utilizado de forma muito
eficaz se a sua aplicação não está esperando este tipo de formatação de texto como
entrada. Para a formatação, você poderia usar BBCode, que é aceita sem ser
afetada por essa função.
A função htmlentities () do PHP irá converter todos os caracteres não-alfanuméricos
(como aspas, maior que, asterisco e assim por diante) para formatação HTML. Você
também pode usar expressões regulares para tirar todos os caracteres especiais
exceto alfanuméricos. Por último, em um campo Nome, você pode usar uma
declaração como esta:
$myString = preg_replace("/[^a-z 0-9]/i", "", $myString);

6.5 DIRECTORY SCANNING
A navegação entre diretórios é um convite aberto para crackers tentarem descobrir
uma grande quantidade de informações sobre seu sistema. A partir de arquivos de
configuração geral do sistema o cracker poderá ter acessos a informações sobre o
sistema operacional do provedor e da aplicação.
Como medida preventiva, o CMS Joomla cria um arquivo index.html, em branco, em
cada diretório do site e subdiretório do site para evitar esta possível intrusão. A
maior parte das extensões e templates desenvolvidas por terceiros, no entanto, não
adotam este ato preventivo.
6.6 CROOS-SITE REQUEST FORGERY (CSRF)
Cross site request forgery é um tipo de ataque simples e devastador. Este tipo de
ataque depende da confiança de um site no usuário logado e que pode fazer certos
tipos de transações. O CSRF força o navegador logado da vítima a enviar uma
requisição de solicitação não autorizada para uma aplicação web vulnerável, que
realiza a ação desejada em nome da vítima.
Por exemplo, digamos que um usuário esteja conectado no backend do Joomla e
em outra aba do navegador esteja navegando em um website comprometido. Em
alguns navegadores, um ataque CSRF pode ser lançado pela simples adulteração
de um elemento do tipo IMG, para que eles apontam para algo como
http://some/joomla/site/administrator/index2.php?option=com_users&task=delete...

Quando o usuário, logado no backend, navega no site comprometido, e clica sobre a
imagem com o link alterado o pedido forjado será interpretado como autenticado e
executado no backend do Joomla!
Figura nr 23 – Tipo de ataque CSRF
Fonte: http://www.google.com/images/, (2011)
6.7 DEFACEMENT
O objetivo deste ataque é “pixar” a página inicial do website e geralmente é
praticado por script kiddies com cunho político ou pessoal. A utilização de templates
piratas em websites Joomla pode abrir backdoors que facilitam em última análise,
ataques deste tipo.
Figura nr 24 – Defacement
Fonte: http://www.google.com/images/, (2008)

Uma aplicação web está sujeita a vários tipos de ataques. Porém, a maioria pode
ser evitada com a adoção de melhores práticas relacionadas à segurança, por parte
de quem desenvolve.
É comum encontrarmos websites com nome de usuário administrativo padrão e
senha fraca. Hospedados em hosts desatualizados, com sérios problemas de
permissionamento.
Estas preocupações são inerentes ao desenvolvedor web e uma vez negligenciadas
colocam em risco toda a estrutura envolvida, desde a rede até a aplicação.
O defacement é o tipo de ataque mais temido por mudar as características da
página inicial do website, podendo comprometer seriamente a marca do cliente
invadido. Porém, dependendo da intensidade não é o mais perigoso.
Não existe sistema seguro, o que podemos fazer é otimizar a segurança para
minimizar as chances de sucesso por parte do atacante. Mas, desejamos 100% de
segurança, só existe uma opção: “desligar a máquina.”

7. TESTES DE PENETRAÇÃO
Para avaliar o nível de segurança do componente MVC desenvolvido, é importante
viabilizar testes de penetração com ferramentas específicas para este fim. O teste
de penetração é um Método que avalia dentre outras coisas, a segurança de um
sistema, neste caso o componente.
Com o teste, é feita uma simulação de ataque de uma fonte maliciosa e o processo
envolve uma análise nas atividades do sistema em busca de alguma vulnerabilidade
em potencial resultante da má configuração ou má codificação do sistema. Todas as
análises submetidas pelos testes escolhidos são apresentadas no sistema, junto
com avaliação do impacto e muitas vezes, proposta para resolução do problema.
O objetivo central do teste de penetração é determinar a viabilidade de um ataque e
mensurar o seu impacto caso seja bem sucedido. Ele age como um componente na
auditoria de segurança e é altamente recomendável que desenvolvedores de
componentes considerem incluir testes de penetração no processo.
Podem ser realizados de várias maneiras sendo mais comuns o teste caixa preta e o
caixa branca.
Testes de penetração podem ser usados para busca de vulnerabilidades em
sistemas, uma simples varredura na organização dos endereços IP, abrir/fechar
portas ou fazer uma auditoria completa no escopo da rede em busca de
vulnerabilidades.

7.1 TESTE CAIXA PRETA
O teste da caixa preta assume que não existe qualquer conhecimento prévio da
infra-estrutura a ser testada. Sendo que o primeiro teste deve determinar a
localização e extensão dos sistemas antes de iniciar a análise. Simulam um ataque
de alguém que esteja familiarizado com o sistema.
7.2 TESTE CAIXA BRANCA
O teste da caixa branca assume que o testador possui total conhecimento da infra-
estrutura a ser testada, incluindo o diagrama da rede, endereçamento IP e qualquer
informação complementar. Simula o que pode acontecer durante o expediente de
um trabalho ou depois de um "vazamento" de informações, em que o invasor tenha
acesso ao código fonte do sistema.
7.3 TESTES DE VULNERABILIDADES EM COMPONENTE MVC
Uma vez instalado no “website” o componente deve sofrer testes para verificar o
nível de segurança em relação aos principais ataques conhecidos e utilizados contra
websites.
7.4 BACKTRACK
Backtrack é uma poderosa solução desenvolvida para testes de penetração,
apreciada por especialistas em segurança, hackers e crackers. Conta com 13
ferramentas de código aberto que lhe conferem um alto poder de “fogo”.

As ferramentas do Backtrack são divididos em três categorias: Aquisição de Imagem,
escultura de arquivo e análise forense. As ferramentas da categoria de aquisição de
imagem permitem-lhe adquirir pouco a pouco as imagens de discos. As duas
ferramentas de escultura de arquivos, ajudam no processo de resgate de arquivos
apagados. As nove ferramentas da categoria de análise forense permitem uma
pesquisa completa no disco em busca de mensagens de email, histórico de
navegação e miniaturas de imagens.
O Backtrack pode ser utilizado em conjutno com outros aplicativos para testar
componentes MVC desenvolvidos para o CMS Joomla, a partir de algumas de suas
ferramentas para identificação de vulnerabilidades: Nikto, SQL Inject, SQLbrute.
Algumas ferramentas irão interagir com a máquina servidora e outras, diretamente
com a aplicação.
Figura 25 – Iniciando o backtrack em máquina virtual

Figura 26 – Backtrack pronto para uso em máquina virtual
7.5 NIKTO
Nikto é um projeto open source de um scanner que busca vulnerabilidades no
servidor web. O nikto está embutido no Backtrack, mas pode ser executado
separadamente em um terminal de uma máquina GNU/LINUX exibindo um raio-x do
servidor em que o website está hospedado. O comando shell para execução do
Nikto é: nikto –h http://www.sitealvo.com.br.
7.6 ZERODAYSCAN
ZeroDayScan é um scanner de segurança online voltado para web, usado por
webmasters e especialistas em segurança para validar a segurança dos seus sites e
aplicativos. Os principais destaques são:

 Nenhuma instalação é necessária. É um serviço on-line;
 Detecta ataques Cross Site Scripting (XSS);
 Detecta diretórios ocultos e arquivos de backup;
 Olha para vulnerabilidades de segurança conhecidas;
 Pesquisas para vulnerabilidades de injeção SQL;
 Detecta automaticamente bugs do tipo zero-day;
 Realiza “Fingerprinting” no website;
 Gera relatórios em PDF grátis.
7.7 OWASP
Projeto open source de um scanner de vulnerabilidades em CMS.
Os seguintes recursos estão disponíveis no OWASP:
 Sondagem da versão atual do Joomla! (o scanner pode dizer se o alvo está
executando a versão 1.5.12 em diante);
 Detecção comum do Joomla! Baseado na aplicação web e firewall;
 Procurar as vulnerabilidades conhecidas do Joomla! E seus componentes;
 Reportagem de saída em Texto e HTML;
 Capacidade de atualização imediata via scanner ou svn.
7.7.1 Requisitos e funcionamento do OWASP
- Sistema Operacional GNU/LINUX

- Faça o download no “website” (http://yehg.net/lab/pr0js/files.php/joomscan-
latest.zip) e descompacte o arquivo zip ($ unzip file) na raiz do seu “website”; e
- Acesse o diretório e dê permissão de execução no arquivo joomscan.pl ($ chmod
+x joomscan.pl)
- Atualize a base de dados do scanner
$ ./joomscan.pl update
- O uso básico do scanner é:
$ ./joomscan.pl -u http://seusite.com.br
- Parâmetros
Usage: ./joomscan.pl -u <string> -x proxy:port
-u <string> = joomla Url
-x <string:int> = proxy to tunnel
-c <string> = cookie (name=value;)
-g "<string>" = desired useragent string(within ")
-nv = No Version fingerprinting check
-nf = No Firewall detection check
-nvf/ -nfv = No version+firewall check
-pe = Poke version only and Exit
-ot = Output to Text file (target-joexploit.txt)
-oh = Output to Html file (target-joexploit.txt)
-vu = Verbose (output every Url scan)
-sp = show completed Percentage

É fundamental realizar testes para termos certeza que a infraestrutura de
hospedagem, as extensões e o website, estão com a segurança maximizada.
A maioria dos programas são exclusivos do sistema operacional GNU/LINUX, mas
existem soluções on line e gratuitas que podem ser utilizadas, enviando de forma
automática uma análise estatística de toda a situação.

8. MELHORES PRÁTICAS PARA EVITAR INVASÕES
O profissional responsável pelo desenvolvimento do website precisa prever no
levantamento de requisitos, a política de segurança com o uso de extensões
específicas para este fim. Deve manter a versão atualizada, evitar o uso de
templates piratas, extensões que estejam relacionadas na lista de vulnerabilidades
do projeto Joomla! e a utilização de provedores pouco conhecidos. A aplicação
correta das permissões de arquivos e diretórios, a escolha de uma senha forte com
troca do nome padrão do usuário de administração completa o ciclo.
As tecnologias envolvidas na preparação do ambiente de hospedagem
representadas pelo acrônimo LAMP e o gerenciamento de toda a estrutura da rede,
com seus sistemas de firewall, voltados a impedir acesso não autorizado são
fundamentais para garantir o sucesso de um projeto web e ficam a cargo do
provedor de hospedagem contratado.
Figura nr 27 – A aplicação é a ponta do iceberg

O CMS representa à camada de aplicação que pode ser comparada a ponta de um
iceberg.
A preocupação com a segurança deve ser prioridade no desenvolvimento de um
projeto web. Projetos desenvolvidos com o CMS Joomla devem obedecer a regras
específicas para a melhor utilização do CMS.
8.1 O PROVEDOR DE HOSPEDAGEM
A escolha do provedor de hospedagem é uma etapa importante e que poderá
comprometer toda a segurança do projeto se for escolhido um provedor ruim, com
os aplicativos que sintetizam o “LAMP” desatualizados. Muitas vezes fica a cargo do
desenvolvedor tendo em vista que o cliente ignora o que venha a ser um provedor.
Neste caso, deve-se evitar a venda casada e os provedores extremamente baratos.
O melhor a fazer é orientar o cliente e buscar em conjunto, provedores idôneos
através de pesquisa de mercado. Todos os direitos relativos ao domínio devem ficar
com o cliente.
8.2 INSTALAÇÃO AUTOMÁTICA DO JOOMLA!
Joomla! vende e por isso, vários provedores prometem suporte e instalação
automática do CMS. Não existe suporta a Joomla, qualquer máquina que possua no
mínimo PHP e Mysql será capaz de prover condições de funcionamento ao CMS
desde que devidamente configurada com um web Server.
O fato é que essas empresas utilizam programas que instalam automaticamente,
não só o CMS, como vários outros programas. Geralmente utilizam o “Fantástico”
que é um instalador automático. O problema é que o “Fantástico” leva em média 15
(quinze) dias para atualizar sua base de dados e o usuário acaba por ter um website

com duas, três, às vezes quatro versões atrasadas do CMS e dificilmente percebe
este fato. A conseqüência será um website com um Joomla desatualizado e
potencialmente suscetível a ataques bem sucedidos de crackers.
O processo de instalação do Joomla! É extremamente simples e existem vários
tutoriais na internet que podem ajudar sendo desaconselhável a utilização de
programas instaladores.
8.3 ENCAPSULAMENTO DO ADMINISTRATOR
Ataques do tipo força bruta precisam acessar o /administrator do website para tentar
combinações aleatórias de usuários e senhas. Encapsular o endereço diminui em
pelo menos 80 % as tentativas desta natureza uma vez que não existirá o endereço
buscado pelo atacante.
Existem várias extensões que protegem o acesso ao /administrator do Joomla!
Sendo o mais utilizado o plugin JSecure que permite a criação de uma chave que
será pedida ao final da url de administração do website.
A instalação e habilitação do plugin forçam o usuário a digitar após o /administrator,
a chave criada pelo superadministrador do website.
Ex: http://www.seusite.com.br/administrator?suachave

8.4 URL’S AMIGÁVEIS
Todo CMS gera url’s dinâmicas que são um conjunto de caracteres e variáveis que
indicam o conteúdo a ser renderizado pelo navegador. Url’s amigáveis nada mais
são que endereços humanamente compreensíveis. Por exemplo: O endereço
http://www.seusite.com.br/index.php?option=1&content=2 é um exemplo de url
dinâmica. Utilizando-se url amigável poderíamos ter algo parecido com
http://www.seusite.com.br/blog/meuartigo.html.
A url amigável além de permitir uma melhor indexação pelas máquinas de busca e
conseqüente melhora no Page rank é importante fator de aumento na segurança do
website joomla!, tendo em vista que muitos ataques automáticos buscam fragmentos
de url para obter êxito.
Um componente chamado com_prest geraria o seguinte fragmento na url dinâmica
de seu website: http://www.seusite.com.br/index.php?option=com_prest. Caso este
componente possua algum tipo de vulnerabilidade o robô irá capturar este fragmento
(com_prest) e buscará em sua base de dados, a melhor forma de explorar a
vulnerabilidade encontrada e conseqüentemente irá obter êxito invadindo o seu
website.
Com a utilização de url’s amigáveis fica impossível para o robô identificar o
componente no fragmento da url tornando inócua esta tentativa de ataque.
8.5 APLICAÇÃO CORRETA DAS PERMISSÕES
O GNU/LINUX, que é o sistema operacional da máquina servidora do seu website é
baseado no UNIX e por isso requer permissões de LEITURA - GRAVAÇÃO -
ESCRITA. Mudanças de permissão são conseguidas com o comando chmod

(CHANGE MODE), ficando assim na linha de comando: chmod [parametro
diretorio/arquivo]
* Ex: chmod 755 -r /var/www/novosite
* chmod 755 (/var/www/novosite) - aquí o prorietário têm todas as permissões, mas o
grupo e os outros utilizadores apenas têm permissão de leitura e execução. O -r
significa recursivamente, ou seja, todos os diretórios abaixo do /novosite serão
atingidos.
* -r afeta também os subdiretórios
* -v mostra cada arquivo a ser processado
* -c mostra apenas os arquivos que sofreram alterações
Para entendermos como este comando pode ser utilizado será melhor percebermos
como as permissões são atribuídas a cada arquivo ou diretório. A permissão Read
tem o valor 4 , a Write o valor 2 e o Execute o valor é 1.
A permissão total do arquivo é obtida somando esses 3 números. Um arquivo com
permissão de leitura (Read) assume o valor 4. A permissão de escrita (Write)
assume o valor 2, a permissão Execute assume o valor 1. Vejam-se alguns dos
exemplos mais comuns:
 chmod 777 (nome_arquivo/diretório) - neste exemplo o proprietário, grupo e
todos os usuários têm permissões quer de leitura (Read) , gravação (Write) e
execução (Execute)
 chmod 755 (nome_arquivo/diretório) - aquí o proprietário têm todas as
permissões, mas o grupo e os outros usuários têm apenas permissão de
leitura e execução, ou seja, não podem gravar.
 chmod 666 (nome_arquivo/diretório) - Dá permissões de gravação e leitura a
todos os usuários

 chmod 644 (nome_arquivo/diretório) - atribui leitura e gravação para o
proprietário e apenas leitura para o grupo e usuários
Se o proprietário quiser todas as permissões, ficaria assim:
 Read + Write + Execute (4+2+1);
 Read + Execute (4+1) para o grupo (para ser Write teria de ser 4+2); e
 Execute para os restantes teríamos a seguinte exemplo chmod 751
(nome_arquivo/diretório)
O chmod permite atuar sobre 3 grupos bem distintos, que são :
 'u' - utilizador (user)
 'g' - grupo (group)
 'o' - outros (others)
Isto significa que podemos ou usar as letras (u, g, o) , ou o modo octal explicado
antes. Estas letras são conjugas com as restantes r (read), w (write) x (execução)
Mas e o que isso tem haver com o Joomla? Tudo se levarmos em conta que você
estará hospedando no GNU/LINUX.
Os seus diretórios deverão estar com permissão 0755 e os seus arquivos com
permissão 0644 e o provedor de hospedagem deve utilizar sistema operacional
GNU/LINUX.

8.6 ATUALIZAÇÃO DA VERSÃO DO CMS
A equipe de desenvolvimento do Joomla! É muito ativa e reage rapidamente a novos
tipos de ataques e/ou vulnerabilidades encontradas no código-fonte do CMS,
lançando releases das versões estáveis. Cabe aos usuários, particularmente a quem
desenvolve e possui perfil de super administrador de um website, a atualização da
versão utilizada em seu projeto.
A atualização é um processo simples e pode ser utilizada uma extensão para
automatização do processo.
É fundamental manter a versão do CMS atualizada para evitar problemas de
segurança.
8.7 INFORMAÇÕES RELEVANTES
Desabilite o relatório de erros no backend do Joomla, escolhendo a opção Nenhuma
para relatórios de erros nas configurações globais. É interessante que a diretiva
display_errors do php também esteja desabilitada. Mas, lembre-se que dependendo
do contexto o display_errors deve estar habilitado. Por exemplo: você instala um
módulo e ele dá pau. Com o display_errors desabilitado você verá apenas uma
página em branco. Esta diretiva fica no php.ini e você não terá acesso no servidor. O
máximo que poderá fazer é criar uma flag no seu arquivo (.htaccess) alterando o
padrão de ON para OFF.

8.8 ATAQUES CSRF
Joomla! tenta se proteger de ataques CSRF inserindo uma seqüência aleatória
chamada “token” em cada requisição de formulário do tipo POST ou GET. Esta
seqüência aleatória fornece proteção porque não só o site comprometido precisa
saber a URL do site de destino e um formato de solicitação válida para o local do
alvo, ele também deve conhecer a seqüência aleatória que muda a cada sessão e a
cada usuário logado. O framework do joomla! torna fácil incluir essa proteção em
componentes MVC também. É simples de implementar em ambos as requisições de
formulários, POST e GET.
8.8.1 POST
Para requisições do tipo POST em formulários HTML do componente MVC deve-se
usar a seguinte linha de código: <?php echo JHTML::_( 'form.token' ); ?>
Será impresso algo parecido com <input type="hidden"
name="1234567890abcdef1234567890abcdef" value="1" />
8.8.2 GET
Para requisições do tipo GET em formulários HTML do componente MVC deve-se
usar a seguinte linha de código que irá gerar uma URL com o símbolo na seqüência
de consulta.

Figura 28 – JRoute
8.8.3 Verificando o Token
Depois de ter incluído o símbolo em sua forma ou na sua seqüência de consulta, o
token deve ser verificado antes que o script do componente MVC realize o pedido.
Isto é feito com a seguinte linha:
Figura nr 29 – JRequest
Se a solicitação é proveniente da seqüência de consulta, isto deve ser especificado
no componente MVC. O código deve ficar da seguinte forma:
Figura 28 – JRequestGet
8.8.4 Procedimentos complementares
Embora esses Métodos ajudam a prevenir contra ataques do tipo CSRF, é
importante perceber que existem outras práticas de segurança que devem ser

seguidas pelo administrador do sistema para evitar que a mesma seja
comprometida.
1. Não navegue em outros sites com o mesmo navegador enquanto estiver
logado no backend do Joomla.
2. Use sempre o “logout” para encerrar a sessão do backend do joomla.
3. Não fique logado no backend do joomla sem fazer nada.
4. Verifique se o endereço na barra do navegador corresponde ao endereço
do seu website
8.9 VALIDAÇÃO DE CAMPOS NOS FORMULÁRIOS DE
COMPONENTES
Todos os campos de formulários que receberão entrada de dados devem ser
validados no próprio código-fonte do componente, em scripts no lado cliente
(javascript) e no lado servidor (php).
As validações devem verificar se o tipo de dado inserido é permitido, se o tipo de
dado condiz com o esperado pela aplicação, o tamanho do dado inserido bem como
evitar o envio de qualquer “tag” que possa causar danos ao sistema.
Para o tamanho de campos dos dados a serem inseridos nos formulários devem ser
utilizados “maxlength” e “size”.
A eliminação de “tags” deve ser realizada através da utilização de funções
específicas do “PHP”, para este fim.

8.9.1 Validação de campos no lado cliente
Existem vários scripts em javascript que validam os campos digitados em um
formulário de inserção de dados e emitem alertas através de janelas avisando sobre
os possíveis erros encontrados ou usam máscaras que evitam erros de digitação
sendo as mais comuns, as utilizadas para campos do tipo CPF, CNPJ e telefone.
Este tipo de validação pode ser visualizado através do código-fonte da página.
8.9.2 Validação de campos no lado do servidor
As validações no lado servidor ficam protegidas e não podem ser visualizadas no
código-fonte da página. São scripts em “PHP” que podem ser incluídos no corpo do
próprio código-fonte ou serem instanciados via “include” ou “require once”.
8.9.3 Validação de formulário contra SQL Injection
Injecções SQL tornam possível para os atacantes de modificar algumas consultas
SQL inseguro, o script é executado, de tal forma que poderia alterar dados em seu
banco de dados ou dar a dados sensíveis para o atacante. Isso é por causa da
entrada do usuário invalidado. Abaixo temos uma parte do código-fonte de um
formulário de login de um componente MVC.

Figura 30 – $_Get[]
A variável $database executa uma consulta e seleciona todos os registros da tabela
mytable onde a chave primária da tabela possua o mesmo valor passado no
formulário através do campo que passa o valor da variável $value.
Um invasor pode entrar com uma seqüência do tipo "1 OR 1 ', no formulário e os
resultados da consulta ficariam parecido com:
Figura 31 – SQLInjection
A consulta irá retornar todas as linhas da tabela jos_mytable, o formulário de “login”
acaba de ser invadido e a segurança do sistema comprometida.
As seguintes medidas deveriam ter sido aplicadas em todas as entradas dos
formulários de consulta “SQL” para campos que recebam os números inteiros em
consultas SQL, para proteger o mesmo de ataques do tipo SQL Injection:

Figura nr 32 – String SQLInjection
Além disso, devemos usar mosGetParam () para recuperar a entrada do usuário a
partir da solicitação, por exemplo:
Figura nr 33 – String SQLInjection
mosGetParam irá retornar valores de escape, independentemente da configuração
do PHP magic_quotes_gpc.
JRequest:: getVar – retornará valores “unsecaped”, independentemente da
configuração do PHP magic_quotes_gpc. Em Joomla! 1.5, devido ao suporte UTF-
8, a regra-quadro é que as variáveis no código são escapados, e banco de dados
apropriado escapar deve ser aplicado no momento da requisição do banco de
dados, com US $-> db getEscaped ($ string) ou usando o objeto de Métodos save ()
Que fazem o bom escape.
8.9.4 Validação de formulários contra ataques XSS
Cross Site Scripting (XSS) significa a execução de código script (JavaScript por
exemplo) em um navegador por visitantes. É importante evitar o uso indiscrimidado

do “echo” no código-fonte fo componente por ser potencialmente perigoso para os
visitantes:
Figura 34 – String Request
Usar mosGetParam () para recuperar a entrada do usuário a partir de um pedido,
pode melhorar muito a segurança. Mas não confie no usuário, também dê uma boa
olhada em lugares onde ecoam as informações para o browser. Use:
Figura 35 – String HmtlSpecial
8.10 VALIDAÇÃO DO NÍVEL DE PERMISSÃO DOS USUÁRIOS
Componentes que possuam diferentes níveis de acesso devem possuir linhas de
validação para garantir que apenas usuários com o nível de permissão adequada
possam acessar determinadas áreas do mesmo. O componente deve verificar se o
usuário faz parte do grupo de usuários com nível de acesso “gerente”,
“administrador” ou “super administrador”.
8.11 SEGURANÇA NA PROGRAMAÇÃO DE COMPONENTE MVC
O primeiro cuidado que você precisa ter é evitar o acesso direto de componentes,
módulos, plugins, etc. Todo mundo está careca de saber que os componentes do

Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla

Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla

Semelhante a Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla (20)

Mais de Júlio Coutinho

Mais de Júlio Coutinho (11)

Processo de Testes de Vulnerabilidades em Componentes MVC para CMS Joomla